Ich wende mich eigentlich nur selten direkt an Entwickler eines Projekts oder eines Programmes. Meistens dann, wenn ich davon überzeugt bin, dass es wichtig oder zweckmäßig ist, ein besonderes Feature einzubauen oder einen Bug zu beseitigen. Wenn es angebracht erscheint, nutze ich auch die Bugtracker- oder Featurerequestinterfaces und teste vorher, ob das angesprochene Problem nachzuvollziehen ist bzw. unabhängig von meiner individuellen Benutzung existiert.
Dabei habe ich schon aufgrund der Vielzahl an Applikationen kein Interesse, mich bei einem Einzelproblem für jede Applikation über eine Mailingliste einzubringen bzw. dort anzumelden, Mitglied eines Forums zu werden oder mich abseits der Benutzung intensiver damit zu beschäftigen. Umso mehr ärgert es mich, wenn ich dann eine Antwort erhalte, die mehr oder weniger überhaupt nicht auf den Inhalt meiner E-Mail eingeht und stattdessen die Standardaufforderung kommt, ich solle das doch in Mailingliste XYZ veröffentlichen. Meistens lasse ich es dann bleiben oder bemühe vielleicht den Bugtracker.
Zuletzt war dies der Fall bei
Enigmail, der Erweiterung für Thunderbird zur Nutzung von GnuPG. Nur um das vorweg zu sagen: Ich verwende Enigmail sehr gerne und denke, dass Enigmail eine wichtige Erweiterung ist, die aufgrund ihrer relativ einfachen Verwendung viel für die Verbreitung von OpenPGP getan hat.
Aufgrund eines Problems mit einem Mailpartners habe ich mir die Signierfunktionen von Enigmail näher angeschaut und bin dabei auf eine Diskrepanz zur sinnvollen Anwendung bzw. Konfiguration von GnuPG gestoßen, die ich dann mit obigem Ergebnis dem Enigmailprojektleiter mitgeteilt habe.
Bei Enigmail ist es nämlich so, dass man unter den PGP/MIME Einstellungen einen Hash-Algorithmus angeben kann, also SHA256, RIPEMD160 usw. Dieser gilt unabhängig davon, ob man
PGP/MIME oder PGP/INLINE verwendet, was schon mal von der GUI her irreführend ist. Aber was noch gravierender ist: Die Einstellung schreibt den Hashalgorithmus statisch fest und entspricht damit der GnuPG Option "
digest-algo name", was bedeutet, dass der gewählte Hashalgorithmus immer benutzt wird, egal, ob die PGP / GnuPG Version des Mailpartners den interpretieren kann oder nicht und ob der Mailpartner den Hashalgorithmus bevorzugt oder nicht.
Wer die GnuPG Mailingliste schon etwas länger liest, weiß, dass die statische Verwendung von Algorithmen immer wieder ein Quell geschilderter Kompatibilitätsprobleme war und allgemein von den GnuPG Entwicklern nicht empfohlen wird.
Speziell zur Verhinderung dieser Probleme und um die Präferenzen des Schlüsselbesitzers zu achten, wurde für GnuPG einerseits die
Möglichkeit geschaffen, die eigenen Algorithmuspräferenzen in dem Eigenzertifikat zu hinterlegen und so dem Kommunikationspartner bekannt zu machen und andererseits die "
personal-digest|cipher|compress-preferences" Optionen eingerichtet, mit denen man ebenfalls die eigenen Präferenzen in der Konfigurationsdatei gpg.conf angibt. Der eigentliche Zweck der Optionen besteht aber darin, vor einer Signierung und / oder Verschlüsselung einen dynamischen Abgleich zwischen den Algorithmuspräferenzen des Kommunikationspartners und den eigenen Präferenzen durchzuführen, um den "größten, gemeinsamen Nenner" zu finden, so dass "immer" die Algorithmen Verwendung finden, die beide Partner akzeptieren und "verstehen". Also das genaue Gegenteil von der Methode, wie Enigmail die Signierung implementiert.
Ich habe deshalb die Vorschläge gemacht, die Auswahlfunktion in Enigmail ganz herauszunehmen und die Wahl des Algorithmus durch GnuPG und die "personal-*-preferences" vornehmen zu lassen – was, so die Antwort, nicht gehen würde, da für PGP/MIME der Hash Algorithmus bekannt sein muss, bevor die Daten signiert werden und der Algorithmus bei PGP/MIME im Mail Header angegeben sein muss. Oder die "personal-*-preferences" Optionen als Einstellungen in Enigmail anzugeben, was die Sache komplizierter für den Benutzer machen würde oder einen Schalter für den Hashalgorithmus in den Empfängerregeln einzufügen.
In der Antwort kam neben der Aufforderung zur Mailinglistenbeteiligung noch die Methode, für jeden Schlüssel per GnuPG prüfen zu lassen, welche Algorithmen unterstützt werden und den besten zu wählen, was aber meinem ersten Vorschlag entspricht, wenn man die Auswertung der Präferenzen im Eigenzertifikat hinzunimmt – wie das zu implementieren ist, weiß ich doch nicht und ist auch nicht meine Aufgabe. Ich weiß auch nicht, was jetzt daran so schwer sein soll, den Inhalt und Zweck meiner Mail als Blödsinn zu verwerfen oder einfach als sinnvoll aufzugreifen und das mit meinem "Entwicklerstab" zu besprechen.
Owner login