From aheinecke at gnupg.org Mon Feb 1 12:32:03 2021 From: aheinecke at gnupg.org (Andre Heinecke) Date: Mon, 01 Feb 2021 12:32:03 +0100 Subject: Protect email experience not Subject:s (hypothesis, draft) In-Reply-To: <202101291752.32473.bernhard@intevation.de> References: <202101291752.32473.bernhard@intevation.de> Message-ID: <2745132.OPOr1PVihp@hopper> Hi, On Friday 29 January 2021 17:52:25 CET Bernhard Reiter wrote: > for many months now, my feeling is growing that > > encrypted subject headers in emails > shift the security balance in the wrong direction. I share that feeling. My goal that encrypted mails do not feel much different from unencrypted mails is made harder by subject encryption. So in a security VS. usability standpoint that assumes that if usability is bad, users will not encrypt mails or at least fewer mails I come to the same conclusion. This discussion is very relevant for me because GpgOL is starting to include protected-headers mime parts with the next version to transfer To and CC information. Putting the subject into it would be easy but it's more of a policy decision if we want to encourage or discourage this. > If it is understood that the header section is like notes > on a paper envelope, needed for mail transport and to be able to be seen by > the transporting agents, this can be used to assess what can be learned > from it. And then common ways of distracting from the contents can be used. > (I write 'common ways', because this is a core of my concept about how to > get end-to-end encryption - especially email - more usable: People already > know social ways how to deal with different levels of confidentiality. > Sofware application need not to hide it the aspects too much.) I agree with the mental image of notes on an envelope, this is also how I try to explain the Subject. We could probably try to explain this better. E.g. by showning this as information once the first encrypted mail is sent. > == Valid use cases? > Where the "Subject:" is a lot more than a writing on the envelope. > > * Example: a roundup-tracker fully run with OpenPGP/MIME mails, > by default it changes the title of an issue and there can be > commands to control the issue in the subject. (Also an example > where backwards compatiblity failed.) > > Implementation idea: per recipient (group) settings to explicitely > enable encrypted subjects for those groups and contexts where it is > known to be more useful. I'm not sure, if the user configures such rules by themself they already have an awareness that they don't really need automation for this. And if an Admin preconfigures this for a whole instiution we have the bad user expierence that the subject is "sometimes" encrypted. That would be even more confusion. Currently for GpgOL I'm tending to a global option to encrypt the subject which would be off by default and show a warning when it is activated that recipients will only see "..." in their message list and threading etc. will be broken. Just having the option and a warning related to the option could raise awareness about the issue. Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, B.Reiter, A.Heinecke Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Mon Feb 1 22:35:48 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 01 Feb 2021 22:35:48 +0100 Subject: Help with GPGME keylisting not listing signatures In-Reply-To: <2982267.ouH8jyFxom@t450> References: <806052122.0ifERbkFSE@t450> <3153371.sksYtiFmj9@breq> <2982267.ouH8jyFxom@t450> Message-ID: <2024452.Uo5b1BxaHC@breq> On Samstag, 30. Januar 2021 00:22:11 CET John Scott via Gnupg-users wrote: > On Saturday, January 23, 2021 10:39:30 AM EST Ingo Kl?cker wrote: > > Did you have a look at GPGME's tests as working example code? There is a > > test for listing signatures: > > https://dev.gnupg.org/source/gpgme/browse/master/tests/gpg/t-keylist-sig.c > > Thanks, I didn't see that. Except for the difference that I read the keys > from a gpgme_data_t connected to a stream instead of GnuPG's keyring, my > code seems to match up with the test's way of doing things. > > With the debugging information on the invocation of gpg doesn't look > abnormal, and trying in a fresh chroot gets me the same results, so it > seems as though getting detailed signature data from a gpgme_data_t may not > be possible. My example for testing is at > https://salsa.debian.org/-/snippets/519 You are using gpgme_op_keylist_from_data_start(). This effectively does gpg --with-colons --with-fingerprint --import-options import-show --dry-run --import -- From nn at copblock.app Thu Feb 4 10:34:35 2021 From: nn at copblock.app (nn at copblock.app) Date: Thu, 4 Feb 2021 09:34:35 +0000 Subject: Keyservers In-Reply-To: References: Message-ID: <20210204093435.GA46761@copblock.app> I would like to bring up my own keyserver for my company, which would contain only those keys which have been signed by one or more authorized people. Can anybody suggest software for this? sks-keyserver does not compile for me, and I don't know ocaml. mailvelope-keyserver fails its unit tests. Is there a howto? From wk at gnupg.org Thu Feb 4 16:53:37 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Feb 2021 16:53:37 +0100 Subject: Keyservers In-Reply-To: <20210204093435.GA46761@copblock.app> (nn's message of "Thu, 4 Feb 2021 09:34:35 +0000") References: <20210204093435.GA46761@copblock.app> Message-ID: <875z37subi.fsf@wheatstone.g10code.de> On Thu, 4 Feb 2021 09:34, nn at copblock.app said: > I would like to bring up my own keyserver for my company, which would > contain only those keys which have been signed by one or more authorized > people. I would suggest to use LDAP - best OpenLDAP or Active Directory. See https://gnupg.org/blog/20201018-gnupg-and-ldap.html and also check what updates we have in the GnuPG Git repo under doc/ldap/ . If you want a public server which can sync with other servers, https://github.com/hockeypuck is the way to go. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Tue Feb 9 17:31:44 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 09 Feb 2021 17:31:44 +0100 Subject: Protect email experience not Subject:s (hypothesis, draft) In-Reply-To: <202101291752.32473.bernhard@intevation.de> References: <202101291752.32473.bernhard@intevation.de> Message-ID: <3115751.44csPzL39Z@kymo.gruen> Am Freitag, 29. Januar 2021, 17:52:25 CET schrieb Bernhard Reiter: > From an implementers point of view, protected headers seem to make > it more complicated and break some ways to implement good access > to emails. As Thunderbird as enabled "encrypted" subjects by default with 78 and additionally did not offer a way to disable this initially, it created a number of real world examples. Thunderbird forced this change on users, according to this https://support.mozilla.org/en-US/questions/1304451 there is only a hidden (expert) setting to disable it since 78.5.1. Mentioned drawback: * Breaks filtering for the using company. " It's very important for mail filtering rules to be able to read the subject without opening the mail first." Best Regards, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From phill at thesusis.net Tue Feb 9 19:53:52 2021 From: phill at thesusis.net (Phillip Susi) Date: Tue, 09 Feb 2021 13:53:52 -0500 Subject: pinetry and emacs Message-ID: <87k0rhvza7.fsf@vps.thesusis.net> I have installed the pinetry module and run M-x pinentry-start, as well as added allow-emacs-pinentry to ~/.gnupg/gpg-agent.conf, yet whenever I try signing an email in mu4e, pinentry gets into a fight with emacs over the tty and everything goes all fscked up. Why is this? Why does pinentry still try to take over the terminal instead of contacting emacs? For that matter, why can both programs fight over it? I thoguht only one process group was the foreground group, and only that process group could read input from the tty. Instead it seems like both programs are reading some of the input and so I can't get emacs to switch buffers, nor pinentry to enter the correct password, nor cancel. I'm on Ubuntu 20.04 with pinentry 1.1.0 and emacs 26.3. From x10an14 at gmail.com Tue Feb 9 21:33:28 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Tue, 9 Feb 2021 21:33:28 +0100 Subject: pinetry and emacs In-Reply-To: <87k0rhvza7.fsf@vps.thesusis.net> References: <87k0rhvza7.fsf@vps.thesusis.net> Message-ID: Have you tried checking with update-alternatives which pinentry is default selected? I remember having to switch mine from pinentry-gnome to pinentry-tty on my machine (I don't use emacs though). On Tue, Feb 9, 2021 at 9:22 PM Phillip Susi wrote: > I have installed the pinetry module and run M-x pinentry-start, as well > as added allow-emacs-pinentry to ~/.gnupg/gpg-agent.conf, yet whenever I > try signing an email in mu4e, pinentry gets into a fight with emacs over > the tty and everything goes all fscked up. Why is this? Why does > pinentry still try to take over the terminal instead of contacting > emacs? For that matter, why can both programs fight over it? I thoguht > only one process group was the foreground group, and only that process > group could read input from the tty. Instead it seems like both > programs are reading some of the input and so I can't get emacs to > switch buffers, nor pinentry to enter the correct password, nor cancel. > > I'm on Ubuntu 20.04 with pinentry 1.1.0 and emacs 26.3. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From phill at thesusis.net Tue Feb 9 21:55:56 2021 From: phill at thesusis.net (Phillip Susi) Date: Tue, 09 Feb 2021 15:55:56 -0500 Subject: pinetry and emacs In-Reply-To: References: <87k0rhvza7.fsf@vps.thesusis.net> Message-ID: <87zh0dlztq.fsf@vps.thesusis.net> Christian Chavez writes: > Have you tried checking with update-alternatives which pinentry is default > selected? > I remember having to switch mine from pinentry-gnome to pinentry-tty on my > machine (I don't use emacs though). It was pinentry-curses. I tried switching to pinentry-tty and it rapes the tty even worse than the curses one. At least some keystrokes occasionally had some effect with the curses one. With This one nothing I hit would do anything. Couldn't get it to eventually think I entered a wrong password and give up, couldn't C-c, C-g, or C-z; I just had to use ~. to force ssh to hang up. Why and how is this program so abusive of the terminal? From beatrice76.sd at gmail.com Thu Feb 11 01:50:21 2021 From: beatrice76.sd at gmail.com (Socorro Beatrice Dominguez) Date: Wed, 10 Feb 2021 18:50:21 -0600 Subject: No subject Message-ID: amoffapu SOCORRO BEATRICE DOMINGUEZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From beatrice76.sd at gmail.com Thu Feb 11 02:02:24 2021 From: beatrice76.sd at gmail.com (Socorro Beatrice Dominguez) Date: Wed, 10 Feb 2021 19:02:24 -0600 Subject: List Message-ID: SOCORRO BEATRICE DOMINGUEZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From phill at thesusis.net Thu Feb 11 17:32:57 2021 From: phill at thesusis.net (Phillip Susi) Date: Thu, 11 Feb 2021 11:32:57 -0500 Subject: pinetry and emacs In-Reply-To: <87zh0dlztq.fsf@vps.thesusis.net> References: <87k0rhvza7.fsf@vps.thesusis.net> <87zh0dlztq.fsf@vps.thesusis.net> Message-ID: <87czx61s1z.fsf@vps.thesusis.net> Phillip Susi writes: > It was pinentry-curses. I tried switching to pinentry-tty and it rapes > the tty even worse than the curses one. At least some keystrokes > occasionally had some effect with the curses one. With This one nothing > I hit would do anything. Couldn't get it to eventually think I entered > a wrong password and give up, couldn't C-c, C-g, or C-z; I just had to > use ~. to force ssh to hang up. Why and how is this program so abusive > of the terminal? Weird... I ran strace on the program from another terminal and could see that it was reading each keystroke, but continued to read after seeing the \r. I hit C-j ( \n ) and it finally recognized the end of input. I'm thinking that it requires that tty mode that appends a \n to a \r to be enabled, but it doesn't bother enabling it when it takes over the tty. From cmoullia at redhat.com Thu Feb 11 18:24:24 2021 From: cmoullia at redhat.com (Charles Moulliard) Date: Thu, 11 Feb 2021 18:24:24 +0100 Subject: gpg: [don't know]: invalid packet (ctb=00) Message-ID: Hi We experience a very weird problem when the following command is executed on macos using gpg 2.2.27 (installed by homebrew tool). echo "xxxxxxx" | gpg --batch --yes --passphrase-fd 0 --local-user 4BD5F787F27F97744BC09E019C1CA69653E98E56 --armor --detach-sign --no-default-keyring --secret-keyring secring.gpg --keyring pubring.gpg --homedir 50_ReleaseBOMUpstream/.gnupg -output dummy.txt.asc dummy.txt gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/Users/cmoullia/.jenkins/workspace/50_ReleaseBOMUpstream/.gnupg/secring.gpg' to gpg-agent gpg: [don't know]: invalid packet (ctb=00) gpg: read_block: read error: Invalid packet gpg: import from '/Users/cmoullia/.jenkins/workspace/50_ReleaseBOMUpstream/.gnupg/secring.gpg' failed: Invalid keyring gpg: skipped "4BD5F787F27F97744BC09E019C1CA69653E98E56": No secret key gpg: signing failed: No secret key Do you know what is the problem ("gpg: [don't know]: invalid packet (ctb=00)")and how to fix it ? Cheers Charles Moulliard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at eckner.net Fri Feb 12 11:44:33 2021 From: gnupg at eckner.net (Erich Eckner) Date: Fri, 12 Feb 2021 11:44:33 +0100 (CET) Subject: export-filter question or bug Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm using the following command to export keys for wkd: $GPG --export --export-filter keep-uid="mbox = $mbox" $fpr However, this creates funny results for the key for buildmaster at archlinux32.org which is downloadable here: https://archlinux32.org/keys.php?k=2E29129B8C684FE7A959C422714A1770ECE2DF62 Is my filtering wrong or is this some bug in gpg? To reproduce the issue, run: tmp_dir=$(mktemp -d) GPG='gpg --homedir '"$tmp_dir" curl 'https://archlinux32.org/keys.php?k=2E29129B8C684FE7A959C422714A1770ECE2DF62' | $GPG --import $GPG --export --export-filter keep-uid="mbox = buildmaster at archlinux32.org" 2E29129B8C684FE7A959C422714A1770ECE2DF62 | gpg this gives: pub rsa4096 2017-06-23 [SC] [expired: 2019-06-23] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid buildmaster sub rsa4096 2017-06-23 [S] [expired: 2021-12-31] (note the expired pub, thus the whole key is considered expired) However, skipping the --export-filter: $GPG --export 2E29129B8C684FE7A959C422714A1770ECE2DF62 | gpg gives the correct expiration: pub rsa4096 2017-06-23 [SC] [expires: 2021-12-31] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid buildmaster uid archlinux32 repository signing key sub rsa4096 2017-06-23 [S] [expires: 2021-12-31] This is not usable for wkd for me, because it contains all uids (of course). Thanks in advance, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAmXBMACgkQCu7JB1Xa e1rL3Q/8Doo2VqaXgZgJAPw3xK0CvF8VQc8GLW4krEDTQH6Wu70e7nYGxFeJyLgt pqmloRZHDbGBfAh35qIfO1eQZgoe9eyVQyriJcqG/BrW5H9Qk20KGUHhHD1yjupZ +8WAQXzbmapiZz5COBkp1AQlOXgjKWMMTWMPt1DyaOaUKvw6LfpU78nML7wY6rF5 r7VX5jwrEDQmdyuPrumCotuZZpNOPgdAtURO9YHGh9sbOSsuIh4jvxWPyLOiFLRO M9wmyVhDt7sDQzoyzKew5LJGqsXaJ+SaAbQszNnS5NYMWeoeZk9nJGKgUosWFhwi RWe9ADVo9JTJcivGT/u/DGIlUtYhIdCO3z87sNvON6o4Uh9twAJk+okR/X7EYcRu ZcVWp/HFqwqBGDKtnxw8TCvLFEHPmnnklaXBwZW0k1TQw1HbmdQoe5vHsJJoIx0s CGMD2/5NxDWZtRPs/hJMnERgX7n15VJgMVDPSMSeGGQUIibrmEO3Pggyy2xNmVeo x0Bhobi+zsUKluC78Jv/GHkSc1jJa0ioXQIU2Kf2/zfm9148NFtE3bWOiz/sqC19 n+SItHRN/qs4J8obNNX2T9pXbnOXQ9wAmA5rYxG/3lKyq0rCKfXAXlOFSXksabDG PI10H2boPeMLu+HlnRtuAOq5an70flwuvXlDWg3Ux8NY3vJ4eu0= =dzM2 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 12 14:31:58 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Feb 2021 14:31:58 +0100 Subject: export-filter question or bug In-Reply-To: (Erich Eckner via Gnupg-users's message of "Fri, 12 Feb 2021 11:44:33 +0100 (CET)") References: Message-ID: <87ft21mmy9.fsf@wheatstone.g10code.de> On Fri, 12 Feb 2021 11:44, Erich Eckner said: > $GPG --export --export-filter keep-uid="mbox = $mbox" $fpr gpg-wks-client does something similar but using "uid =" with a pre-checked UID in an import filter. It also uses import-options=import-export to process the keyblock without actually importing it. > $GPG --export --export-filter keep-uid="mbox = > buildmaster at archlinux32.org" 2E29129B8C684FE7A959C422714A1770ECE2DF62 > | gpg You should use | gpg --show-keys > pub rsa4096 2017-06-23 [SC] [expired: 2019-06-23] > 2E29129B8C684FE7A959C422714A1770ECE2DF62 > uid buildmaster > sub rsa4096 2017-06-23 [S] [expired: 2021-12-31] > > (note the expired pub, thus the whole key is considered expired) Please try with --show-keys instead of using the default action. > This is not usable for wkd for me, because it contains all uids (of > course). I am curious why you don't use gpg-wks-client for example with the --install-key command. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From pankaj at codeisgreat.org Fri Feb 12 10:55:53 2021 From: pankaj at codeisgreat.org (Pankaj Jangid) Date: Fri, 12 Feb 2021 15:25:53 +0530 Subject: pinetry and emacs In-Reply-To: <87czx61s1z.fsf@vps.thesusis.net> (Phillip Susi's message of "Thu, 11 Feb 2021 11:32:57 -0500") References: <87k0rhvza7.fsf@vps.thesusis.net> <87zh0dlztq.fsf@vps.thesusis.net> <87czx61s1z.fsf@vps.thesusis.net> Message-ID: Phillip Susi writes: >> It was pinentry-curses. I tried switching to pinentry-tty and it rapes >> the tty even worse than the curses one. At least some keystrokes >> occasionally had some effect with the curses one. With This one nothing >> I hit would do anything. Couldn't get it to eventually think I entered >> a wrong password and give up, couldn't C-c, C-g, or C-z; I just had to >> use ~. to force ssh to hang up. Why and how is this program so abusive >> of the terminal? > > Weird... I ran strace on the program from another terminal and could see > that it was reading each keystroke, but continued to read after seeing > the \r. I hit C-j ( \n ) and it finally recognized the end of input. > I'm thinking that it requires that tty mode that appends a \n to a \r to > be enabled, but it doesn't bother enabling it when it takes over the > tty. I faced the same issue when I started Emacs from virtual terminal window. But I do not get the issue when launching from directly GUI. I am on MacOS. From gnupg at eckner.net Sat Feb 13 11:37:39 2021 From: gnupg at eckner.net (Erich Eckner) Date: Sat, 13 Feb 2021 11:37:39 +0100 (CET) Subject: export-filter question or bug In-Reply-To: <87ft21mmy9.fsf@wheatstone.g10code.de> References: <87ft21mmy9.fsf@wheatstone.g10code.de> Message-ID: <7c593ba4-ad18-9544-2d17-d7211579885f@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 12 Feb 2021, Werner Koch wrote: > On Fri, 12 Feb 2021 11:44, Erich Eckner said: > >> $GPG --export --export-filter keep-uid="mbox = $mbox" $fpr > > gpg-wks-client does something similar but using "uid =" with a > pre-checked UID in an import filter. It also uses > import-options=import-export to process the keyblock without actually > importing it. Changing to "uid = ..." filter yields the same result. Same for adding "--import-options=import-export". But I'm also confused, why - --import-options should be relevant when exporting a key :-/ > >> $GPG --export --export-filter keep-uid="mbox = >> buildmaster at archlinux32.org" 2E29129B8C684FE7A959C422714A1770ECE2DF62 >> | gpg > > You should use > > | gpg --show-keys ok, noted. > > >> pub rsa4096 2017-06-23 [SC] [expired: 2019-06-23] >> 2E29129B8C684FE7A959C422714A1770ECE2DF62 >> uid buildmaster >> sub rsa4096 2017-06-23 [S] [expired: 2021-12-31] >> >> (note the expired pub, thus the whole key is considered expired) > > Please try with --show-keys instead of using the default action. Makes no difference. > >> This is not usable for wkd for me, because it contains all uids (of >> course). > > I am curious why you don't use gpg-wks-client for example with > the --install-key command. Well, for multiple reasons: First, it's not in $PATH, so I didn't see it, when 'ing ;-) Now, that I played around with gpg-wks-client, I cannot find a --homedir option to set the homedir of the keyring (I do not want to fill the wks's user keyring with all the installed keys). Assuming, I have the key in the gpg directory in $tmp_dir, what's the best way to get gpg-wks-client to read it from there? Only way I found, is exporting into a temporary file: $GPG --export 2E29129B8C684FE7A959C422714A1770ECE2DF62 > "$tmp_dir/key" gpg-wks-server --install-key "$tmp_dir/key" buildmaster at archlinux32.org Interesting thing: This also installes an expired key, while "$tmp_dir/key" looks ok: $ gpg --show-keys < "$tmp_dir/key" pub rsa4096 2017-06-23 [SC] [expires: 2021-12-31] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid archlinux32 repository signing key uid buildmaster sub rsa4096 2017-06-23 [S] [expires: 2021-12-31] $ gpg --show-keys < archlinux32.org/hu/z4eyw18p7a9p7c9owm78fj93mqkks6q3 pub rsa4096 2017-06-23 [SC] [expired: 2019-06-23] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid buildmaster sub rsa4096 2017-06-23 [S] [expired: 2021-12-31] Ah, yet another question: The difference between `gpg-wks-client - --install-key ...` and `gpg-wks-server --install-key ...` is quite opaque to me: With gpg-wks-client, I need to add "-C .", else it tries in openpgp/, but besides that, the options and result look rather identical to me. > > > Salam-Shalom, > > Werner regards, Erich -----BEGIN PGP SIGNATURE----- Comment: Topal (https://zircon.org.uk/topal/) iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAnrBoACgkQCu7JB1Xa e1pPHw/+N6zqijbSYsMZb/e5AHVdq4czvYy9+hoo087XIcr5214rB7BYfoM4lZMy NivAbrekYm1wHu4JZv420Yybn0wcSDGoQZZOv5LTJ2G8xz/1xBAWObQ5Hk6KJyTa cY4vzEYKTbhFMha48zLA1zKFzEM3Iqhq2xmziTcHRj8AgyOt8VlpZzdA1YgsOgdo eGnxY857CNUAJIXxTg6oVdUjr2ISTrkDinf8ZqpI5DncIatMS5dKKko0DBEkdR0m /kufwkntOR3PmhxkYw2Z+ThTlTEmhnxHHHxyLrVm30gJPDN9b/+ZyD4B5ShswGTm AtwjVi3nOL6oDfsHjQNq/EcbH/kdd44TLQLRXEzJ48SIAPnOvo3Y8K2diV00CdhC qdKFpT4Vh1HIdI7hivtqvj46kgN1jn+lUzYldXixldCMaYkFz7ibeoP/KSMscFs7 VtHF0U/Ipbj8fcwxRrSRkOpfgKALpZDO4+NO9j3V29pSPZk7UCvBeduxs4TG3Koa veC8m1v1QJleh2FdCz8ExSSrQi+py+uOFYt2XAflCG9fQzfLLF/02dQ9MrNxpbHU zhgp07BzqxNdH/rOV74OqbJ9S5a4aiMmzHwRWuEZafBDitWcsSw69J7K6kCrmpiV +zVTCDozeKstpb411cQhpiwSjyTOOKOtFjB/ThhpmLiQ+ljuhP4= =pSy7 -----END PGP SIGNATURE----- From phill at thesusis.net Sun Feb 14 00:25:10 2021 From: phill at thesusis.net (Phillip Susi) Date: Sat, 13 Feb 2021 18:25:10 -0500 Subject: pinetry and emacs In-Reply-To: References: <87k0rhvza7.fsf@vps.thesusis.net> <87zh0dlztq.fsf@vps.thesusis.net> <87czx61s1z.fsf@vps.thesusis.net> Message-ID: <87tuqflfc0.fsf@vps.thesusis.net> Pankaj Jangid writes: > I faced the same issue when I started Emacs from virtual terminal > window. But I do not get the issue when launching from directly GUI. I > am on MacOS. Even if you run emacs from a terminal emulator, as long as you are in a GUI environment, then the gui pinentry should be used afaik. I'm using a remote server via ssh so I'm restricted to the terminal. From pankaj at codeisgreat.org Sun Feb 14 05:39:37 2021 From: pankaj at codeisgreat.org (Pankaj Jangid) Date: Sun, 14 Feb 2021 10:09:37 +0530 Subject: pinetry and emacs In-Reply-To: <87tuqflfc0.fsf@vps.thesusis.net> (Phillip Susi's message of "Sat, 13 Feb 2021 18:25:10 -0500") References: <87k0rhvza7.fsf@vps.thesusis.net> <87zh0dlztq.fsf@vps.thesusis.net> <87czx61s1z.fsf@vps.thesusis.net> <87tuqflfc0.fsf@vps.thesusis.net> Message-ID: Phillip Susi writes: > Even if you run emacs from a terminal emulator, as long as you are in a > GUI environment, then the gui pinentry should be used afaik. I also think so. But I could not manage to configure it even after few attempts. I use Homebrew packages on this mac. On one older macbook I have recently installed packages using Ports system. And after installing GnuPG on that, I have noticed a GUI app pinentry-mac. Probably that will pop-up some kind of GUI for asking passphrase. I?ll update in this thread after trying that out. From andrewg at andrewg.com Sun Feb 14 17:38:55 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 14 Feb 2021 16:38:55 +0000 Subject: Cannot set trust on one identity Message-ID: I appear to have an ID on my longstanding key that I can't set to ultimate trust. I had this issue on my previous macbook, and after migrating to a new one the problem persists: ``` gpg> trust pub? rsa4096/0xFB73E21AF1163937 ???? created: 2013-07-02? expires: 2022-12-09? usage: SCA ???? trust: ultimate????? validity: ultimate ssb? rsa4096/0x6B09069314549D4B ???? created: 2013-07-02? expires: 2022-12-09? usage: E ???? card-no: 0005 00002ED9 ssb? rsa4096/0x5C1EC404D5906629 ???? created: 2015-04-26? expires: 2022-12-09? usage: S ???? card-no: 0005 00002ED9 ssb? rsa4096/0x85FDF561DA8C0C46 ???? created: 2015-04-26? expires: 2022-12-09? usage: A ???? card-no: 0005 00002ED9 [ultimate] (1). Andrew Gallagher [ultimate] (2)? Andrew Gallagher [ultimate] (3)? Andrew Gallagher [ultimate] (4)? Andrew Gallagher [ unknown] (5)* Andrew Gallagher Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) ? 1 = I don't know or won't say ? 2 = I do NOT trust ? 3 = I trust marginally ? 4 = I trust fully ? 5 = I trust ultimately ? m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y pub? rsa4096/0xFB73E21AF1163937 ???? created: 2013-07-02? expires: 2022-12-09? usage: SCA ???? trust: ultimate????? validity: ultimate ssb? rsa4096/0x6B09069314549D4B ???? created: 2013-07-02? expires: 2022-12-09? usage: E ???? card-no: 0005 00002ED9 ssb? rsa4096/0x5C1EC404D5906629 ???? created: 2015-04-26? expires: 2022-12-09? usage: S ???? card-no: 0005 00002ED9 ssb? rsa4096/0x85FDF561DA8C0C46 ???? created: 2015-04-26? expires: 2022-12-09? usage: A ???? card-no: 0005 00002ED9 [ultimate] (1). Andrew Gallagher [ultimate] (2)? Andrew Gallagher [ultimate] (3)? Andrew Gallagher [ultimate] (4)? Andrew Gallagher [ unknown] (5)* Andrew Gallagher gpg> ``` I appreciate that I can probably fix this by purging and reloading the key from a portable copy, but I'm curious what's going on here, as it appears to be a problem with this particular kbx/trustdb... ``` gpg (GnuPG/MacGPG2) 2.2.24 libgcrypt 1.8.7 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /Users/andrewg/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, ??????? CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ``` A From ondrejsynacek at fastmail.com Sun Feb 14 21:33:33 2021 From: ondrejsynacek at fastmail.com (=?utf-8?b?T25kxZllaiBTeW7DocSNZWs=?=) Date: Sun, 14 Feb 2021 21:33:33 +0100 Subject: pinentry will not ask me for passphrase Message-ID: Hello. I?m a mac user and I am using `pinentry-mac` via homebrew. The homebrew package links to repository for `pinentry` so that is why I am asking here (not sure if that specific port is maintained by somebody). I?m not sure what happened in past day or so but when I set `pinentry-program` in my `gpg-agent.conf` to value `pinentry-mac`, I?m never asked for passphrase anymore. It definitely used to work. I have tried restarting `gpg-agent` but I had not luck. If I delete `pinentry-program` from the config, I?m asked for passphrase. I believe if no `pinentry-program` is provided, `pinentry-tty` is the default (?). Can this be caused by some other settings on my system. Currently running macOS Catalina v10.15.7 Thank you. From ondrejsynacek at fastmail.com Mon Feb 15 16:23:38 2021 From: ondrejsynacek at fastmail.com (=?utf-8?q?Ond=C5=99ej_Syn=C3=A1=C4=8Dek?=) Date: Mon, 15 Feb 2021 16:23:38 +0100 Subject: pinentry will not ask me for passphrase In-Reply-To: <5BA2915C-8882-4242-B3D6-75EB155560AD@gpgtools.org> Message-ID: On Mon Feb 15, 2021 at 4:16 PM CET, Lukas Pitschl wrote: > Are you using the full path in your gpg-agent.conf? > `pinentry-program /usr/local/bin/pinentry-mac` Yes that is how I specified it, exactly like that. > You might also try calling `/usr/local/bin/pinentry-mac ?version` and > see if that correctly reports the version. That reports the following: ``` pinentry-mac (pinentry) 1.1.0 Copyright (C) 2016 g10 Code GmbH License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ``` I think that is the latest version, right? I still do not understand how specifying `pinentry-program` just overrides passphrase entirely. That's pretty dangerous I think. Or maybe I'm just misunderstood the way it's supposed to be used. From lukele at gpgtools.org Mon Feb 15 16:16:43 2021 From: lukele at gpgtools.org (Lukas Pitschl) Date: Mon, 15 Feb 2021 16:16:43 +0100 Subject: pinentry will not ask me for passphrase In-Reply-To: References: Message-ID: <5BA2915C-8882-4242-B3D6-75EB155560AD@gpgtools.org> Hi Ond?ej, > I?m not sure what happened in past day or so but when I set `pinentry-program` in my > `gpg-agent.conf` to value `pinentry-mac`, Are you using the full path in your gpg-agent.conf? `pinentry-program /usr/local/bin/pinentry-mac` You might also try calling `/usr/local/bin/pinentry-mac ?version` and see if that correctly reports the version. Best, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Feb 17 09:41:31 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Feb 2021 09:41:31 +0100 Subject: [Announce] Libgcrypt 1.9.2 relased Message-ID: <874kibkrwk.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.9.2. This is a maintenance release. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.9.2 ===================================== * Bug fixes: - Fix build problem for macOS in the random code. [#5268] - Fix building with --disable-asm on x86. [#5277] - Check public key for ECDSA verify operation. [#5282] - Make sure gcry_get_config (NULL) returns a nul-terminated string. [8716e4b2ad] - Fix a memory leak in the ECDH code. [289543544e] - Fix a reading beyond end of input buffer in SHA2-avx2. [24af2a55d8] * Other features: - New test driver to allow for standalone regression tests. [b142da4c88] For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T5276 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.9.2.tar.bz2 you would use this command: gpg --verify libgcrypt-1.9.2.tar.bz2.sig libgcrypt-1.9.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.9.2.tar.bz2, you run the command like this: sha1sum libgcrypt-1.9.2.tar.bz2 and check that the output matches the first line from the this list: 29bd5d0a8f674d4521167dd518ef99b26d1e8f27 libgcrypt-1.9.2.tar.bz2 a2972134c55870264a136b37d51836926e13ce60 libgcrypt-1.9.2.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T5276 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME, and Gpg4win. We like to thank all the nice people who are helping Libgcrypt, be it testing, coding, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG and Libgcrypt in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) rsa2048 2014-10-29 [expired: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Feb 17 11:37:55 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Feb 2021 11:37:55 +0100 Subject: pinentry will not ask me for passphrase In-Reply-To: (=?utf-8?B?Ik9uZMWZ?= =?utf-8?B?ZWogU3luw6HEjWVr?= via Gnupg-users"'s message of "Mon, 15 Feb 2021 16:23:38 +0100") References: Message-ID: <87pn0zj7y4.fsf@wheatstone.g10code.de> On Mon, 15 Feb 2021 16:23, Ond?ej Syn??ek said: > pinentry-mac (pinentry) 1.1.0 > Copyright (C) 2016 g10 Code GmbH FWIW: We do not provide a pinentry under that name. This must be a homebrew specific change which unfortunately is not reflected by the version number. The latest pinentry is 1.1.1, released a few weeks ago. Shalom-Salam, Werner -- g10 Code GmbH https://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ondrejsynacek at fastmail.com Wed Feb 17 11:52:38 2021 From: ondrejsynacek at fastmail.com (=?utf-8?q?Ond=C5=99ej_Syn=C3=A1=C4=8Dek?=) Date: Wed, 17 Feb 2021 11:52:38 +0100 Subject: pinentry will not ask me for passphrase In-Reply-To: <87pn0zj7y4.fsf@wheatstone.g10code.de> Message-ID: On Wed Feb 17, 2021 at 11:37 AM CET, Werner Koch wrote: > FWIW: We do not provide a pinentry under that name. This must be a > homebrew specific change which unfortunately is not reflected by the > version number. I looked up `pinentry-mac` via Homebrew website[1] to see who is the maintainer or where I could find more info. >From the URL[2] I followed here to this mailing list. I guess them linking to `pinentry` is then wrong (?). Well I got my help here which is very much appreciated. [1] https://formulae.brew.sh/formula/pinentry-mac [2] https://github.com/GPGTools/pinentry From mail at lukemarlin.fr Thu Feb 18 22:35:16 2021 From: mail at lukemarlin.fr (Luke) Date: Thu, 18 Feb 2021 22:35:16 +0100 Subject: Handling an identity over multiple devices Message-ID: <98253940-7306-665d-2490-39fb77c523fe@lukemarlin.fr> Hi there, I've been using gpg on a basic level for some time now (signing commits, mails, using pass[1]) on different computers and phones, and have never cared much for tweaking as it seemed unnecessary. Now I've seen here and there that it would make more sense for me to use subkeys for devices, so that they all refer to the same identity (me). Reading this, it felt like the good, logical thing to do. Yet, after checking some existing threads of this mailing list through the archive system, it seems that if the subkey subject is brought up, the usual response is "just stick to gpg defaults and that's it". However, these threads usually involve a person that has a single device and looks for better security for this one device. Now in the case of multiple device, not using subkeys would mean creating different keypais, and different identities, which doesn't sound nice, right? [1] https://www.passwordstore.org/ From andrewg at andrewg.com Fri Feb 19 11:00:16 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 19 Feb 2021 10:00:16 +0000 Subject: Handling an identity over multiple devices In-Reply-To: <98253940-7306-665d-2490-39fb77c523fe@lukemarlin.fr> References: <98253940-7306-665d-2490-39fb77c523fe@lukemarlin.fr> Message-ID: <033bbceb-2d0a-df09-412b-9440dd1929b3@andrewg.com> Hi, Luke. My personal experience is that a hardware device such as an OpenPGP card or Yubikey is the easiest way to share the same private key across multiple devices (assuming you have physical access, see below). You designate one machine your master, where you store your original key material on disk as normal (this would typically be your "most secure" machine), and then copy your key (including any subkeys) to the hardware device for use on your other machines. To copy key material to a hardware device without deleting the master copy from disk, use the `keytocard` command of `gpg --edit-key`, but DO NOT SAVE, make sure instead to `quit` without saving. You may want to keep a backup of your .gnupg directory just in case. On your other machine, first get a copy of your public key (by whatever means: email, scp, keyservers...). Then plug in the hardware device and incant `gpg --card-status`. It should automatically associate the private key on your card/yubikey with your public key, and you're good to go. You can use the same card on as many machines as you like, or you can make multiple cards. Using a tamper-proof hardware device like this also ensures that you don't accidentally leave private key material somewhere you shouldn't (you should use a secure passphrase of course, but belt and braces never hurts). If you need to use gpg on a remote machine without physical access, it may be worth looking into agent forwarding. The UX is a little less mature than cards but I've got it successfully working on a couple of machines. Where agent forwarding tends to go wrong is if you use the same machine both via the physical terminal and remotely - switching easily between these modes remains a work in progress. A On 18/02/2021 21:35, Luke via Gnupg-users wrote: > Hi there, > > > I've been using gpg on a basic level for some time now (signing commits, > mails, using pass[1]) on different computers and phones, and have never > cared much for tweaking as it seemed unnecessary. Now I've seen here and > there that it would make more sense for me to use subkeys for devices, > so that they all refer to the same identity (me). Reading this, it felt > like the good, logical thing to do. Yet, after checking some existing > threads of this mailing list through the archive system, it seems that > if the subkey subject is brought up, the usual response is "just stick > to gpg defaults and that's it". However, these threads usually involve a > person that has a single device and looks for better security for this > one device. > > Now in the case of multiple device, not using subkeys would mean > creating different keypais, and different identities, which doesn't > sound nice, right? > > [1] https://www.passwordstore.org/ > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Fri Feb 19 11:33:01 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 19 Feb 2021 11:33:01 +0100 Subject: Handling an identity over multiple devices In-Reply-To: <98253940-7306-665d-2490-39fb77c523fe@lukemarlin.fr> References: <98253940-7306-665d-2490-39fb77c523fe@lukemarlin.fr> Message-ID: <5244859.45IGVdHu2k@breq> On Donnerstag, 18. Februar 2021 22:35:16 CET Luke via Gnupg-users wrote: > Now in the case of multiple device, not using subkeys would mean > creating different keypais, and different identities, which doesn't > sound nice, right? I think Andrew's suggestion to use a hardware token is good advice. I'm using an OpenPGP token with three subkeys (sign, encrypt, authenticate). The main key stays on one device, preferable offline. Back to your question. I don't think using different subkeys for different devices makes much sense. For encryption subkeys it makes no sense at all because almost all existing applications will encrypt only to a single subkey (typically the most recently created one). This means that only one of your devices will be able to decrypt something encrypted to you. For signing subkeys it makes little sense. Yes, it would allow you to replace the device-specific signing subkey in case the device is compromised. But I don't see an advantage over simply replacing a common signing subkey in case of a compromise. (Okay, one advantage would be that the replacement subkey only needs to be deployed on one device.) Using a hardware token is much better because it protects against compromise in the first place. For authentication subkeys it makes sense (unless you use a hard token) because this allows you for example to control which devices can ssh to which machines. But you could also use plain ssh keys for this. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From michaelof at rocketmail.com Fri Feb 19 12:06:11 2021 From: michaelof at rocketmail.com (michaelof at rocketmail.com) Date: Fri, 19 Feb 2021 12:06:11 +0100 Subject: Generic question: replication/sync between key servers, how long until published? References: Message-ID: Hi all, published a revocation cert for a very long used old 1024 bit key plus a newly created 4096 bit key to http://keys.gnupg.net/. Visible after some minutes. Now, four days later, both keys are still not visible on e.g. https://pgp.ocf.berkeley.edu Is this usually taking that long, or is something broken? Best Regards, Michael From andrewg at andrewg.com Fri Feb 19 13:10:27 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 19 Feb 2021 12:10:27 +0000 Subject: Generic question: replication/sync between key servers, how long until published? In-Reply-To: References: Message-ID: On 19/02/2021 11:06, michaelof--- via Gnupg-users wrote: > Hi all, > > published a revocation cert for a very long used old 1024 bit key plus a newly created 4096 bit key to http://keys.gnupg.net/. Visible after some minutes. > Now, four days later, both keys are still not visible on e.g. https://pgp.ocf.berkeley.edu > > Is this usually taking that long, or is something broken? keys.gnupg.net doesn't exist (tested from several locations): ``` Host keys.gnupg.net not found: 3(NXDOMAIN) ``` These days, it's probably safest to publish your key to as many keyservers as you can. If they sync eventually, great. But the sync process is nowhere near as reliable as it used to be, and probably shouldn't be depended upon. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From michaelof at rocketmail.com Fri Feb 19 14:13:46 2021 From: michaelof at rocketmail.com (michaelof at rocketmail.com) Date: Fri, 19 Feb 2021 14:13:46 +0100 Subject: Generic question: replication/sync between key servers, how long until published? In-Reply-To: References: Message-ID: Am 19.02.21 um 13:10 schrieb Andrew Gallagher via Gnupg-users: > On 19/02/2021 11:06, michaelof--- via Gnupg-users wrote: >> Hi all, >> >> published a revocation cert for a very long used old 1024 bit key plus a newly created 4096 bit key to http://keys.gnupg.net/. Visible after some minutes. >> Now, four days later, both keys are still not visible on e.g. https://pgp.ocf.berkeley.edu >> >> Is this usually taking that long, or is something broken? > > keys.gnupg.net doesn't exist (tested from several locations): > > ``` > Host keys.gnupg.net not found: 3(NXDOMAIN) > ``` > > These days, it's probably safest to publish your key to as many keyservers as you can. If they sync eventually, great. But the sync process is nowhere near as reliable as it used to be, and probably shouldn't be depended upon. > > Thanks, Andrew, will follow your suggestion and upload to as many key servers as I'll find :) No idea why you've got the NXDOMAIN answer for keys.gnupg.net, but it seems that it been offline today, maybe that's why. Now it's online, again, and you are getting DNS feedback: $ host keys.gnupg.net keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net. hkps.pool.sks-keyservers.net has address 209.244.105.201 I've used usually pgp.mit.edu, but it's very slow, currently but for a while now. From gnupg at eckner.net Tue Feb 23 13:37:38 2021 From: gnupg at eckner.net (Erich Eckner) Date: Tue, 23 Feb 2021 13:37:38 +0100 (CET) Subject: export-filter question or bug In-Reply-To: <7c593ba4-ad18-9544-2d17-d7211579885f@eckner.net> References: <87ft21mmy9.fsf@wheatstone.g10code.de> <7c593ba4-ad18-9544-2d17-d7211579885f@eckner.net> Message-ID: <6282a431-d046-cbcc-c5d0-a4f27093dcdd@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I wanted to ask for help regarding this wkd-key-installation issue I had, once more. Whichever way I try, I always end up with an expired key being installed into wkd, although the key file looks all-right to me: $ gpg --show-keys --with-wkd-hash $tmp_dir/key pub rsa4096 2017-06-23 [SC] [expires: 2021-12-31] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid archlinux32 repository signing key 5s69opjiwx4q8z87mmkdaiiyizf5jkpt at archlinux32.org uid buildmaster z4eyw18p7a9p7c9owm78fj93mqkks6q3 at archlinux32.org sub rsa4096 2017-06-23 [S] [expires: 2021-12-31] $ /usr/lib/gnupg/gpg-wks-client -C . --install-key "$tmp_dir/key" buildmaster at archlinux32.org gpg-wks-client: key 2E29129B8C684FE7A959C422714A1770ECE2DF62 published for 'buildmaster at archlinux32.org' $ gpg --show-keys archlinux32.org/hu/z4eyw18p7a9p7c9owm78fj93mqkks6q3 pub rsa4096 2017-06-23 [SC] [expired: 2019-06-23] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid buildmaster sub rsa4096 2017-06-23 [S] [expired: 2021-12-31] Instead of `gpg-wks-client --install-key`, I also tried `gpg-wks-server - --install-key` and `gpg --export --exportfilter keep-uid="uid=buildmaster "`. What am I doing wrong? Or is there something special about this key? The key can be found here: https://archlinux32.org/keys.php?k=2E29129B8C684FE7A959C422714A1770ECE2DF62 regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmA09xMACgkQCu7JB1Xa e1oNbQ//aBqnPH6yw+Fp6z1+0q73Xkg0cNgxIXgvxZKV+9imYadIKWyc1CRpVsG9 EuvSff3d5R9oxol6AIRzo3/ny0khm/CYuHr5TAmQlu8byQn4n7YK6J34m5ul9m6J P3E7ShbmnLTdfGW7nY2jc5V1DdGNo+Rgyb6rughxULW/IeqFFQyyvKUv/XCenlKB I2J6i/N7GYzdKmjFtei4qggvmAlMfktWeHZ12BysOxyroMnyjLlTCVReBk5mcUqJ BZkGhiprHlx8bZRQ/ZPYZZ4RJI+KoxkKTrpeasu6fkjdSONFf0I4KiyMA9GzJArq QX40PYPR7Jb6FrKTm6JqlNvhZqpPkCoNoyP0TVUUPN53TL/we/9rky/KGPcYXcjy YYXOG26HQlGWIbQIUoqHaztT2Kp17WM90ENRRk3ZYYM06t4bwWPxjxdzBsi8FK/w b9dvbMACnI3kYmB+hiFCsFUgJPCrGJ1RSpGIU7/PpMKQQFC7agxj5cJz+mEtHaAJ 3qzHtd4xVjaWYURqvAhfgkwBEZlOgzOEn8c5S7gLGfSHo+L5EwpDxkmSWsbOvTwR /jM2FnZyIfNFnKGUSVKp7iU8nYUswMqOvFLQ1DCSmd8EFpcohdARPY8BTwC3r+T4 tFaPvPTj3fJ1BF1zXchVF/XAFlw0q5S5M5/kT4+zyYp2niyQDpc= =ud5u -----END PGP SIGNATURE----- From wk at gnupg.org Tue Feb 23 18:07:33 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 18:07:33 +0100 Subject: export-filter question or bug In-Reply-To: <6282a431-d046-cbcc-c5d0-a4f27093dcdd@eckner.net> (Erich Eckner via Gnupg-users's message of "Tue, 23 Feb 2021 13:37:38 +0100 (CET)") References: <87ft21mmy9.fsf@wheatstone.g10code.de> <7c593ba4-ad18-9544-2d17-d7211579885f@eckner.net> <6282a431-d046-cbcc-c5d0-a4f27093dcdd@eckner.net> Message-ID: <87eeh6g1be.fsf@wheatstone.g10code.de> On Tue, 23 Feb 2021 13:37, Erich Eckner said: > What am I doing wrong? Or is there something special about this key? Nothing. It is an interesting case. Let's have a look at key exported without any options (listing slightly edited): $ gpg --show-keys --with-sig-check c.pub pub rsa4096 2017-06-23 [SC] [expires: 2021-12-31] 2E29129B8C684FE7A959C422714A1770ECE2DF62 uid [...] sig 3 714A1770ECE2DF62 2021-01-25 [...] uid [...] sig 3 714A1770ECE2DF62 2017-06-23 [...] sub rsa4096 2017-06-23 [S] [expires: 2021-12-31] FD45993ACA052203886D618205CDEE5C356A46AD sig 714A1770ECE2DF62 2021-01-25 [...] What we see is a key with two user ids. The self-signatures binding the user ids to the key carry important information, for example the expiration date. If we look close at the self-signatures using --list-packets we see: :user ID packet: "[...] " :signature packet: algo 1, keyid 714A1770ECE2DF62 version 4, created 1498203061, md5len 0, sigclass 0x13 [...] hashed subpkt 9 len 4 (key expires after 2y0d0h0m) [...] Adding this expiration value to the key creation time yields 2019-06-17 and thus the key would be expired. :user ID packet: "[...] " :signature packet: algo 1, keyid 714A1770ECE2DF62 version 4, created 1611599717, md5len 0, sigclass 0x13 [...] hashed subpkt 9 len 4 (key expires after 4y192d3h29m) [...] Adding this expiration value to the key creation time yields 2021-12-31 and thus the key would be valid. The actual used key expiration date is the latest one seen in user id self-signaturres, thus in out case 2021-12-31. Now if we export just one user id as done by gpg-wks-client gpg --no-options -v --batch --status-fd=2 --always-trust --armor \ --export-options=export-minimal \ --export-filter 'keep-uid=mbox= buildmaster at archlinux32.org' --export -- 2E29129B8C684FE7A959C422714A1770ECE2DF62 We get a key with the buildmaster@ user id and thus the latest expiration date is 2019-06-17. This is because the other user id and its self-signature has been stripped. Sure, this could be considered a bug in export-minimal but fixing this would require to create a new self-signature for the exported user id which then requires the private key and would even more confuse. I am not sure how to solve it but it needs to be solved at least for gpg-wks-client. See https://dev.gnupg.org/T5323 You may simply want to change the expiration date of the key which, in contrast to "adduid" updates all self-signatures. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From doug at rekt.email Tue Feb 23 19:47:09 2021 From: doug at rekt.email (Doug Richardson) Date: Tue, 23 Feb 2021 18:47:09 +0000 Subject: gpg --card-status fails with Yubikey 5 under MSYS2 Message-ID: Under MSYS2, gpg --card-status fails with the following when trying to use a Yubikey 5 NFC. $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device This same command works when using Gpg4Win's gpg. This leads me to believe it's a configuration issue with MSYS2's gpg, but I'm not familiar enough with gpg to know where the problem might be. I'd appreciate any advice as to where the problem is likely to be. For more detail, see the MSYS2 bug report: https://github.com/msys2/MSYS2-packages/issues/2329 Thanks, Doug From wk at gnupg.org Tue Feb 23 22:12:10 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 22:12:10 +0100 Subject: gpg --card-status fails with Yubikey 5 under MSYS2 In-Reply-To: (Doug Richardson via Gnupg-users's message of "Tue, 23 Feb 2021 18:47:09 +0000") References: Message-ID: <874ki2fpzp.fsf@wheatstone.g10code.de> On Tue, 23 Feb 2021 18:47, Doug Richardson said: > Under MSYS2, gpg --card-status fails with the following when trying to GnuPG is not intended to be build under MSYS. You need to cross-build from a real POSIX system using mingw. All other ways to build it are not supported and are strongly discouraged. Sorry. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 24 11:07:54 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Feb 2021 11:07:54 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <7889404e-b5b2-3d74-6b3e-efb86ffa5a97@eckner.net> (Erich Eckner via Gnupg-users's message of "Fri, 22 Jan 2021 20:59:10 +0100 (CET)") References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> <87h7n93wum.fsf@wheatstone.g10code.de> <7889404e-b5b2-3d74-6b3e-efb86ffa5a97@eckner.net> Message-ID: <87k0qxeq2t.fsf@wheatstone.g10code.de> On Fri, 22 Jan 2021 20:59, Erich Eckner said: > Thank you for your time! For everyone to benefit from my problem, I'd like > to suggest to clarify in the documentation, that and how tor will be I'll change the option description to: --use-tor --no-use-tor The option --use-tor switches Dirmngr and thus GnuPG into ``Tor mode'' to route all net? work access via Tor (an anonymity network). Certain other features are disabled in this mode. The effect of --use-tor cannot be overridden by any other command or even by reloading dirmngr. The use of --no-use-tor disables the use of Tor. The default is to use Tor if it is available on startup or after reloading dirmngr. The test on the avail? able of Tor is done by trying to connects to a SOCKS proxy at either port 9050 or 9150); if another type of proxy is listening on one of these ports, you should use --no-use-tor. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at eckner.net Wed Feb 24 12:40:29 2021 From: gnupg at eckner.net (Erich Eckner) Date: Wed, 24 Feb 2021 12:40:29 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <87k0qxeq2t.fsf@wheatstone.g10code.de> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> <87h7n93wum.fsf@wheatstone.g10code.de> <7889404e-b5b2-3d74-6b3e-efb86ffa5a97@eckner.net> <87k0qxeq2t.fsf@wheatstone.g10code.de> Message-ID: <1293ef9-a1a4-ae34-8de5-9c887f852b6@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On Wed, 24 Feb 2021, Werner Koch wrote: > On Fri, 22 Jan 2021 20:59, Erich Eckner said: > >> Thank you for your time! For everyone to benefit from my problem, I'd like >> to suggest to clarify in the documentation, that and how tor will be > > I'll change the option description to: thanks, again, just a minor typo: > > --use-tor > --no-use-tor > > The option --use-tor switches Dirmngr and thus GnuPG into ``Tor > mode'' to route all net? work access via Tor (an anonymity network). > Certain other features are disabled in this mode. The effect of > --use-tor cannot be overridden by any other command or even by > reloading dirmngr. The use of --no-use-tor disables the use of Tor. > The default is to use Tor if it is available on startup or after > reloading dirmngr. The test on the avail? able of Tor is done by > trying to connects to a SOCKS proxy at either port 9050 or 9150); if - - reloading dirmngr. The test on the avail? able of Tor is done by - - trying to connects to a SOCKS proxy at either port 9050 or 9150); if + reloading dirmngr. The test on the avail? ability of Tor is done by + trying to connect to a SOCKS proxy at either port 9050 or 9150); if > another type of proxy is listening on one of these ports, you should > use --no-use-tor. > > > > Shalom-Salam, > > Werner > regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmA2Oy8ACgkQCu7JB1Xa e1oIkBAAknFv699JQJY/axHlXwWZxtF+70kqEvHgg4uc/DfZ1u4xJcwP7umJz6v5 +SIT0QJCxfe6h/lSRADyfurXnYHBH5k3Bxucnc0EPw/c1dasvxOyYg9q6tfENF38 HQl6g8LYHBXqdm4qUDGxEwAEnoH8XJTL90lE/1dFInQtJMPF9giSvlvJVtxLBv44 QYwhi814kh+tzwgAC54QhAFIOuEKOWSIV0mwhcr81/vIo0LNszzc2NPsMzOjQYwB niEpyCcj69RGNzDxjYvIa5I4hjz3SecuJrqGosgi1l/hRWquEZSMn6Gs6tuNn2iV Ka1oduf2bjUP7kZcQOPVUnwdx1nEPaREC5OgAMm3rhy5Qv6aXz52t8wNlQzFmyvS 7uHq2xx29WCscY79y7vaYIvO75bBynOR5t6/AIyPIgTdvQDWcTabK79HZAgpzZH2 QfZqlT/yPLRRN9kqkhyp3jN/i7Zm5I5GX1tw3sFYKQRv0D5NCTkGwxh0Ry2OS6Hh JMqXINZU/AqtSsZE8NtMnYipGMBvA50tBIgjuJozBJNS/cWloLLpeo+P/EVSUGYM Mh66VztyVTu+/b9wjoY0g6deVj049M/JljkETMUZyrQ6iQOJ9p51D5bkYg1qimNj jm8+oxnM4bqV0nBPqRswfsHxqtM9A9Oj2K2XxfOk/D/bgA+Vfic= =+Z6P -----END PGP SIGNATURE----- From jsmith9810 at gmx.com Fri Feb 26 20:14:06 2021 From: jsmith9810 at gmx.com (jsmith9810 at gmx.com) Date: Fri, 26 Feb 2021 20:14:06 +0100 Subject: New packet format for OpenPGP Message-ID: Hello, I noticed that GnuPG (I'm using v2.2.19) still uses the old format OpenPGP packets, when I export my keys, for example. Is there a way I can make it use the new format instead (and possibly make it default)? It does understand the new format, I just can't seem to find the option to enforce its use. Also, is it possible to use a private keyring (secring.gpg) for decryption without importing it? I recall it used to be possible to do this with the earlier versions by specifying the keyring path in gpg.conf, but I can't figure out how to do it now. Thanks! From wk at gnupg.org Sat Feb 27 16:56:23 2021 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Feb 2021 16:56:23 +0100 Subject: New packet format for OpenPGP In-Reply-To: (jsmith's message of "Fri, 26 Feb 2021 20:14:06 +0100") References: Message-ID: <87k0qta4ig.fsf@wheatstone.g10code.de> On Fri, 26 Feb 2021 20:14, jsmith9810--- said: > I noticed that GnuPG (I'm using v2.2.19) still uses the old format > OpenPGP packets, when I export my keys, for example. That is perfectly fine - no need to chnage this. > Also, is it possible to use a private keyring (secring.gpg) for > decryption without importing it? No. Since 2.1 there is no more secring.gpg; instead gnupg uses one file per private key. You find these files under ~/.gnupg/private-keys-v1.d and their format is stable. To get the name of the file run gpg -k --with-keygrip USERIDORFINGERPRINT and use the printed keygrip. Use --with-colons for scripts and see doc/DETAILS to see how the keygrip is printed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: