Hast du pinentry aus den packages oder ports? Wohin zeigt bei dir der symlink /usr/local/bin/pinentry?
Thunderbird/Enigmail entschlüsselt nicht
- Ersteller JochenF
- Erstellt am
Mittlerweile glaube ich dass einfach nur der Port schlecht gemacht ist. "make config" erlaubt nur genau eine Option aus 4 möglichen. Default ist "TTY", was auch beim Binärpaket der Fall ist. Liest man mal das README, gibt es offenbar aber auch die Möglichkeit mehre Optionen zu aktivieren, und es gibt sogar ein "auto-detection", womit ein Wrapper überflüssig wäre.
Das „To build everything that is supported (complete auto-detection)“ bezieht sich darauf, dass wenn der „configure“-Schritt merkt GTK ist installiert, auch den pinentry-gtk-2 vorsieht zu bauen. Ebenso mit QT und Curses. So ist meine Vermutung. Es geht also hier ums Bauen und nicht um das Verhalten zur Laufzeit.
Dann hab ich das wohl falsch verstanden. Aber dieser "ncurses-fallback-mode" wird doch wohl zur Laufzeit passieren, oder? Das würde doch reichen, damit es sowohl unter X11 als auch auf der Konsole funktioniert.
Probiere es am besten aus, installiere Dir das Paket pinentry-curses. Dann vermutlich in ~/.gnupg/gpg-agent.conf „pinentry-program /usr/local/bin/pinentry-curses“ (oder die Zeile raus und Symlink setzen). Neustarten und Enigmail testen. Selbst wenn das klappt wäre es aber noch keine Lösung.
Hab noch ein bisschen rumprobiert. Die GTK2-Version hat den Curses-Fallback drin. Nur die TTY-Version natürlich nicht. Baut man den Port mit GTK2, dann klappt das sowohl unter X11 als auch auf der Konsole (mit Curses).
Problem ist also nur, dass mit "TTY" ein scheiss Default gewählt wurde.
Problem ist also nur, dass mit "TTY" ein scheiss Default gewählt wurde.
Kein anderes Default wäre besser: pinentry-curses allein würde doch nicht mit Enigmail funktionieren und pinentry-gtk-2 kann man doch niemanden zumuten, nur weil er gnupg installiert – es würde eine Menge Zeug mitziehen.
Fakt ist aber auch, dass Enigmail nicht mit pinentry-tty funktioniert. Du kannst das drehen und wenden wie du willst, es ist und bleibt ein Fehler. Du kannst jetzt Thunderbird die Schuld geben, weil das eine falsche Abhängigkeit drin hat (aber wie willst du das mit den gegebenen Mitteln besser machen? Es gibt keine Möglichkeit eine bestimmte Konfiguration eines Paketes vorauszusetzen), oder du kannst pinentry die Schuld geben. Ich bin für pinentry, weil das die einzige Stelle ist wo man das Problem lösen kann.
Ich halte nichts von zusätzlichen Scripten wenn die Funktionalität schon in den Programmen enthalten ist. Wer weiss welche Sicherheitslücken man sich damit wieder einhandelt. Offenbar wurde ja auch ganz bewusst nicht das aktuelle Environment an pinentry übergeben (fehlende DISPLAY-Variable), wohl auch aus Sicherheitsgründen.
Na ganz einfach: die einzigen beiden Konfigurationen die sowohl mit als auch ohne X11 funktionieren, sind die GTK und die Qt Version. Die Qt Version ist als "broken" gekennzeichnet, also bleibt nur die GTK.
Somit sollte man die zum Default machen. Wer was anderes will kann es ja aus den Ports compilieren. Es gibt 1000 andere Pakete die als Default nicht die Minimal-Konfiguration haben. Was meinst du was ich schon alles aus den Ports compilieren musste, um den ganzen Linux-Ballast, wie z.B. HAL oder ALSA, loszuwerden. Ich sehe keinen Grund warum man hier die Minimalkonfiguration zum Default machen sollte, und in Kauf nimmt dass dann zig andere Binärpakete die gnupg in einer Desktopumgebung nutzen, dann nicht funktionieren.
Das darf man natürlich nicht unkommentiert hier stehen lassen: Es reicht den gpg-agent neu zu starten. Einen reboot braucht man nur wenn man den Kernel aktualisiert (oder bei bestimmten Hardware- oder Kernel-Fehlern).
JochenF: Danke für deine Mühen! Seit ich auf dem Desktop zu FreeBSD gewechselt bin hab ich ständig Probleme mit pinentry und Enigmail+Thunderbird. Allein bis ich initial herausgefunden hatte, was das Problem war (dank absolut nichtssagender Fehlermeldung) vergingen fast Wochen. Von daher danke dass du dich des Problems annimmst!
Normal finde ich das nicht (auch nicht für BSD). Konfig-Files dienen zur Personalisierung, nicht als Workaround für Bugs. Bei globalen Konfig-Files mag es ja noch angemessen sein, eine spezifische Einstellung vorzunehmen, aber User-Konfig-Files sollten auch in der Default-Einstellung zumindest funktionieren. Ich kann doch jetzt nicht hergehen und auf allen meinen Rechnern in allen User-Accounts die gpg-agent.conf ändern. Und bei einer User Neuanlage jedesmal wieder die defaults ändern.
Dafür gibts ja das skelton für neue User. Aber ich will auch nicht polarisieren. Ich hatte mich nur gewundert da ich eben keinen "Fehler" sah.
Beim gpg-agent? Wo wäre denn das?
Rakor: aus meiner Perspektive kann ich nicht nachvollziehen, wie man das nicht als Fehler sehen kann. Als ich vor einer Weile auf FreeBSD als Desktopsystem gewechselt bin konnte ich eine Weile keine Emails verschlüsseln. Warum? Weil Thunderbird/Enigmail seltsame Fehlermeldungen ausspuckt, die mich an der völlig falschen Stelle, nämlich der Schlüsselverwaltung suchen lies. Selbst langes googlen und Fragen stellen im offiziellen Forum brachte keine Antworten, mehr durch Zufall bin ich auf eine Seite gestoßen (die ich seitdem leider nicht wiederfinden kann), die überhauptmal "pinentry" erwähnt. Ich hatte bis dahin keine Ahnung, daß das benötigt wird, unter Linux sah die Passworteingabe wie ein normales Passwortfenster von Thunderbird aus. Das alles in Kombination machte es mir fast unmöglich das Problem zu lösen. Wir können uns jetzt gern darüber unterhalten, wo der Bug sitzt (Paketabhänigkeit, Standardconfig des Pakets, Dokumentation...), aber ein Bug ist definitiv vorhanden.
SolarCatcher
Well-Known Member
@yggdrasil
Unterstütze ich vollkommen - es ging mir ganz genau so. Daher bin ich sehr dankbar, dass hier einige aktiv geworden sind und eine Lösung entwickelt haben. Ich mag nicht nach jedem pkg upgrade wieder rumfummeln oder irgendwelche Ports locken, wenn es nicht unbedingt sein muss (wer weiß, ob es nicht irgendwann wichtig ist, dass gerade pinentry aktualisiert wird... dann funktioniert vielleicht etwas anderes nicht mehr).
Unterstütze ich vollkommen - es ging mir ganz genau so. Daher bin ich sehr dankbar, dass hier einige aktiv geworden sind und eine Lösung entwickelt haben. Ich mag nicht nach jedem pkg upgrade wieder rumfummeln oder irgendwelche Ports locken, wenn es nicht unbedingt sein muss (wer weiß, ob es nicht irgendwann wichtig ist, dass gerade pinentry aktualisiert wird... dann funktioniert vielleicht etwas anderes nicht mehr).
pit234a
Well-Known Member
pinentry-program /usr/local/bin/pinentry-gtk-2
steht in meiner ~/.gnupg/gpg-agent.conf und das ist wohl deutlich genug, ich nutze ausschließlich dieses Pinentry (und hatte auch mal eine QT-Version probiert).
Links brauche ich damit nicht zu verbiegen. Allerdings stolpere ich gelegentlich auch über Pakete, die mir Funktionen stillegen und beinahe immer ist Claws une ein Teil davon betroffen. Es hilft meist nur der Bau aus den Ports, wenn man erst mal herausgefunden hat, was denn klemmt.
Eine GPG-Verschlüsselung überhaupt zum Laufen zu bringen (mit Claws-Mail), ist mir sehr schwer gefallen und ich bin froh, dass ich das gerade mal für einen Nutzer so hinbekommen habe. Wie das Szenario ausschaut, wenn ich mehrere Nutzer auf einen gpg-agent zugreifen lassen will und auch unterschiedliche Mail-Clients mit unterschiedlichen Pinentry Versionen verlangt werden, das kann ich mir derzeit gar nicht ausmalen.
Zentrale Information und Dokumentation ist da gar nicht. Stundenlanges Suchen bei mehr oder weniger passenden Themen verdirbt schnell die Freude.
Das ist einer der Punkte, die mich immer wieder überlegen lassen, ob ich überhaupt mit meinem nächsten PC wieder FreeBSD einsetzen werde. Irgendwie konnte ich das zwar mal lösen, aber es brauchte mir einfach zu lange Zeit und mir sind inzwischen andere Dinge wichtiger. Mit einem Mac-OS-X und etwas Zusatzsoftware und mit einem Ubuntu war das eine Affäre von jeweils vielleicht 15 Minuten, inklusive Import meiner keys. Es geht einfach, man braucht nichts zu suchen und zu lesen, man braucht keine Gehirnzellen zu opfern. Irgendwie auch blöd, zugegeben.
Aber etwas besser und zusammenfassender könnte man das Thema sicher für FreeBSD aufbereiten.
Wie schon angedeutet: man mag gar nicht glauben, dass niemand sonst über ein Problem stolpert.
Ist das nicht vielleicht auch etwas für einen Wiki-Beitrag?
steht in meiner ~/.gnupg/gpg-agent.conf und das ist wohl deutlich genug, ich nutze ausschließlich dieses Pinentry (und hatte auch mal eine QT-Version probiert).
Links brauche ich damit nicht zu verbiegen. Allerdings stolpere ich gelegentlich auch über Pakete, die mir Funktionen stillegen und beinahe immer ist Claws une ein Teil davon betroffen. Es hilft meist nur der Bau aus den Ports, wenn man erst mal herausgefunden hat, was denn klemmt.
Eine GPG-Verschlüsselung überhaupt zum Laufen zu bringen (mit Claws-Mail), ist mir sehr schwer gefallen und ich bin froh, dass ich das gerade mal für einen Nutzer so hinbekommen habe. Wie das Szenario ausschaut, wenn ich mehrere Nutzer auf einen gpg-agent zugreifen lassen will und auch unterschiedliche Mail-Clients mit unterschiedlichen Pinentry Versionen verlangt werden, das kann ich mir derzeit gar nicht ausmalen.
Zentrale Information und Dokumentation ist da gar nicht. Stundenlanges Suchen bei mehr oder weniger passenden Themen verdirbt schnell die Freude.
Das ist einer der Punkte, die mich immer wieder überlegen lassen, ob ich überhaupt mit meinem nächsten PC wieder FreeBSD einsetzen werde. Irgendwie konnte ich das zwar mal lösen, aber es brauchte mir einfach zu lange Zeit und mir sind inzwischen andere Dinge wichtiger. Mit einem Mac-OS-X und etwas Zusatzsoftware und mit einem Ubuntu war das eine Affäre von jeweils vielleicht 15 Minuten, inklusive Import meiner keys. Es geht einfach, man braucht nichts zu suchen und zu lesen, man braucht keine Gehirnzellen zu opfern. Irgendwie auch blöd, zugegeben.
Aber etwas besser und zusammenfassender könnte man das Thema sicher für FreeBSD aufbereiten.
Wie schon angedeutet: man mag gar nicht glauben, dass niemand sonst über ein Problem stolpert.
Ist das nicht vielleicht auch etwas für einen Wiki-Beitrag?