From bernhard at intevation.de Fri May 3 09:08:40 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 May 2019 09:08:40 +0200 Subject: Trust-Tiefe =?utf-8?q?nachtr=C3=A4glich?= =?utf-8?q?_=C3=A4ndern=3F?= In-Reply-To: <7aa711b3d91732f14ccc1311cfdbc387b486716f.camel@googlemail.com> References: <201904250848.40986.bernhard@intevation.de> <7aa711b3d91732f14ccc1311cfdbc387b486716f.camel@googlemail.com> Message-ID: <201905030908.40466.bernhard@intevation.de> Moin Dirk, Am Donnerstag 25 April 2019 13:32:49 schrieb Dirk Gottschalk: > Beim Erstellen einer Trust-Signatur fragt FPF nach der Tiefe. Also wie > Schlüssel behandelt werden sollen, die von der Person gezeichnet > wurden. was ist FPF? > Jedoch habe ich keinen Weg gefunden, diesen Wert im Nachhinein zu > ändern. Das wäre für mich derzeit recht interessant, da wir für ein > Software-Projekt GPG einsetzen und damit eine kleine CA, wenn man so > will, einrichten möchten, da GPG(me) nach unserem Empfinden deutlich > einfacher zu verednen ist und dabei den gleichen Job wie das für > unseren Fall sehr überladene OpenSSL. Persönlich würde ich gpgsm/gpgme ebenfalls vorziehen, weil es technisch modularer und besser zu verstehen ist. (Aber ich gehöre auch zum GnuPG-Team.) > Unser derzeitiger Workaround liegt darin, Keyring und Trustdb zu > sichern, anschließend zu löschen und dann die besagten Keys neu zu > importieren und einen neuen Trust-Eintrag mit entsprechender Tiefe zu > machen. Das geht natürlich auch recht schnell. Mich interessiert nur, > ob wir blind sind und etwas übersehen haben, oder ob das schlichtweg > nicht vorgesehen ist. Es passt nicht in meinem gedanklichen Konzept, dass es eine Tiefe pro öffentlichem Schlüssel gibt. Insofern müsste ich das auch im Code nachlesen und experimentieren. Ist aus meiner Sicht also eher eine Frage für Gnupg-devel at . Viele Grüße, Bernhard -- www.intevation.de/~bernhard   +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 488 bytes Beschreibung: This is a digitally signed message part. URL : From dirk.gottschalk1980 at googlemail.com Sun May 5 13:08:47 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 05 May 2019 13:08:47 +0200 Subject: Trust-Tiefe =?ISO-8859-1?Q?nachtr=E4glich?= =?ISO-8859-1?Q?_=E4ndern=3F?= In-Reply-To: <201905030908.40466.bernhard@intevation.de> References: <201904250848.40986.bernhard@intevation.de> <7aa711b3d91732f14ccc1311cfdbc387b486716f.camel@googlemail.com> <201905030908.40466.bernhard@intevation.de> Message-ID: <955622bd62cfb8de5569e03e52b5556e4093df24.camel@googlemail.com> Hallo Bernhard. Am Freitag, den 03.05.2019, 09:08 +0200 schrieb Bernhard Reiter: > Moin Dirk, > Am Donnerstag 25 April 2019 13:32:49 schrieb Dirk Gottschalk: > > Beim Erstellen einer Trust-Signatur fragt FPF nach der Tiefe. Also > > wie > > Schlüssel behandelt werden sollen, die von der Person gezeichnet > > wurden. > was ist FPF? FPF ist GPG, wenn man gerade einen KInoten in den Fingern hat. Sorry dafür, den habe ich glatt übersehen. > > Jedoch habe ich keinen Weg gefunden, diesen Wert im Nachhinein zu > > ändern. Das wäre für mich derzeit recht interessant, da wir für ein > > Software-Projekt GPG einsetzen und damit eine kleine CA, wenn man > > so > > will, einrichten möchten, da GPG(me) nach unserem Empfinden > > deutlich > > einfacher zu verednen ist und dabei den gleichen Job wie das für > > unseren Fall sehr überladene OpenSSL. > Persönlich würde ich gpgsm/gpgme ebenfalls vorziehen, weil es > technisch > modularer und besser zu verstehen ist. (Aber ich gehöre auch zum > GnuPG-Team.) GPGsm ist eine feine Sache, kann aber keine CA stemmen, ohne viel Voodoo, da muss dann also wieder OpenSSL irgendwo in der Kette mitspielen. Für mich wäre das kein Problem, allerdings für einige der Leute, die damit nachher klar kommen müssen. > > Unser derzeitiger Workaround liegt darin, Keyring und Trustdb zu > > sichern, anschließend zu löschen und dann die besagten Keys neu zu > > importieren und einen neuen Trust-Eintrag mit entsprechender Tiefe > > zu > > machen. Das geht natürlich auch recht schnell. Mich interessiert > > nur, > > ob wir blind sind und etwas übersehen haben, oder ob das > > schlichtweg > > nicht vorgesehen ist. > Es passt nicht in meinem gedanklichen Konzept, dass es eine Tiefe > pro öffentlichem Schlüssel gibt. Insofern müsste ich das auch im Code > nachlesen und experimentieren. Ist aus meiner Sicht also eher eine > Frage für Gnupg-devel at . Wenn du einen Schlüssel editierst und ein 'tsign' machst, wird nach dieser Tiefe gefragt, aber nur da, scheinbar. Ich werde mich mit dem Thema mal an die beiden englischsprachigen Gruppen wenden, vielleicht hat da jemand eine zündende Idee, oder kann die Sache genauer erklären. Vielen Dank für deine Hilfe. Gruß, Dirk -- Dirk Gottschalk Ardennenstrasse 25 52076 Aachen, Germany GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 833 bytes Beschreibung: This is a digitally signed message part URL : From bernhard at intevation.de Mon May 6 09:10:45 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 6 May 2019 09:10:45 +0200 Subject: Trust-Tiefe =?utf-8?q?nachtr=C3=A4glich?= =?utf-8?q?_=C3=A4ndern=3F?= In-Reply-To: <955622bd62cfb8de5569e03e52b5556e4093df24.camel@googlemail.com> References: <201905030908.40466.bernhard@intevation.de> <955622bd62cfb8de5569e03e52b5556e4093df24.camel@googlemail.com> Message-ID: <201905060910.45369.bernhard@intevation.de> Moin Dirk, Am Sonntag 05 Mai 2019 13:08:47 schrieb Dirk Gottschalk: > FPF ist GPG, wenn man gerade einen KInoten in den Fingern hat. Sorry > dafür kein Problem, passiert uns allen mal. :) > GPGsm ist eine feine Sache, kann aber keine CA stemmen, ohne viel > Voodoo, Die anderen vom Entwicklungsteam, besonders Werner, interessiert das bestimmt, wobei Du dabei welche Schwierigkeiten hast. Noch ein Grund auf gnupg-devel@ weiterzuschreiben. ;) > > Es passt nicht in meinem gedanklichen Konzept, dass es eine Tiefe > > pro öffentlichem Schlüssel gibt. Insofern müsste ich das auch im Code > > nachlesen und experimentieren. Ist aus meiner Sicht also eher eine > > Frage für Gnupg-devel at . > > Wenn du einen Schlüssel editierst und ein 'tsign' machst, wird nach > dieser Tiefe gefragt, aber nur da, scheinbar. Ah, dabei geht es um die Signaturen, also nicht pro öffentlichem Schlüssel. Zumindest findet sich dazu im Handbuch ein Satz: tsign Make a trust signature. This is a signature that combines the notions of certification (like a regular signature), and trust (like the "trust" command). It is generally only useful in distinct communities or groups. For more information please read the sections ?Trust Signature? and ?Regular Expression? in RFC-4880. > Ich werde mich mit dem Thema mal an die beiden englischsprachigen > Gruppen wenden, vielleicht hat da jemand eine zündende Idee, oder kann > die Sache genauer erklären. Das ist bestimmt eine gute Idee. Viele Grüße, Bernhard -- www.intevation.de/~bernhard   +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 488 bytes Beschreibung: This is a digitally signed message part. URL : From bernhard at intevation.de Mon May 13 15:57:46 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 13 May 2019 15:57:46 +0200 Subject: Eigensignatur auf aktuellen Hash bringen (Heise Security Artikel) Message-ID: <201905131557.52676.bernhard@intevation.de> Moin, folgender Heise Artikel erklärt auf Deutsch, wie mensch sich die Signaturen auf den eigenen Schlüssel aktualisieren lassen, damit neue Hash-Verfahren verwendet werden. https://www.heise.de/security/artikel/Aufpoliert-Alte-PGP-Schluessel-mit-neuen-Signaturen-4331048.html Werners Kommentare bringt noch ein paar weitere Infos rein: https://www.heise.de/forum/heise-Security/Kommentare/Aufpoliert-Alte-PGP-Schluessel-mit-neuen-Signaturen/quick-set-expire/posting-34453618/show/ Ist interessant für Leute deren OpenPGP-Schlüssel schon etwas älter ist. Viele Grüße, Bernhard -- www.intevation.de/~bernhard   +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 488 bytes Beschreibung: This is a digitally signed message part. URL : From wk at gnupg.org Tue May 21 15:40:02 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 May 2019 15:40:02 +0200 Subject: Frage bzgl. gpg-agent In-Reply-To: <20190520201505.fdeac4ugsrn6jtaa@russet.rince.de> (Hanno Wagner's message of "Mon, 20 May 2019 22:15:05 +0200") References: <20190520201505.fdeac4ugsrn6jtaa@russet.rince.de> Message-ID: <87woiklydp.fsf@wheatstone.g10code.de> Hallo Hanno! On Mon, 20 May 2019 22:15, wagner at rince.de said: > - Rechner A: Server mit Emails (Debian Linux) > - Rechner B: Laptop der sich via ssh auf Rechner A einloggt (Kali Linux) > - Smartcard in Form eines yubikey Neo. Habe ich jahrelang auch so ähnlich gemacht. Ich habe dabei auf A "emacs --daemon" laufen lassen und mich von B über ssh und emacsclient daran bedient. Das mit dem emacsclient ist ganz praktisch aber man kann natürlich jeden Client auf A per ssh starten. Crypto habe ich direkt auf dem auf dem Server (eigentlich mein Desktop im Büro) gemacht; ledigich das pinentry musste ich per updatestartuptty umbiegen. Aber richtig; das geht dann nicht per smartcard. > Beide Rechner haben in ~/.gnupg/ denselben Public- und Secret keyring > liegen; die habe ich via scp kopiert. Secret Keys brauchst Du auf dem Server (A) nicht und könnten eventuell ein Problem sein - ich habe das aber nicht getestet. > Ich möchte nun von Rechner B aus die Mails die auf Rechner A liegen > entschlüsseln und anzeigen lassen (ssh, tmux und darin mutt). > Ich habe mir dafür die Webseite https://wiki.gnupg.org/AgentForwarding > angeschaut und auch ssh und den gpg-agent entsprechend konfiguriert, > zumindest bin ich der Meinung. Yep. Alles korrekt. > Was mache ich da falsch? Wie kann ich debuggen was da funktioniert > oder auch nicht? Kann ich rausfinden ob der auf Rechner A laufende gpg $ gpg-connect-agent 'getinfo restricted' /bye Auf dem Server sollte OK anzeigen - dann ist der Agent im restricted mode und das forwarding aktiv. Mit Wenn Du bei gpg aufrufen auf dem Server "--debug ipc" hinzufügts, sieht Du die Kommunikation mit dem (remote) agent. Praktischer ist es aber folgendes auf dem Cleint (laptop) zu machen: $ echo >>./gnupg/gpg-agent.conf 'socket://' $ echo >>./gnupg/gpg-agent.conf 'debug ipc' $ echo >>./gnupg/gpg-agent.conf 'verbose' $ gpgconf --reload gpg-agent Dann in einem andere tty $ watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log laufen zu lassen. Du solltest dann sehen was gpg-agent loged. Ist einfacher als tail(1) und Die config Optionen auch in scdaemon und dirmngr einbauen, womit DU das dann schön syncronisiert siehts. > Wenn ich auf Rechner B ein "gpg --card-status" eingebe, zeigt er mir > die Daten des Yubikey an, der sieht ihn also und kann ihn auslesen. Sieht gut aus. > Nur Rechner A scheint nicht mitzubekommen dass es eine Remote > gpg-agent gibt der ihm helfen könnte... Probier dort mal gpg-connect-agent oder aber fortune | gpg -eavs MEINKEY --debug ipc Welchen Socket hast Du auf dem Server geforwarded? Falls ein /var/run/user/NNNN existiert wird der socket darunter erwartet und nicht in ~/.gnupg/ (wg. NFS etc). Testen mit gpgconf --list-dirs und es sollte besser kein gpg-agent auf dem Server laufen. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 227 bytes Beschreibung: nicht verfügbar URL : From wk at gnupg.org Mon May 27 17:17:18 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 May 2019 17:17:18 +0200 Subject: Frage bzgl. gpg-agent In-Reply-To: <20190527073459.c6tl33jlnernlbup@russet.rince.de> (Hanno Wagner's message of "Mon, 27 May 2019 09:34:59 +0200") References: <20190520201505.fdeac4ugsrn6jtaa@russet.rince.de> <87woiklydp.fsf@wheatstone.g10code.de> <20190527073459.c6tl33jlnernlbup@russet.rince.de> Message-ID: <874l5glyf5.fsf@wheatstone.g10code.de> On Mon, 27 May 2019 09:34, wagner at rince.de said: > rince at serverA:$ gpg-connect-agent 'getinfo restricted' /bye > ERR 67108865 Allgemeiner Fehler Du bist _nicht_ im restricted mode; also lokal verbunden. OK (kein Fehler) kommt zurück, wenn Du im resticted Mode wärst. > Leider finde ich nirgendwo was die Fehlernummer bedeutet... > Auf dem Client kriege ich interessanterweise dieselbe Fehlermeldung. Klar. >> $ echo >>./gnupg/gpg-agent.conf 'socket://' >> $ echo >>./gnupg/gpg-agent.conf 'debug ipc' >> $ echo >>./gnupg/gpg-agent.conf 'verbose' >> $ gpgconf --reload gpg-agent > > bei meinem gpg wird socket:// in der Config als fehlerhaft angesehen. > gpg auf dem Laptop (kali-linux): Wird seit 2.1.16 unterstüzt, sollte also gehen. Bist Du sicher, das die richtige gpg Version aufrufst. Schau mal direkt in die gpg-agent.conf; dort sollte sich socket:// debug ipc verbose finden. Ruf auch mal so auf $ gpg-agent --debug ipc gpg-agent[26062]: reading options from '/home/wk/.gnupg/gpg-agent.conf' gpg-agent[26062]: gpg-agent running and available Damit es auch wirklich klar, ist welche Configdatei gelesen wird. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 227 bytes Beschreibung: nicht verfügbar URL : From wk at gnupg.org Fri May 31 15:09:11 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 May 2019 15:09:11 +0200 Subject: Frage bzgl. gpg-agent In-Reply-To: <20190528123504.dzi6g4i5mxoo5pfs@russet.rince.de> (Hanno Wagner's message of "Tue, 28 May 2019 14:35:04 +0200") References: <20190520201505.fdeac4ugsrn6jtaa@russet.rince.de> <87woiklydp.fsf@wheatstone.g10code.de> <20190527073459.c6tl33jlnernlbup@russet.rince.de> <874l5glyf5.fsf@wheatstone.g10code.de> <20190528123504.dzi6g4i5mxoo5pfs@russet.rince.de> Message-ID: <87o93iydmw.fsf@wheatstone.g10code.de> On Tue, 28 May 2019 14:35, wagner at rince.de said: > "socket://" als ungültige Option in ~/.gnupg/gpg-agent.conf angesehen: Okay, jetzt aber mal aus meiner gpg-agent.conf kopiert --8<---------------cut here---------------start------------->8--- log-file socket:// --8<---------------cut here---------------end--------------->8--- Hatte ich das log-file vergessen? Hmmm. Sorry wegen der Verwirrung. --log-file ist die Option und socket:// ist das Argument zur Option. Da kannst Du einen Datei angeben, eine Socket log-file socket:///var/run/gnupg/WHATEVER oder aber die log-file socket:// als Abkürzung für echo log-file $(gpgconf --list-dirs socketdir)/S.log >> ~/.gnupg/gpg-agent.conf. Man kann auch log-file tcp://1.2.3.4:30000 angeben um über TCP zu loggen. (watchgnupg dann mit --tcp). Das ist zwar unverschlüsselt aber bequem um gpg auf Windows zu debuggen. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 227 bytes Beschreibung: nicht verfügbar URL :