Passphrase wird nicht mehr abgefragt

  • Wo eingestellt - im Agent oder in Enigmail?

    In beiden. Ich habe die Einstellung für default-cache-ttl in Enigmail vorgenommen. Sie wurde in die gpg-agent.conf übernommen. Den Wert für max-cache-ttl habe ich direkt in der gpg-agent.conf geändert. Dafür bietet Enigmail kein Dialogfeld.

    Die max-cache-ttl habe ich deshalb geändert, weil ich so sicher gehen wollte, dass es in jedem Fall zu einem Ablauf kommen muss, auch dann wenn die default-cache-ttl erneut von vorn beginnt.


    Das blieb ohne Wirkung.


    Da ich das auch in meinem Linus-Container gemacht habe, will ich nicht gänzlich ausschließen, dass ich die Tests gerade durcheinander bringe. Ich benutze im Internet fast ausschließlich eine Art Proxy und Thin-Client, den wir gemeinsam mit einigen Bekannten betreiben. Darauf hat jeder seine Ubuntu VM, die er quasi von überall all aus benutzen kann. Meine Session kommt mit mir mit, z.B. auf Reisen oder so wie jetzt an den Arbeitsplatz.


    Ich werde mir das nochmal anschauen, wenn ich meinen eigenen Rechner zur Verfügung habe. Ich bin mir aber recht sicher, dass ich gpg-agent-conf kontrolliert habe und er Agent auch lief.

  • Enigmail nimmt einen konstanten Faktor? Es spricht nichts dagegen und spart ein Dialogfeld. Das war mir bisher nicht aufgefallen. Ich dachte, es würde den Default belassen und habe es deshalb manuell geändert.

  • Mir ist gerade eingefallen, dass wir ja auch einen Windows 10 Host auf dem Server haben. Er zeigt gleiches Verhalten wie mein privater Windows PC. Die Passphrase kann auch über das Menü nicht gelöscht werden.

    Ich habe es mit verschieden Zeiten versucht, auch "0". Änderungen aus Enigmail heraus werden in die gpg-agent.conf übernommen. Der Agent läuft laut Taskmanager ebenfalls.


    Code
    1. ###+++--- GPGConf ---+++###
    2. default-cache-ttl 60
    3. max-cache-ttl 600
    4. ###+++--- GPGConf ---+++### 05/25/18 13:32:38 Mitteleuropäische Sommerzeit
    5. # GPGConf edited this configuration file.
    6. # It will disable options before this marked block, but it will
    7. # never change anything below these lines.
  • Ein Update dazu:


    Heute habe ich, aufgrund eines anderen Themas im Forum, GnuPG und die dazugehörigen Komponenten einem Upgrate auf GunPG 2.2.7 unterzogen. Unter Ubuntu 14.04 musste ich das per configure, make und make install von Hand machen.

    Aufgrund einiger weiterer Abhängigkeiten war das kein Spaß. Auch Enigmail musste ich neu installieren, weil es partout nicht dazu zu bewegen war, den mit der Version 2.2 einhergehenden neuen Schlüsselspeicher zu benutzen. Ich empfehle diesen Weg deshalb ausdrücklich nicht zur Nachahmung.


    Seit dem Upgrade läuft die gecachete Passphrase wieder korrekt nach der eingestellten Zeit aus. Auch das Löschen funktioniert wieder.

  • Mit Hilfe der Man-Pages und der Dokumentation bei GnuPG habe ich mich etwas weiter in die Thematik gpg-agent, gpg-connect-agent, gnome.keyring usw. eingelesen.

    Kurzform:

    Folgende Konfiguration funktioniert bei auf einem virtuellen System auf einem Remote-Server und auch auf meinem eigenen PC bei Nutzung des Gnome-Keyrings. Die Passphrase wird (wieder) nach ihrer Ablaufzeit aus dem Cache gelöscht.

    Ubuntu 14.04.
    gpg (GnuPG) 2.2.7
    libgcrypt 1.8.2

    Mit dem dconf-editor die gpg-cache-method auf idle setzen und die gpg-cache-ttl wie gewünscht einstellen.
    Den Autostart von "/usr/bin/gnome-keyring-daemon --start --components=gpg", der über die Datei gnome-keyring-gpg.dektop erfolgt, deaktivieren.

    Der Keyring selbst wird natürlich weiterhin gestartet und läuft auch. Das für mich Überraschende ist aber, dass er weiterhin auch für gpg funktioniert.

    Code
    1. echo $GPG_AGENT_INFO
    2. /run/user/1000/keyring-2TkG69/gpg:0:1



    Auch Enigmail meldet, dass der gnome-keyring für die Verwaltung der Passphrase benutze wird. Möglicherweise sorgt GnuPG, wenn es durch Enigmail aufgerufen wird, dafür, dass der Keyring benutzt wird. Es ist jedenfalls in meinem Fall so, dass die Ablaufzeit nur dann berücksichtigt wird, wenn ich den Autostart nicht durchführen lasse.

    Unter ~/.gnupg finde ich mit der Version 2.2.7 auch keine gpg.conf oder gpg-agent.conf mehr.

    Eine wirklich durchgängige Dokumentation, insbesondere dazu. wie der Keyring im Detail mit dem gpg-agent zusammenspielt, habe ich nicht gefunden. Falls jemand dazu nähere Informationen hat, würde ich mich über einen Link freuen.


    Die Version 2.2.7 gibt es noch nicht über das Ubuntu Repository. Dort gibt es derzeit noch gpg 1.4.x und gpg2 2.0.22. Ich musste die Installation deshalb selbst durchführen. Das ist nicht jedem zu empfehlen. Im Zweifelsfall ist zu überlegen, ob man nicht besser das Speichern der Passphrase für eine gesamte Session akzeptiert.


    Da die 2.2.7 nun die einige Version ist, die ich installiert habe, kann ich nicht testen, ob die oben genannten Schritte auch mit einer 2.0.x erfolgreich sind. Einen Versuch wäre es Wert.

  • Abschließend:


    Wegen des in 2019 auslaufenden Supports von Ubuntu 14.04 habe ich erste Tests mit der 18.04 durchgeführt. Es gibt einige Ungereimtheiten, jedoch nicht in Bezug auf gpg. Die 18.04 kommt bereits mit GnuPG 2.2.4.


    Ubuntu 18.04

    GnuPG 2.2.4.

    Enigmail 2.0.7


    Die Passphrasenverwaltung funktioniert einwandfrei. Ebenfalls nach manuellem Update auf GnuPG 2.2.8.


    Die in Enigmail importierten privaten Schlüssel sind im Keyring enthalten. Der Keyring Daemon wird dem Anschein nach nicht mehr zwingend benutzt:

    Code
    1. GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1



    Hinweis:

    Das manuelle Nachinstallieren der 2.2.8 ist nicht schwierig aber auch nicht trivial. Ich möchte deshalb niemanden verleiten.

    Ob die zusätzlichen Fixes gegenüber der 2.2.4 (u.a. Efail/MDC) relevant sind, hängt vom Sicherheitsbedürfnis des Benutzers ab. Nach meiner persönlichen Meinung ist Efail für den normalen Benutzer irrelevant.

    Wer unsicher in Bezug auf die manuelle Installation ist und kein zwingendes Sicherheitsbedürfnis hat, wartet besser auf das offizielle Update über das Ubuntu Repository, auch wenn das noch dauern sollte.