From wk at gnupg.org Tue Oct 1 12:15:56 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2024 12:15:56 +0200 Subject: Upgrade woes In-Reply-To: <87bk098c3k.fsf@vps.thesusis.net> (Phillip Susi's message of "Fri, 27 Sep 2024 09:23:11 -0400") References: <87v7yjl9gj.fsf@vps.thesusis.net> <87r096wmln.fsf@jacob.g10code.de> <87bk098c3k.fsf@vps.thesusis.net> Message-ID: <87h69wuo0z.fsf@jacob.g10code.de> On Fri, 27 Sep 2024 09:23, Phillip Susi said: > Then how do you convince the agent to work in a chroot? At first it > just keep saying inappropriate ioctl for the device. I tried bind > mounting /sys, /proc, /dev, and /dev/pts into the chroot and it changed /var/run/user might also be a good idea. Instead of doing a chroot you may want to run the agent under different user and use the extra-socket feature. This will be quite some work to get it working but it better secures your private keys than a chroot. You may want to first tell us your goals and then we can see how it can be achieved. "running in a chroot" is nopt specific enough for useful help. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 1 12:21:51 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2024 12:21:51 +0200 Subject: Concerns regarding T3065 dirmngr: proxy issues with dnslookup causing failure In-Reply-To: (=?utf-8?B?Iuael+WNmuS7gUJ1by1yZW4=?= Lin via Gnupg-users"'s message of "Sun, 29 Sep 2024 02:48:45 +0800") References: Message-ID: <87cykkunr4.fsf@jacob.g10code.de> Hi! > gpg2 --keyserver hkps://keyserver.ubuntu.com --keyserver-options > "timeout=40 http-proxy=$http_proxy" --recv-keys > 409B6B1796C275462A1703113804BB82D39DC0E3 You should configure proxy settings and other keyserver options in dirmngr.conf and not on the gpg comnand line or conf file. > IMHO as the actual DNS resolution may not be available in a networking > environment that provides internet access over an HTTP proxy service, That is why we have our own resolver. The whole thing has been explained in the ticket and elsewhere. BTW, the entire keyserver thing is more or less useless these days because there is no proper working network of keyservers anymore. Use the Web Key Directory or ask for a signed initial mail to get the key. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 1 12:24:21 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2024 12:24:21 +0200 Subject: website charset encoding for manual In-Reply-To: <20240922085205.43f172b6@ryz.dorfdsl.de> (Marco Moock via Gnupg-users's message of "Sun, 22 Sep 2024 08:52:05 +0200") References: <20240922085205.43f172b6@ryz.dorfdsl.de> Message-ID: <878qv8unmy.fsf@jacob.g10code.de> On Sun, 22 Sep 2024 08:52, Marco Moock said: > https://gnupg.org/gph/de/manual/f20.html#AEN33 > doesn't seem to have any charset encoding information. Unfortunately the GPH is way to old to be useful. I also doubt that we have a working docbook toolchain availabale to build the GPH from source. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 1 12:39:25 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2024 12:39:25 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <87jzf8rujk.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Thu, 19 Sep 2024 09:07:11 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> Message-ID: <874j5wumxu.fsf@jacob.g10code.de> Hi! On Thu, 19 Sep 2024 09:07, Nils Schween said: > suffices to import the certificate. It is actually enough to increase > the value from 20 to 32. Here is the git diff of my change of minip12.c > (version 2.5.1 ) I looked at you patch and it should not cause any harm. Thus applied (even w/o a sample file). Thanks for trying to drill down on the cause for this problem. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Tue Oct 1 13:18:52 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 1 Oct 2024 13:18:52 +0200 Subject: Concerns regarding T3065 dirmngr: proxy issues with dnslookup causing failure In-Reply-To: <87cykkunr4.fsf@jacob.g10code.de> References: <87cykkunr4.fsf@jacob.g10code.de> Message-ID: On 1 Oct 2024, at 12:20, Werner Koch via Gnupg-users wrote: > > BTW, the entire keyserver thing is more or less useless these days > because there is no proper working network of keyservers anymore. This overstates the facts. Keyservers still exist and still work, with some caveats. See https://blog.pgpkeys.eu/state-keyservers-2024.html for details. tl;dr: you have to poll multiple keyservers to be sure to get the latest updates. A From rjh at sixdemonbag.org Tue Oct 1 18:14:58 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 1 Oct 2024 12:14:58 -0400 Subject: website charset encoding for manual In-Reply-To: <878qv8unmy.fsf@jacob.g10code.de> References: <20240922085205.43f172b6@ryz.dorfdsl.de> <878qv8unmy.fsf@jacob.g10code.de> Message-ID: <7a0eff87-c9ff-4c58-903e-a6c577769a42@sixdemonbag.org> > Unfortunately the GPH is way to old to be useful. I also doubt that we > have a working docbook toolchain availabale to build the GPH from > source. The FAQ is also increasingly out of date. Since I put it down years ago (as a protest against RMS' continued involvement in the Free Software movement) no one has touched it. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1E7A94D4E87F91D5.asc Type: application/pgp-keys Size: 1355 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From albrecht.dress at posteo.de Tue Oct 1 19:40:13 2024 From: albrecht.dress at posteo.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Tue, 01 Oct 2024 17:40:13 +0000 Subject: gpgsm unable to extract signers from a valid (?) signature Message-ID: Hi all, I stumbled over a S/MIME signed message where gpgsm seems to be unable to extract the signers and to verify the signature. Using the attached signature blob and a dummy ?message? part, gpgsm says just $ gpgsm --debug-level basic --verify SIG.bin dummy.txt gpgsm: enabled debug flags: ipc gpgsm: enabled compatibility flags: gpgsm: detached signature secmem usage: 0/16384 bytes in 0 blocks instead of printing the signer's data (date, key id). Higher debug levels don't provide more insight (to me, at least). The command does import the certificates into the key ring, though (try ?gpgsm --list-chain 0x3F239410?). The effect is not reproducible with other RSA+SHA256 signatures. OTOH, certtool *does* print the signature info $ certtool --p7-verify --inder --load-data dummy.txt < SIG.bin Loaded system trust (141 CAs available) eContent Type: 1.2.840.113549.1.7.1 Signers: Signer's issuer DN: CN=SwissSign RSA SMIME NCP ICA 2022 - 1,O=SwissSign AG,C=CH Signer's serial: 02dc760c692bf5e017f7dcdd4857ff674b7aa436 Signing time: Fri Sep 27 15:44:21 UTC 2024 Signature Algorithm: RSA-SHA256 Signature status: verification failed: Public key signature verification has failed. and Thunderbird is also able to verify the massage and to display the signature info. I use gpgsm coming with Debian Bookworm $ gpgsm --version gpgsm (GnuPG) 2.2.40 libgcrypt 1.10.1 libksba 1.6.3 Is this a mis-configuration of my system, or a limitation of a gpgsm (maybe a too old version)? Thanks in advance, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: SIG.bin Type: application/octet-stream Size: 9837 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Oct 2 08:46:47 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Oct 2024 08:46:47 +0200 Subject: website charset encoding for manual In-Reply-To: <7a0eff87-c9ff-4c58-903e-a6c577769a42@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Tue, 1 Oct 2024 12:14:58 -0400") References: <20240922085205.43f172b6@ryz.dorfdsl.de> <878qv8unmy.fsf@jacob.g10code.de> <7a0eff87-c9ff-4c58-903e-a6c577769a42@sixdemonbag.org> Message-ID: <87h69vt31k.fsf@jacob.g10code.de> On Tue, 1 Oct 2024 12:14, Robert J. Hansen said: > The FAQ is also increasingly out of date. Since I put it down years > ago (as a protest against RMS' continued involvement in the Free > Software movement) no one has touched it. However, technically we can easily add new stuff and adjust it for current versions. Thanks for the reminder and for all the work you put into the FAQ and your diligent help on this and other mailing lists. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From nils.schween at mpi-hd.mpg.de Wed Oct 2 09:13:55 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Wed, 02 Oct 2024 09:13:55 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <874j5wumxu.fsf@jacob.g10code.de> (Werner Koch's message of "Tue, 01 Oct 2024 12:39:25 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <874j5wumxu.fsf@jacob.g10code.de> Message-ID: <87frpf6kp8.fsf@mpi-hd.mpg.de> Thank you very much! That's great. Regards, Nils Schween Werner Koch writes: > Hi! > > On Thu, 19 Sep 2024 09:07, Nils Schween said: > >> suffices to import the certificate. It is actually enough to increase >> the value from 20 to 32. Here is the git diff of my change of minip12.c >> (version 2.5.1 ) > > I looked at you patch and it should not cause any harm. Thus applied > (even w/o a sample file). Thanks for trying to drill down on the cause > for this problem. > > > Salam-Shalom, > > Werner -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 2 09:19:04 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Oct 2024 09:19:04 +0200 Subject: gpgsm unable to extract signers from a valid (?) signature In-Reply-To: ("Albrecht =?utf-8?Q?Dre=C3=9F?= via Gnupg-users"'s message of "Tue, 01 Oct 2024 17:40:13 +0000") References: Message-ID: <87bk03t1jr.fsf@jacob.g10code.de> Hi! On Tue, 1 Oct 2024 17:40, Albrecht Dre? said: > and Thunderbird is also able to verify the massage and to display the > signature info. Running it with --audit-log FILE puts this info into FILE: * Data verification succeeded: No * Data available: Yes * Signature available: No * Included certificates: 5 * (#00BB401C43F55E4FB0/CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH) * (/CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH) * (#00B30511B116B4A056511D7C681F877D/CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH) * (/CN=SwissSign RSA SMIME Root CA 2022 - 1,O=SwissSign AG,C=CH) * (#796C0FD9724F3291C0083A1A6DEEC2670EB6DCA0/CN=SwissSign RSA SMIME Root CA 2022 - 1,O=SwissSign AG,C=CH) * (/CN=SwissSign RSA SMIME NCP ICA 2022 - 1,O=SwissSign AG,C=CH) * (#02DC760C692BF5E017F7DCDD4857FF674B7AA436/CN=SwissSign RSA SMIME NCP ICA 2022 - 1,O=SwissSign AG,C=CH) * (/CN=pseudo Kundenservice e regio,1.2.840.113549.1.9.1=#6B756E64656E7365727669636540652D726567696F2E6465,2.5.4.97=#4E545244452D444552333230312E48524135383834,O=e-regio GmbH & Co. KG,L=Euskirchen,ST=NW,C=DE) * (/) * (#02DC760C692BF5E017F7DCDD4857FF674B7AA436/CN=SwissSign RSA SMIME NCP ICA 2022 - 1,O=SwissSign AG,C=CH) * (/CN=pseudo Kundenservice e regio,1.2.840.113549.1.9.1=#6B756E64656E7365727669636540652D726567696F2E6465,2.5.4.97=#4E545244452D444552333230312E48524135383834,O=e-regio GmbH & Co. KG,L=Euskirchen,ST=NW,C=DE) * (/) Thus libksba does not see the actual signature but only the certificates. The data is handled as a kind of certs-only message but that's of course wrong. I'll get back to you as soon as I have had a closer look at it. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mike at mdsresource.net Thu Oct 3 18:19:43 2024 From: mike at mdsresource.net (Mike Schleif) Date: Thu, 3 Oct 2024 11:19:43 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? Message-ID: Finally, we are moving from CentOS Linux release 7.9.2009 (Core) _to_ AlmaLinux release 9.4 (Seafoam Ocelot). I copied .gnupg/ to the new host. Problems unsued ... [ROOT at russell ~/tmP ] # date; /bin/gpg -K ;date Thu Oct 3 11:13:52 CDT 2024 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 95b748bd217e51c036d8d0ce4387c502 gpg: key 0000000000000000 occurs more than once in the trustdb /root/.gnupg/pubring.gpg ------------------------ sec dsa1024 2002-04-01 [SCA] 8C71B38C3A071ABCD831D4655257EBE831A070A8 uid [ultimate] publickey at provell.com ssb elg1024 2002-04-01 [E] sec rsa4096 2016-03-18 [SC] 3EA174A350A97D4356A35BC6455FC35E80167A71 uid [ultimate] Sempris ssb rsa4096 2016-03-18 [E] Thu Oct 3 11:13:52 CDT 2024 [ROOT at russell ~/tmP ] # date; /bin/gpg -K --debug=ipc ;date Thu Oct 3 11:14:09 CDT 2024 gpg: reading options from '/root/.gnupg/gpg.conf' gpg: reading options from '[cmdline]' gpg: enabled debug flags: ipc gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 95b748bd217e51c036d8d0ce4387c502 gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: chan_6 <- OK Pleased to meet you, process 88789 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_6 -> RESET gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION ttyname=/dev/pts/4 gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION ttytype=xterm gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION lc-ctype=C gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION lc-messages=C gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> GETINFO version gpg: DBG: chan_6 <- D 2.3.3 gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION allow-pinentry-notify gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> HAVEKEY --list=1000 gpg: DBG: chan_6 <- [ 44 20 d5 a1 e8 57 87 66 fc 6d cc 90 8b 25 32 35 ...(74 byte(s) skipped) ] gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 gpg: DBG: chan_6 <- S KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 D - - - P - - - gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 gpg: DBG: chan_6 <- S KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 D - - - P - - - gpg: DBG: chan_6 <- OK /root/.gnupg/pubring.gpg ------------------------ sec dsa1024 2002-04-01 [SCA] 8C71B38C3A071ABCD831D4655257EBE831A070A8 uid [ultimate] publickey at provell.com ssb elg1024 2002-04-01 [E] gpg: DBG: chan_6 -> KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE gpg: DBG: chan_6 <- S KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE D - - - P - - - gpg: DBG: chan_6 <- OK gpg: DBG: chan_6 -> KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 gpg: DBG: chan_6 <- S KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 D - - - P - - - gpg: DBG: chan_6 <- OK sec rsa4096 2016-03-18 [SC] 3EA174A350A97D4356A35BC6455FC35E80167A71 uid [ultimate] Sempris ssb rsa4096 2016-03-18 [E] gpg: secmem usage: 0/65536 bytes in 0 blocks Thu Oct 3 11:14:09 CDT 2024 Initial attempt to encrypt resulted in error: gpg: starting migration from earlier GnuPG versions All subsequent attempts failed with this: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 HOW to eliminate these? gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb [ROOT at russell ~/tmP ] # date; /bin/gpg --list-secret-keys ;date Thu Oct 3 11:19:03 CDT 2024 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 95b748bd217e51c036d8d0ce4387c502 gpg: key 0000000000000000 occurs more than once in the trustdb /root/.gnupg/pubring.gpg ------------------------ sec dsa1024 2002-04-01 [SCA] 8C71B38C3A071ABCD831D4655257EBE831A070A8 uid [ultimate] publickey at provell.com ssb elg1024 2002-04-01 [E] sec rsa4096 2016-03-18 [SC] 3EA174A350A97D4356A35BC6455FC35E80167A71 uid [ultimate] Sempris ssb rsa4096 2016-03-18 [E] Thu Oct 3 11:19:03 CDT 2024 Please, advise. Thank you. ~ Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Oct 4 09:23:16 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Oct 2024 09:23:16 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: (Mike Schleif's message of "Thu, 3 Oct 2024 11:19:43 -0500") References: Message-ID: <87plogs55n.fsf@jacob.g10code.de> Hi! You should not update to a 3 years old devel version. The current stable version is 2.4.5. > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 That is a PGP-2 key. Support for them has been dropped in version 2.1.0 (2014): * gpg: All support for v3 (PGP 2) keys has been dropped. All signatures are now created as v4 signatures. v3 keys will be removed from the keyring. See also https://gnupg.org/faq/whats-new-in-2.1.html If you still have data encrypted to such keys, you need to install GnuPG 1.4. In the wake of the Snowden revelation there was a heavy move to newer algorithms and thus PGP-2 was considered broken by some people. In fact Google people heavily pledged for removing all support for PGP-2 for GnuPG. Meanwhile I think this was the wrong decision - keeping PGP-2 decryption capabilities would have been easier than all the extra code to skip PGP-2 keys in existing keyrings. And of course the PGP-2 encryption has not been broken - only signatures are vulnerable to the full MD5 hash algorithm attacks we know for 25 years. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Oct 4 09:47:50 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 4 Oct 2024 03:47:50 -0400 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <87plogs55n.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> Message-ID: <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> > to skip PGP-2 keys in existing keyrings. And of course the PGP-2 > encryption has not been broken - only signatures are vulnerable to the > full MD5 hash algorithm attacks we know for 25 years. Given that PGP 2.6 offered "military-grade" 1k RSA keys, I think it's dangerous to think PGP 2.6 encryption is safe. 1k RSA is conjectured to require resolving about 80 bits of entropy. Sixteen years ago (I think) a group of hobbyists broke RC5-64. An equivalent project today would likely be able to threaten RC5-72. An equivalent project spun up on an Amazon computing cloud would get terrifyingly close to resolving 80 bits of entropy. And that's for a hobbyist project run on a commercial cloud provider. It seems reasonable to think that as budgets rise, so too does the risk. PGP 2.6, particularly its defaults, is simply too old and generates keys that are too small to effectively protect against today's threats. I'm all in favor of keeping the decryption capability around for archival reasons, but really, can we _please_ stop using PGP 2.6 since it's now a quarter-century since the first commercial release of PGP 5 and the much superior RFC2440 standard? From mike at mdsresource.net Fri Oct 4 14:41:24 2024 From: mike at mdsresource.net (Mike Schleif) Date: Fri, 4 Oct 2024 07:41:24 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <87plogs55n.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> Message-ID: Yes, that makes sense. However, I do not know if I can use this keyring - in this state - to encrypt files? Also, how ought I cleanup these old, unused keys? ~ Mike On Fri, Oct 4, 2024 at 2:23?AM Werner Koch wrote: > Hi! > > You should not update to a 3 years old devel version. The current > stable version is 2.4.5. > > > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > > 5d5ddc60954d5b06fa7b592ec45b70d9 > > That is a PGP-2 key. Support for them has been dropped in version 2.1.0 > (2014): > > * gpg: All support for v3 (PGP 2) keys has been dropped. All > signatures are now created as v4 signatures. v3 keys will be > removed from the keyring. > > See also https://gnupg.org/faq/whats-new-in-2.1.html > > If you still have data encrypted to such keys, you need to install GnuPG > 1.4. > > In the wake of the Snowden revelation there was a heavy move to newer > algorithms and thus PGP-2 was considered broken by some people. In fact > Google people heavily pledged for removing all support for PGP-2 for > GnuPG. Meanwhile I think this was the wrong decision - keeping PGP-2 > decryption capabilities would have been easier than all the extra code > to skip PGP-2 keys in existing keyrings. And of course the PGP-2 > encryption has not been broken - only signatures are vulnerable to the > full MD5 hash algorithm attacks we know for 25 years. > > > > Shalom-Salam, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -- If ever I can be of service to you; contact me at once. I wish for you a truly extraordinary day ... -- Best Regards, Mike Schleif 612-235-6060 https://mikeschleif.net http://mdsresource.net http://www.linkedin.com/in/schleif http://facebook.com/MDSResource http://twitter.com/mikeschleif -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalzer at 59.ca Fri Oct 4 14:23:06 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Fri, 4 Oct 2024 07:23:06 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> Message-ID: On Fri, Oct 04, 2024 at 03:47:50AM -0400, Robert J. Hansen via Gnupg-users wrote: > > to skip PGP-2 keys in existing keyrings. And of course the PGP-2 > > encryption has not been broken - only signatures are vulnerable to the > > full MD5 hash algorithm attacks we know for 25 years. > > Given that PGP 2.6 offered "military-grade" 1k RSA keys, I think it's > dangerous to think PGP 2.6 encryption is safe. > > 1k RSA is conjectured to require resolving about 80 bits of entropy. There is more to factoring RSA numbers than just compute ability. You need a large amount of memory (100s of Gb in the 1024 bit case) tightly coupled to a lot of processing power to do the matrix reduction phase of the number field sieve algorithm used. That's not the sort of thing that is normally available commercially, rentable on a yearly basis. Even if you just consider compute costs, you are looking at price tag in the billions of dollars range[1]. A nation state with the ability to crack 1024 bit RSA would not spend years and billions of dollars on the messages/files of a single entity. They would be able to get the information they wanted for much less. So for current OpenPGP usage, 1024 bit RSA is for all practical purposes secure. [1]https://crypto.stackexchange.com/questions/109810/how-could-a-1024-bits-rsa-modulus-be-most-economically-factored-within-months-to Bruce From rjh at sixdemonbag.org Fri Oct 4 16:35:02 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 4 Oct 2024 10:35:02 -0400 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> Message-ID: <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> > A nation state with the ability to crack 1024 bit RSA would not spend > years and billions of dollars on the messages/files of a single > entity. They absolutely would, in a heartbeat, and they'd consider it a bargain. Imagine some major world power has a copy of an old message from Vladimir Putin, signed in '99 using 1024-bit RSA. Is it worth a billion dollars to break the key, allowing them to forge authentic-looking messages that could be useful in disinformation campaigns? Israel is believed to be a nuclear power but hard information on it is rare. If you were Iran and were in possession of a 20-year-old copy of their nuclear weapon locations, would you spend a billion dollars to break that, even if 50% of the site locations have changed? Probably. > They would be able to get the information they wanted for much > less. When it comes to breaking archival intercepts there may not be an alternative. The U.S. in particular is well-known for archiving old encrypted data in the hopes of breaking it later. VENONA, for instance. In the digital forensics community there are stories of the USG holding onto the shattered fragments of a CD-ROM that are being held for the day when 3D scanning and modeling matures to the point they can reassemble the CD-ROM from its fragments. Of the DF nerds I worked with, all of us believed the story. We argued instead about whether we had that capability yet, or how far away we were. > So for current OpenPGP usage, 1024 bit RSA is for all practical > purposes secure. No. Just a flat no. If breaking RSA-1024 is feasible today, even if it's not practical, it will be practical *soon*. In the United States, Top Secret-rated national security information is by default considered a grave threat to national security for 25 years. The CIA even has some they've declared major threats for 50 years. I have zero confidence RSA-1024 will be safe for even *five* years. Stop using RSA-1024 today. The best time to stop using it was 25 years ago, but if you missed that opportunity, today's the next best bet. From wk at gnupg.org Fri Oct 4 17:09:40 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Oct 2024 17:09:40 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Fri, 4 Oct 2024 10:35:02 -0400") References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> Message-ID: <87cykfsy4r.fsf@jacob.g10code.de> On Fri, 4 Oct 2024 10:35, Robert J. Hansen said: > Stop using RSA-1024 today. The best time to stop using it was 25 > years ago, but if you missed that opportunity, today's the next best For the records: I never intended to say that anyone should create a new rsa1024 bit key for long time storage. However, there are cases when creating such a key might be useful (old hardware, low value of the the data, and uselessness of decryption after a short time). But even then cv25519 is a better option. Creating PGP-2 keys is of course no no-go. And along with algorithm strength goes the OPsec and that is much harder. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 4 17:14:03 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Oct 2024 17:14:03 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: (Mike Schleif's message of "Fri, 4 Oct 2024 07:41:24 -0500") References: <87plogs55n.fsf@jacob.g10code.de> Message-ID: <878qv3sxxg.fsf@jacob.g10code.de> On Fri, 4 Oct 2024 07:41, Mike Schleif said: > Also, how ought I cleanup these old, unused keys? $ gpg --export --export-options backup > exported.gpg $ echo use-keyboxd ~/.gnupg/common.conf $ gpgconf -K all $ gpg --import --import-options restore < exported.gpg If you use a decent 2.4 version. If your version is older do $ gpg --export > exported.gpg $ mv ~/.gnupg/pubring.kbx ~/.gnupg/pubring.kbx-old $ mv ~/.gnupg/pubring.gpg ~/.gnupg/pubring.gpg-old $ gpg --import < exported.gpg Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mike at mdsresource.net Fri Oct 4 17:59:31 2024 From: mike at mdsresource.net (Mike Schleif) Date: Fri, 4 Oct 2024 10:59:31 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: References: Message-ID: HOW ought we cleanup our keyring? [ROOT at russell ~ ] # date; /bin/gpg --fingerprint 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:50:34 CDT 2024 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 95b748bd217e51c036d8d0ce4387c502 gpg: key 0000000000000000 occurs more than once in the trustdb gpg: error reading key: No public key Fri Oct 4 10:50:34 CDT 2024 [ROOT at russell ~ ] # date; /bin/gpg --delete-secret-key 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:52:40 CDT 2024 gpg (GnuPG) 2.3.3; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key "5d5ddc60954d5b06fa7b592ec45b70d9" not found: Not found gpg: 5d5ddc60954d5b06fa7b592ec45b70d9: delete key failed: Not found Fri Oct 4 10:52:40 CDT 2024 [ROOT at russell ~ ] # date; /bin/gpg --delete-key 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:53:00 CDT 2024 gpg (GnuPG) 2.3.3; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key "5d5ddc60954d5b06fa7b592ec45b70d9" not found: Not found gpg: 5d5ddc60954d5b06fa7b592ec45b70d9: delete key failed: Not found Fri Oct 4 10:53:00 CDT 2024 Even on the legacy system: [ROOT at iceland ~ ] # date; /bin/gpg --fingerprint 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:26:06 CDT 2024 pub 1024R/4A63FA15 2003-06-17 Key fingerprint = 5D 5D DC 60 95 4D 5B 06 FA 7B 59 2E C4 5B 70 D9 uid PFSWebRSA Fri Oct 4 10:26:06 CDT 2024 [ROOT at iceland ~ ] # date; /bin/gpg --delete-secret-key 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:26:27 CDT 2024 gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key "5d5ddc60954d5b06fa7b592ec45b70d9" not found: Unknown system error gpg: 5d5ddc60954d5b06fa7b592ec45b70d9: delete key failed: Unknown system error Fri Oct 4 10:26:27 CDT 2024 [ROOT at iceland ~ ] # date; /bin/gpg --delete-key 5d5ddc60954d5b06fa7b592ec45b70d9 ;date Fri Oct 4 10:26:36 CDT 2024 gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 1024R/4A63FA15 2003-06-17 PFSWebRSA Delete this key from the keyring? (y/N) y gpg: Oops: keyid_from_fingerprint: no pubkey Fri Oct 4 10:26:40 CDT 2024 [ROOT at iceland ~ ] # date; /bin/gpg --delete-key 4A63FA15 ;date Fri Oct 4 10:57:31 CDT 2024 gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key "4A63FA15" not found: Unknown system error gpg: 4A63FA15: delete key failed: Unknown system error Fri Oct 4 10:57:31 CDT 2024 Please, advise. Thank you. ~ Mike On Thu, Oct 3, 2024 at 11:19?AM Mike Schleif wrote: > Finally, we are moving from CentOS Linux release 7.9.2009 (Core) _to_ > AlmaLinux release 9.4 (Seafoam Ocelot). > > I copied .gnupg/ to the new host. Problems unsued ... > > [ROOT at russell ~/tmP ] # date; /bin/gpg -K ;date > Thu Oct 3 11:13:52 CDT 2024 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > Thu Oct 3 11:13:52 CDT 2024 > > > [ROOT at russell ~/tmP ] # date; /bin/gpg -K --debug=ipc ;date > Thu Oct 3 11:14:09 CDT 2024 > gpg: reading options from '/root/.gnupg/gpg.conf' > gpg: reading options from '[cmdline]' > gpg: enabled debug flags: ipc > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: chan_6 <- OK Pleased to meet you, process 88789 > gpg: DBG: connection to the gpg-agent established > gpg: DBG: chan_6 -> RESET > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION ttyname=/dev/pts/4 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION ttytype=xterm > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION lc-ctype=C > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION lc-messages=C > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> GETINFO version > gpg: DBG: chan_6 <- D 2.3.3 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION allow-pinentry-notify > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION agent-awareness=2.1.0 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> HAVEKEY --list=1000 > gpg: DBG: chan_6 <- [ 44 20 d5 a1 e8 57 87 66 fc 6d cc 90 8b 25 32 35 > ...(74 byte(s) skipped) ] > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 > gpg: DBG: chan_6 <- S KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 D - > - - P - - - > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 > gpg: DBG: chan_6 <- S KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 D - > - - P - - - > gpg: DBG: chan_6 <- OK > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > gpg: DBG: chan_6 -> KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE > gpg: DBG: chan_6 <- S KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE D - > - - P - - - > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 > gpg: DBG: chan_6 <- S KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 D - > - - P - - - > gpg: DBG: chan_6 <- OK > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > gpg: secmem usage: 0/65536 bytes in 0 blocks > Thu Oct 3 11:14:09 CDT 2024 > > > Initial attempt to encrypt resulted in error: > gpg: starting migration from earlier GnuPG versions > > All subsequent attempts failed with this: > DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > > HOW to eliminate these? > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > > > [ROOT at russell ~/tmP ] # date; /bin/gpg --list-secret-keys ;date > Thu Oct 3 11:19:03 CDT 2024 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > Thu Oct 3 11:19:03 CDT 2024 > > > Please, advise. Thank you. > > ~ Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalzer at 59.ca Fri Oct 4 18:17:34 2024 From: bwalzer at 59.ca (Bruce Walzer) Date: Fri, 4 Oct 2024 11:17:34 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> Message-ID: On Fri, Oct 04, 2024 at 10:35:02AM -0400, Robert J. Hansen via Gnupg-users wrote: > > A nation state with the ability to crack 1024 bit RSA would not spend > > years and billions of dollars on the messages/files of a single > > entity. > > They absolutely would, in a heartbeat, and they'd consider it a bargain. > > Imagine some major world power has a copy of an old message from Vladimir > Putin, signed in '99 using 1024-bit RSA. Is it worth a billion dollars to > break the key, allowing them to forge authentic-looking messages that could > be useful in disinformation campaigns? I am not suggesting that world leaders should continue to use 1024 bit RSA to store their nuclear installation locations or sign their offical pronouncements. I am merely pointing out that for 99.9999% of GPG users dropping the old key format provided no benefit with respect to key length. They could continue to use such keys indefinitely to generate new messages with no real risk. Of course the bigger usability issue here is that old messages encrypted using the old key format still exist. Dropping support for decrypting such messages entirely means that users lose access to those messages and gain no potential benefit, even if they are a world leader. Bruce From m.mansfeld at mansfeld-elektronik.de Fri Oct 4 17:11:18 2024 From: m.mansfeld at mansfeld-elektronik.de (Mansfeld Elektronik) Date: Fri, 04 Oct 2024 17:11:18 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> Message-ID: Am 04.10.2024 16:35, schrieb Robert J. Hansen via Gnupg-users: >> A nation state with the ability to crack 1024 bit RSA would not spend >> years and billions of dollars on the messages/files of a single >> entity. > > They absolutely would, in a heartbeat, and they'd consider it a > bargain. SCNR Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mdsresource.net Fri Oct 4 19:45:54 2024 From: mike at mdsresource.net (Mike Schleif) Date: Fri, 4 Oct 2024 12:45:54 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <878qv3sxxg.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> Message-ID: Werner, somehow I missed your message, before sending my message 2 hours ago. However, your actions do not work for me. [ROOT at russell ~/.gnupg ] # date; /bin/gpg --version ;date Fri Oct 4 12:38:19 CDT 2024 gpg (GnuPG) 2.3.3 libgcrypt 1.10.0-unknown Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-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: /root/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 AEAD: EAX, OCB Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Fri Oct 4 12:38:19 CDT 2024 BEFORE taking your actions: [ROOT at russell ~/.gnupg ] # ls -al total 864 drwx------. 3 root root 4096 Oct 4 12:35 . dr-xr-x---. 14 root root 4096 Oct 4 12:31 .. -rw-r--r--. 1 root root 0 Oct 3 10:45 .gpg-v21-migrated srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.browser srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.extra srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.ssh srwx------. 1 root root 0 Oct 3 10:45 S.scdaemon -rw-r--r--. 1 root root 268006 Oct 4 12:35 exported.gpg -rw-------. 1 root root 8071 Sep 5 2019 gpg.conf drwx------. 2 root root 4096 Oct 3 10:45 private-keys-v1.d -rw-------. 1 root root 273017 Jul 22 15:03 pubring.gpg -rw-------. 1 root root 273017 Jul 22 15:03 pubring.gpg~ -rw-------. 1 root root 600 Oct 3 11:03 random_seed -rw-------. 1 root root 5726 Jul 10 2017 secring.gpg -rw-------. 1 root root 29360 Jul 22 15:03 trustdb.gpg NOTE: NO .kbx files. [ROOT at russell ~/.gnupg ] # mv pubring.gpg pubring.gpg.OLD [ROOT at russell ~/.gnupg ] # ls -al total 864 drwx------. 3 root root 4096 Oct 4 12:36 . dr-xr-x---. 14 root root 4096 Oct 4 12:31 .. -rw-r--r--. 1 root root 0 Oct 3 10:45 .gpg-v21-migrated srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.browser srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.extra srwx------. 1 root root 0 Oct 3 10:45 S.gpg-agent.ssh srwx------. 1 root root 0 Oct 3 10:45 S.scdaemon -rw-r--r--. 1 root root 268006 Oct 4 12:35 exported.gpg -rw-------. 1 root root 8071 Sep 5 2019 gpg.conf drwx------. 2 root root 4096 Oct 3 10:45 private-keys-v1.d -rw-------. 1 root root 273017 Jul 22 15:03 pubring.gpg.OLD -rw-------. 1 root root 273017 Jul 22 15:03 pubring.gpg~ -rw-------. 1 root root 600 Oct 3 11:03 random_seed -rw-------. 1 root root 5726 Jul 10 2017 secring.gpg -rw-------. 1 root root 29360 Jul 22 15:03 trustdb.gpg [ROOT at russell ~/.gnupg ] # /bin/gpg --import < exported.gpg . . . gpg: Total number processed: 189 gpg: w/o user IDs: 1 gpg: imported: 188 gpg: public key of ultimately trusted key 0000000000000000 not found gpg: marginals needed: 3 completes needed: 1 trust model: classic gpg: depth: 0 valid: 82 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 82u gpg: next trustdb check due at 2033-09-13 [ROOT at russell ~/.gnupg ] # date; /bin/gpg -K ;date Fri Oct 4 12:37:06 CDT 2024 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 5d5ddc60954d5b06fa7b592ec45b70d9 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 850d581e35383b8c11b50e471bb1b9be gpg: key 0000000000000000 occurs more than once in the trustdb gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 95b748bd217e51c036d8d0ce4387c502 gpg: key 0000000000000000 occurs more than once in the trustdb /root/.gnupg/pubring.kbx ------------------------ sec dsa1024 2002-04-01 [SCA] 8C71B38C3A071ABCD831D4655257EBE831A070A8 uid [ultimate] publickey at provell.com ssb elg1024 2002-04-01 [E] sec rsa4096 2016-03-18 [SC] 3EA174A350A97D4356A35BC6455FC35E80167A71 uid [ultimate] Sempris ssb rsa4096 2016-03-18 [E] Fri Oct 4 12:37:06 CDT 2024 Please, advise. Thank you. ~ Mike On Fri, Oct 4, 2024 at 10:14?AM Werner Koch wrote: > On Fri, 4 Oct 2024 07:41, Mike Schleif said: > > > Also, how ought I cleanup these old, unused keys? > > $ gpg --export --export-options backup > exported.gpg > $ echo use-keyboxd ~/.gnupg/common.conf > $ gpgconf -K all > $ gpg --import --import-options restore < exported.gpg > > If you use a decent 2.4 version. If your version is older do > > $ gpg --export > exported.gpg > $ mv ~/.gnupg/pubring.kbx ~/.gnupg/pubring.kbx-old > $ mv ~/.gnupg/pubring.gpg ~/.gnupg/pubring.gpg-old > $ gpg --import < exported.gpg > > > Salam-Shalom, > > Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -- If ever I can be of service to you; contact me at once. I wish for you a truly extraordinary day ... -- Best Regards, Mike Schleif 612-235-6060 https://mikeschleif.net http://mdsresource.net http://www.linkedin.com/in/schleif http://facebook.com/MDSResource http://twitter.com/mikeschleif -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Oct 4 23:17:05 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 4 Oct 2024 17:17:05 -0400 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: References: <87plogs55n.fsf@jacob.g10code.de> <31be2edb-5271-4acf-b8ed-4ef08b876136@sixdemonbag.org> <2bd3f191-d4b3-4f41-94fe-096a038cb397@sixdemonbag.org> Message-ID: > I am not suggesting that world leaders should continue to use 1024 bit > RSA to store their nuclear installation locations or sign their > offical pronouncements. "So for current OpenPGP usage, 1024 bit RSA is for all practical purposes secure." That was you, two messages ago. Now you're saying 1024-bit RSA shouldn't be used for high-value secrets or signatures that need long-term confidence. Thank you for conceding the point. 1024-bit RSA doesn't offer long-term security, and that makes it inappropriate for a lot of situations. Stop using it now. Migrate to something better before it's too late. > I am merely pointing out that for 99.9999% of > GPG users dropping the old key format provided no benefit with respect > to key length. It absolutely did, by reducing unnecessary features and the code necessary to support it. GnuPG's mission has been to deliver high-quality implementations of RFC4880 and the S/MIME RFCs. Every line of code that exists for RFC1991 support contributes nothing to GnuPG's mission while adding a new opportunity for exploitable bugs. I personally want all RFC1991 support out. If I need it, I know where I can download GnuPG 1.4. > They could continue to use such keys indefinitely to > generate new messages with no real risk. Assuming they didn't need long-term secrecy, sure. That's a big assumption to make. Better to say "RSA-1024 is no longer believed to offer acceptable long-term security, please stop using it." From 400thecat at ik.me Mon Oct 7 05:09:31 2024 From: 400thecat at ik.me (Fourhundred Thecat) Date: Mon, 7 Oct 2024 05:09:31 +0200 Subject: decrypting to stdout does not work properly Message-ID: Hello, I have a script to decrypt a file and send it to another program: gpg -q -d "$filename" | mpv - this works fine when my gpg agent is already unlocked, ie the passphrase is alredy cached. But when the agent is not yet unlocked, I get some garbled passphrase prompt which breaks my terminal, and even typing the passphrase does not work what do I need to do? check first whether agent is unlocked, and if not unlock it first and only then proceed with gpg -d? how would I check that? I tried this: if echo "test" | gpg --sign --quiet >/dev/null 2>/dev/null ; then which sort of works, but looks convoluted and also has few hundred milliseconds delay Also, is there a command for unlocking the agent without actually decrypting anything ? thank you, From gnupg-users at city17.xyz Mon Oct 7 08:40:57 2024 From: gnupg-users at city17.xyz (jman) Date: Mon, 07 Oct 2024 08:40:57 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: (Fourhundred Thecat via Gnupg-users's message of "Mon, 7 Oct 2024 05:09:31 +0200") References: Message-ID: <87h69oh0ue.fsf@city17.xyz> Fourhundred Thecat via Gnupg-users writes: > Also, is there a command for unlocking the agent without actually > decrypting anything ? Hi, funny that I asked exactly the same question a few years ago. I wanted to check if my keyring was unlocked before doing any actual operation. Apparently the solution is to send an SCD command and then try to to what you really want to do (i.e. decrypting a key). You might find this thread useful: https://lists.gnupg.org/pipermail/gnupg-users/2020-December/064520.html SCDaemon documentation (with all the commands) at: https://www.gnupg.org/documentation/manuals/gnupg/Scdaemon-Protocol.html In the end I have scripted the unlocking of a smartcard but the resulting script is a bit convoluted because the output of gpg-connect-agent is not super useful. HTH From johh.soo at arista.com Mon Oct 7 20:28:26 2024 From: johh.soo at arista.com (John Soo) Date: Mon, 7 Oct 2024 12:28:26 -0600 Subject: Rectify agent/client mismatch 2.2.27/2.3.3 Message-ID: Posted on discourse but seems like the list is the right place to ask: I have a client at 2.3 and a gpg-agent at 2.2.27 connected via ssh remote forwarding. However I cannot list secret keys (see detail). Is there a way for me to put this client into an accessibility mode so that the older agent will recognize the IPC commands? It is very hard for me to upgrade either client or agent in this case. https://forum.gnupg.org/t/rectify-agent-client-mismatch-listing-secret-keys-with-forwarded-agent/5789 Output follows, thank you! --- John $ gpg --list-secret-keys --debug lookup,ipc,filter gpg: reading options from '[cmdline]' gpg: enabled debug flags: filter ipc lookup gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FIRST gpg: DBG: internal_keydb_search: searching keybox (resource 0 of 1) gpg: DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success gpg: DBG: chan_5 <- OK Pleased to meet you, process 35850 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_5 -> RESET gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION ttyname=/dev/pts/0 gpg: DBG: chan_5 <- ERR 67109115 Forbidden gpg: DBG: chan_5 -> GETINFO restricted gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> GETINFO version gpg: DBG: chan_5 <- D 2.2.27 gpg: DBG: chan_5 <- OK gpg: WARNING: server 'gpg-agent' is older than us (2.2.27 < 2.3.3) gpg: Note: Outdated servers may lack important security fixes. gpg: Note: Use the command "gpgconf --kill all" to restart them. gpg: DBG: chan_5 -> OPTION allow-pinentry-notify gpg: DBG: chan_5 <- ERR 67109115 Forbidden gpg: DBG: chan_5 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> HAVEKEY --list=1000 gpg: DBG: chan_5 <- ERR 67109144 IPC parameter error - invalid hexstring gpg: problem with fast path key listing: IPC parameter error - ignored gpg: DBG: chan_5 -> HAVEKEY gpg: DBG: chan_5 <- ERR 67108881 No secret key gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: NEXT gpg: DBG: internal_keydb_search: searching keybox (resource 0 of 1) gpg: DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF gpg: secmem usage: 0/65536 bytes in 0 blocks From mike at mdsresource.net Mon Oct 7 21:46:38 2024 From: mike at mdsresource.net (Mike Schleif) Date: Mon, 7 Oct 2024 14:46:38 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <878qv3sxxg.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> Message-ID: As my subject states, we are using v2.3.3 - and your suggestion does not cleanup our keyring, continuing to spew these errors. Please, advise. Thank you. ~ Mike On Fri, Oct 4, 2024 at 10:14?AM Werner Koch wrote: > On Fri, 4 Oct 2024 07:41, Mike Schleif said: > > > Also, how ought I cleanup these old, unused keys? > > $ gpg --export --export-options backup > exported.gpg > $ echo use-keyboxd ~/.gnupg/common.conf > $ gpgconf -K all > $ gpg --import --import-options restore < exported.gpg > > If you use a decent 2.4 version. If your version is older do > > $ gpg --export > exported.gpg > $ mv ~/.gnupg/pubring.kbx ~/.gnupg/pubring.kbx-old > $ mv ~/.gnupg/pubring.gpg ~/.gnupg/pubring.gpg-old > $ gpg --import < exported.gpg > > > Salam-Shalom, > > Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -- If ever I can be of service to you; contact me at once. I wish for you a truly extraordinary day ... -- Best Regards, Mike Schleif 612-235-6060 https://mikeschleif.net http://mdsresource.net http://www.linkedin.com/in/schleif http://facebook.com/MDSResource http://twitter.com/mikeschleif -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mdsresource.net Mon Oct 7 21:50:01 2024 From: mike at mdsresource.net (Mike Schleif) Date: Mon, 7 Oct 2024 14:50:01 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: References: Message-ID: Apparently, this upgrade also negatively affects trustdb, since encrypting files with previously trusted public keys not fails, stating the there is no trust assigned to these keys. How can we correct these trust issues? Please, advise. Thank you. ~ Mike On Thu, Oct 3, 2024 at 11:19?AM Mike Schleif wrote: > Finally, we are moving from CentOS Linux release 7.9.2009 (Core) _to_ > AlmaLinux release 9.4 (Seafoam Ocelot). > > I copied .gnupg/ to the new host. Problems unsued ... > > [ROOT at russell ~/tmP ] # date; /bin/gpg -K ;date > Thu Oct 3 11:13:52 CDT 2024 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > Thu Oct 3 11:13:52 CDT 2024 > > > [ROOT at russell ~/tmP ] # date; /bin/gpg -K --debug=ipc ;date > Thu Oct 3 11:14:09 CDT 2024 > gpg: reading options from '/root/.gnupg/gpg.conf' > gpg: reading options from '[cmdline]' > gpg: enabled debug flags: ipc > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: chan_6 <- OK Pleased to meet you, process 88789 > gpg: DBG: connection to the gpg-agent established > gpg: DBG: chan_6 -> RESET > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION ttyname=/dev/pts/4 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION ttytype=xterm > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION lc-ctype=C > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION lc-messages=C > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> GETINFO version > gpg: DBG: chan_6 <- D 2.3.3 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION allow-pinentry-notify > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> OPTION agent-awareness=2.1.0 > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> HAVEKEY --list=1000 > gpg: DBG: chan_6 <- [ 44 20 d5 a1 e8 57 87 66 fc 6d cc 90 8b 25 32 35 > ...(74 byte(s) skipped) ] > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 > gpg: DBG: chan_6 <- S KEYINFO D5A1E8578766FC6DCC908B25D600BAD639D641A6 D - > - - P - - - > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 > gpg: DBG: chan_6 <- S KEYINFO 50C781CC9FD53404EC17CF98BFC22BE65A1547E7 D - > - - P - - - > gpg: DBG: chan_6 <- OK > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > gpg: DBG: chan_6 -> KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE > gpg: DBG: chan_6 <- S KEYINFO 6924009722E1790A3D3CB382FD26707F0A3136EE D - > - - P - - - > gpg: DBG: chan_6 <- OK > gpg: DBG: chan_6 -> KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 > gpg: DBG: chan_6 <- S KEYINFO 13CF8D0A979ADBF4D7D34E66841FCFA5CC7F5EB8 D - > - - P - - - > gpg: DBG: chan_6 <- OK > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > gpg: secmem usage: 0/65536 bytes in 0 blocks > Thu Oct 3 11:14:09 CDT 2024 > > > Initial attempt to encrypt resulted in error: > gpg: starting migration from earlier GnuPG versions > > All subsequent attempts failed with this: > DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > > HOW to eliminate these? > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > > > [ROOT at russell ~/tmP ] # date; /bin/gpg --list-secret-keys ;date > Thu Oct 3 11:19:03 CDT 2024 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 5d5ddc60954d5b06fa7b592ec45b70d9 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 850d581e35383b8c11b50e471bb1b9be > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 95b748bd217e51c036d8d0ce4387c502 > gpg: key 0000000000000000 occurs more than once in the trustdb > /root/.gnupg/pubring.gpg > ------------------------ > sec dsa1024 2002-04-01 [SCA] > 8C71B38C3A071ABCD831D4655257EBE831A070A8 > uid [ultimate] publickey at provell.com > ssb elg1024 2002-04-01 [E] > > sec rsa4096 2016-03-18 [SC] > 3EA174A350A97D4356A35BC6455FC35E80167A71 > uid [ultimate] Sempris > ssb rsa4096 2016-03-18 [E] > > Thu Oct 3 11:19:03 CDT 2024 > > > Please, advise. Thank you. > > ~ Mike > -- If ever I can be of service to you; contact me at once. I wish for you a truly extraordinary day ... -- Best Regards, Mike Schleif 612-235-6060 https://mikeschleif.net http://mdsresource.net http://www.linkedin.com/in/schleif http://facebook.com/MDSResource http://twitter.com/mikeschleif -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.soo+gnupg-users at arista.com Mon Oct 7 22:39:20 2024 From: john.soo+gnupg-users at arista.com (John Soo) Date: Mon, 7 Oct 2024 14:39:20 -0600 Subject: Rectify agent/client mismatch 2.2.27/2.3.3 Message-ID: Posted on discourse but seems like the list is the right place to ask: I have a client at 2.3 and a gpg-agent at 2.2.27 connected via ssh remote forwarding. However I cannot list secret keys (see detail). Is there a way for me to put this client into an accessibility mode so that the older agent will recognize the IPC commands? It is very hard for me to upgrade either client or agent in this case. https://forum.gnupg.org/t/rectify-agent-client-mismatch-listing-secret-keys-with-forwarded-agent/5789 Output follows, thank you! --- John $ gpg --list-secret-keys --debug lookup,ipc,filter gpg: reading options from '[cmdline]' gpg: enabled debug flags: filter ipc lookup gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FIRST gpg: DBG: internal_keydb_search: searching keybox (resource 0 of 1) gpg: DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success gpg: DBG: chan_5 <- OK Pleased to meet you, process 35850 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_5 -> RESET gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION ttyname=/dev/pts/0 gpg: DBG: chan_5 <- ERR 67109115 Forbidden gpg: DBG: chan_5 -> GETINFO restricted gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> GETINFO version gpg: DBG: chan_5 <- D 2.2.27 gpg: DBG: chan_5 <- OK gpg: WARNING: server 'gpg-agent' is older than us (2.2.27 < 2.3.3) gpg: Note: Outdated servers may lack important security fixes. gpg: Note: Use the command "gpgconf --kill all" to restart them. gpg: DBG: chan_5 -> OPTION allow-pinentry-notify gpg: DBG: chan_5 <- ERR 67109115 Forbidden gpg: DBG: chan_5 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> HAVEKEY --list=1000 gpg: DBG: chan_5 <- ERR 67109144 IPC parameter error - invalid hexstring gpg: problem with fast path key listing: IPC parameter error - ignored gpg: DBG: chan_5 -> HAVEKEY gpg: DBG: chan_5 <- ERR 67108881 No secret key gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: NEXT gpg: DBG: internal_keydb_search: searching keybox (resource 0 of 1) gpg: DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF gpg: secmem usage: 0/65536 bytes in 0 blocks -------------- next part -------------- An HTML attachment was scrubbed... URL: