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: From wk at gnupg.org Tue Oct 8 18:18:14 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Oct 2024 18:18:14 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: (Mike Schleif's message of "Fri, 4 Oct 2024 12:45:54 -0500") References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> Message-ID: <87y12ypnzt.fsf@jacob.g10code.de> On Fri, 4 Oct 2024 12:45, Mike Schleif said: > gpg (GnuPG) 2.3.3 > BEFORE taking your actions: > > -rw-r--r--. 1 root root 0 Oct 3 10:45 .gpg-v21-migrated Which means that you already migtated from 2.0 or 1.4 to 2.1 or later. That is the private keys are now stored in separate file below the > drwx------. 2 root root 4096 Oct 3 10:45 private-keys-v1.d directory. > -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 Take care - that secring.gpg is only used by older gpg versions. > NOTE: NO .kbx files. Right, you still use the pubring.gpg - not a real problem but no so common. Something with the migration didn't worked out. The pubring.gpg can't be used for gpgsm (S/MIME) and thus a pubring.kbx should have been created during the migration. > [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 Your trustdb has an ultimately trusted PGP-2 key. gpg can't disaply the fingerprint anymore and thus you see the zeroes. > 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 You should gpg --edit-key YOURKEY and enter "trust" to set your key back to ultimately trusted. This will given you back the WoT. > gpg: key 0000000000000000 occurs more than once in the trustdb You have several PGP-2 keys in your trustdb. 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 8 18:32:51 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Oct 2024 18:32:51 +0200 Subject: Rectify agent/client mismatch 2.2.27/2.3.3 In-Reply-To: (John Soo via Gnupg-users's message of "Mon, 7 Oct 2024 12:28:26 -0600") References: Message-ID: <87ttdmpnbg.fsf@jacob.g10code.de> Hi! On Mon, 7 Oct 2024 12:28, John Soo said: > 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. Without being able to update the cleint it will be somehwat hard for you. > 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 Yes, you are in restricted mode and thus this connection via the agent-extra-socket is not allowed to do certain operations. > 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 As stated this is ignored and instead the gpg-agent is asked using the classic command: > gpg: DBG: chan_5 -> HAVEKEY > gpg: DBG: chan_5 <- ERR 67108881 No secret key But the agent tells you that it does not have these keys. Check whether the gpg-agent (on the client) has the files ~/.gnupg/private-keys-v1.d/.key etc? You can also test this by running on the cleint: gpg-connect-agent 'HAVEKEY ' /bye Same result? 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 mike at mdsresource.net Tue Oct 8 20:09:12 2024 From: mike at mdsresource.net (Mike Schleif) Date: Tue, 8 Oct 2024 13:09:12 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <87y12ypnzt.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> Message-ID: Allow me to step back to the beginning. We need to move off of our CentOS v7x platform ASAP, on which the most recent GnuPG is v2.0.22. Yes, I know that this is ancient; but, management does not want to rely on roll-our-own executables. What I did was: 1. Zip up the .gnupg/ directory on the old system; 2. Unzip it on the new system; 3. Verify the /bin/gpg is on the new system; 4. Successfully tested decryption; and 5. Tried testing encryption. Sadly, Step 5 (encryption testing) is where the troubles began: a. gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: ... b. gpg: key 0000000000000000 occurs more than once in the trustdb c. gpg: 079A71E548C19BC0: There is no assurance this key belongs to the named user d. gpg: TEST.txt: sign+encrypt failed: Unusable public key Ought we do something on the legacy (v2.0.22) host before copying to the new host? Please, HELP! We need to transition yesterday ... ~ Mike On Tue, Oct 8, 2024 at 11:18?AM Werner Koch wrote: > On Fri, 4 Oct 2024 12:45, Mike Schleif said: > > > gpg (GnuPG) 2.3.3 > > > BEFORE taking your actions: > > > > -rw-r--r--. 1 root root 0 Oct 3 10:45 .gpg-v21-migrated > > Which means that you already migtated from 2.0 or 1.4 to 2.1 or later. > That is the private keys are now stored in separate file below the > > > drwx------. 2 root root 4096 Oct 3 10:45 private-keys-v1.d > > directory. > > > -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 > > Take care - that secring.gpg is only used by older gpg versions. > > > NOTE: NO .kbx files. > > Right, you still use the pubring.gpg - not a real problem but no so > common. Something with the migration didn't worked out. The > pubring.gpg can't be used for gpgsm (S/MIME) and thus a pubring.kbx > should have been created during the migration. > > > [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 > > Your trustdb has an ultimately trusted PGP-2 key. gpg can't disaply the > fingerprint anymore and thus you see the zeroes. > > > 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 > > You should > > gpg --edit-key YOURKEY > > and enter "trust" to set your key back to ultimately trusted. This will > given you back the WoT. > > > gpg: key 0000000000000000 occurs more than once in the trustdb > > You have several PGP-2 keys in your trustdb. > > > 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 wk at gnupg.org Wed Oct 9 08:51:22 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Oct 2024 08:51:22 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: <87h69oh0ue.fsf@city17.xyz> (jman via Gnupg-users's message of "Mon, 07 Oct 2024 08:40:57 +0200") References: <87h69oh0ue.fsf@city17.xyz> Message-ID: <87plo9py51.fsf@jacob.g10code.de> Hi! Just a short remark: On Mon, 7 Oct 2024 08:40, jman said: > 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. meanwhile (since 2.4) we have the gpg-card tool. This is bette suited for scripting. For example you can do things like gpg-card verify CHV1 -- list -- help -- whatever here is the man page: https://gnupg.org/documentation/manuals/gnupg24/gpg-card.1.html 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 guru at unixarea.de Wed Oct 9 09:45:10 2024 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 9 Oct 2024 09:45:10 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: <87plo9py51.fsf@jacob.g10code.de> References: <87h69oh0ue.fsf@city17.xyz> <87plo9py51.fsf@jacob.g10code.de> Message-ID: El d?a mi?rcoles, octubre 09, 2024 a las 08:51:22 +0200, Werner Koch via Gnupg-users escribi?: > Hi! > > Just a short remark: > > On Mon, 7 Oct 2024 08:40, jman said: > > > 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. > > meanwhile (since 2.4) we have the gpg-card tool. This is bette suited > for scripting. For example you can do things like > > gpg-card verify CHV1 -- list -- help -- whatever > ... Hi Werner, Could this tool be backported to 2.2 ? On my L5 I have: purism at pureos:~$ apt info gpg Package: gpg Version: 2.2.27-2+deb11u2 Priority: optional Section: utils Source: gnupg2 Maintainer: Debian GnuPG Maintainers Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. ? ?? ???? ? ???????. Ich bin nicht im Krieg mit Russland. From alejandro at privacyrequired.com Wed Oct 9 15:50:24 2024 From: alejandro at privacyrequired.com (Alejandro) Date: Wed, 9 Oct 2024 15:50:24 +0200 Subject: GnuPG Keyring Issue Across Systems. Where is pubring.kbx? Message-ID: <89dac2f2-3ff6-476d-8669-801b13cc066b@privacyrequired.com> Hi, I?m using the default GnuPG package from `pacman -S gnupg` on my Arch system. For security reasons, I copied my GNUPGHOME to a USB drive, which worked well when I mounted it as GNUPGHOME. However, I recently needed to use my keys on another machine running Pop!_OS 22.04. After decrypting my LUKS USB drive and exporting the GNUPGHOME to my .gnupg directory on the USB, I ran `gpg --list-keys`. This created a new `pubring.kdx`. Upon checking my main .gnupg directory, I noticed it doesn?t contain a `pubring.kbx`, `pubring.gpg`, or `secring.gpg`. I suspect this is because Arch, being a rolling release, uses a newer version of GnuPG that doesn't require a pubring, while Pop!_OS is using an older version. Here?s what my .gnupg directory looks like: ``` ls .gnupg common.conf? openpgp-revocs.d/?? public-keys.d/? sshcontrol crls.d/????? private-keys-v1.d/? random_seed???? trustdb.gpg ``` Thanks for your help! Alejandro -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x9B029E4189816E4A.asc Type: application/pgp-keys Size: 3175 bytes Desc: OpenPGP public key URL: From wk at gnupg.org Wed Oct 9 18:30:15 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Oct 2024 18:30:15 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: (Mike Schleif's message of "Tue, 8 Oct 2024 13:09:12 -0500") References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> Message-ID: <878quxp7c8.fsf@jacob.g10code.de> On Tue, 8 Oct 2024 13:09, Mike Schleif said: > Ought we do something on the legacy (v2.0.22) host before copying to the > new host? I general not but you can do this: gpg --export >all-public-keys.gpg gpg --export-secret-keys >all-secret-keys.gpg gpg --export-ownertrust >ownertrust.txt also backup the *.conf files if you have some. On the new machine rename the existsing ~/.gnupg to ~/.gnupg-saved and then run gpg -k which will create a new ~/.gnupg Then gpg --import From ming at imkuang.com Wed Oct 9 18:00:07 2024 From: ming at imkuang.com (Ming Kuang) Date: Thu, 10 Oct 2024 00:00:07 +0800 Subject: GnuPG Keyring Issue Across Systems. Where is pubring.kbx? In-Reply-To: <89dac2f2-3ff6-476d-8669-801b13cc066b@privacyrequired.com> References: <89dac2f2-3ff6-476d-8669-801b13cc066b@privacyrequired.com> Message-ID: <8bdfe2c2c157727dfa1ab4679449c472b67992ed.camel@imkuang.com> On Wed, 2024-10-09 at 15:50 +0200, Alejandro via Gnupg-users wrote: > Hi, > > I?m using the default GnuPG package from `pacman -S gnupg` on my Arch > system. For security reasons, I copied my GNUPGHOME to a USB drive, > which worked well when I mounted it as GNUPGHOME. > > However, I recently needed to use my keys on another machine running > Pop!_OS 22.04. After decrypting my LUKS USB drive and exporting the > GNUPGHOME to my .gnupg directory on the USB, I ran `gpg --list-keys`. > This created a new `pubring.kdx`. Upon checking my main .gnupg > directory, I noticed it doesn?t contain a `pubring.kbx`, > `pubring.gpg`, > or `secring.gpg`. > > I suspect this is because Arch, being a rolling release, uses a newer > version of GnuPG that doesn't require a pubring, while Pop!_OS is > using > an older version. > > Here?s what my .gnupg directory looks like: > > ``` > > ls .gnupg > > common.conf? openpgp-revocs.d/?? public-keys.d/? sshcontrol > crls.d/????? private-keys-v1.d/? random_seed???? trustdb.gpg > ``` > > Thanks for your help! Hello, As far as I know, the latest version of GPG use keyboxd to manage public keys (essentially a sqlite database, which supposedly offers better performance), and the database files are located in the public-keys.d directory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mike at mdsresource.net Wed Oct 9 20:55:15 2024 From: mike at mdsresource.net (Mike Schleif) Date: Wed, 9 Oct 2024 13:55:15 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <878quxp7c8.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> Message-ID: OK, we are making progress. Thank you. We used this page to rid ourselves of obsolete bad keys: http://stuff-things.net/2015/04/22/gpg-public-key-of-ultimately-trusted-key-00000000-not-found/ We continue to have trust level problems. When adding _all_ new keys from our clients, we always assign level 4 (fully) to each. On the legacy (v2.0.22) host, it looks like this: # /usr/bin/gpg --list-keys 571F553F pub 2048R/571F553F 2023-07-10 [expires: 2025-10-09] uid FISERV-SFG-NA-PROD-GPG-2K-23-193-01 (FISERV SFG NA PROD GPG 2K) sub 2048R/C71BDCEC 2023-07-10 [expires: 2025-10-09] However, on the new host (v2.3.3) the output is different: # /usr/bin/gpg --list-keys 571F553F pub rsa2048 2023-07-10 [SC] [expires: 2025-10-09] 41261F6446B51FDBD18FDDF8C4D62F13571F553F uid [ unknown] FISERV-SFG-NA-PROD-GPG-2K-23-193-01 (FISERV SFG NA PROD GPG 2K) sub rsa2048 2023-07-10 [E] [expires: 2025-10-09] Encrypting a file using that key, for example, fails thusly: gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named user The only solution we've found is to _manually_ edit each public key, and assign level 5 (ultimate) - which we are loathe to do. We do not want every key at level ultimate, and we do not want to manually edit hundreds of keys to change each trust level. What are we missing? Please, advise. Thank you. ~ Mike On Wed, Oct 9, 2024 at 11:30?AM Werner Koch wrote: > On Tue, 8 Oct 2024 13:09, Mike Schleif said: > > > Ought we do something on the legacy (v2.0.22) host before copying to the > > new host? > > I general not but you can do this: > > gpg --export >all-public-keys.gpg > gpg --export-secret-keys >all-secret-keys.gpg > gpg --export-ownertrust >ownertrust.txt > > also backup the *.conf files if you have some. > > On the new machine rename the existsing ~/.gnupg to ~/.gnupg-saved and > then run > > gpg -k > > which will create a new ~/.gnupg > > Then > > gpg --import gpg --import gpg --import-ownertrust gpg --check-trustdb > > That avoids any problem with garbage inthe ~/.gnupg. Check gpg.conf > whether you have any strange keys in them. Inb particular remove any > references to the old PGP-2 keys. > > > 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 alejandro at privacyrequired.com Wed Oct 9 20:43:01 2024 From: alejandro at privacyrequired.com (Alejandro) Date: Wed, 9 Oct 2024 20:43:01 +0200 Subject: GnuPG Keyring Issue Across Systems. Where is pubring.kbx? Message-ID: Hello, Thanks, Researching a little bit inside the files, I found a pubring.db How i can downgrade my .gnupg folder to make it compatible with older versions? Thanks again On 10/9/24 6:00 PM, Ming Kuang via Gnupg-users wrote: > On Wed, 2024-10-09 at 15:50 +0200, Alejandro via Gnupg-users wrote: >> Hi, >> >> I?m using the default GnuPG package from `pacman -S gnupg` on my Arch >> system. For security reasons, I copied my GNUPGHOME to a USB drive, >> which worked well when I mounted it as GNUPGHOME. >> >> However, I recently needed to use my keys on another machine running >> Pop!_OS 22.04. After decrypting my LUKS USB drive and exporting the >> GNUPGHOME to my .gnupg directory on the USB, I ran `gpg --list-keys`. >> This created a new `pubring.kdx`. Upon checking my main .gnupg >> directory, I noticed it doesn?t contain a `pubring.kbx`, >> `pubring.gpg`, >> or `secring.gpg`. >> >> I suspect this is because Arch, being a rolling release, uses a newer >> version of GnuPG that doesn't require a pubring, while Pop!_OS is >> using >> an older version. >> >> Here?s what my .gnupg directory looks like: >> >> ``` >> >> ls .gnupg >> >> common.conf? openpgp-revocs.d/?? public-keys.d/? sshcontrol >> crls.d/????? private-keys-v1.d/? random_seed???? trustdb.gpg >> ``` >> >> Thanks for your help! > Hello, > > As far as I know, the latest version of GPG use keyboxd to manage public > keys (essentially a sqlite database, which supposedly offers better > performance), and the database files are located in the public-keys.d > directory > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x9B029E4189816E4A.asc Type: application/pgp-keys Size: 3175 bytes Desc: OpenPGP public key URL: From wk at gnupg.org Thu Oct 10 09:34:47 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Oct 2024 09:34:47 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: (Mike Schleif's message of "Wed, 9 Oct 2024 13:55:15 -0500") References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> Message-ID: <874j5kpg14.fsf@jacob.g10code.de> On Wed, 9 Oct 2024 13:55, Mike Schleif said: > We do not want every key at level ultimate, and we do not want to manually > edit hundreds of keys to change each trust level. There is a an easier way: gpg --export-ownertrust >ownertrust.txt and then edit that file. You see lines like AEA84EDCF01AD86C4701C85C63113AE866587D0A:6: The first field is the fingerprint and the second field (6) gives the ownertrust value: #define TRUST_MASK 15 #define TRUST_UNKNOWN 0 /* o: not yet calculated/assigned */ #define TRUST_EXPIRED 1 /* e: calculation may be invalid */ #define TRUST_UNDEFINED 2 /* q: not enough information for calculation */ #define TRUST_NEVER 3 /* n: never trust this pubkey */ #define TRUST_MARGINAL 4 /* m: marginally trusted */ #define TRUST_FULLY 5 /* f: fully trusted */ #define TRUST_ULTIMATE 6 /* u: ultimately trusted */ /* Trust values not covered by the mask. */ #define TRUST_FLAG_REVOKED 32 /* r: revoked */ #define TRUST_FLAG_SUB_REVOKED 64 /* r: revoked but for subkeys */ #define TRUST_FLAG_DISABLED 128 /* d: key/uid disabled */ #define TRUST_FLAG_PENDING_CHECK 256 /* a check-trustdb is pending */ #define TRUST_FLAG_TOFU_BASED 512 /* The trust value is based on * the TOFU information. */ Thus setting the second fields to 5 and do a gpg --import-ownertrust < ownertrust.txt gpg --check-trustdb should do what you have in mind. But let me note that this is not an official API - it works but it may in theory be changed w/o notice. 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 Thu Oct 10 09:37:56 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Oct 2024 09:37:56 +0200 Subject: GnuPG Keyring Issue Across Systems. Where is pubring.kbx? In-Reply-To: (Alejandro via Gnupg-users's message of "Wed, 9 Oct 2024 20:43:01 +0200") References: Message-ID: <87zfnco1bf.fsf@jacob.g10code.de> On Wed, 9 Oct 2024 20:43, Alejandro said: > How i can downgrade my .gnupg folder to make it compatible with older > versions? For a new installation the option use-keyboxd is written to ~/.gnupg/common.conf. Uncomment that option and you are back to pubring.kbx. If you already have keys in the keyboxd, you should export them: gpg --export --export-options backup > all-keys.pub the edit common.conf and run gpg --import --import-options restore < all-keys.pub 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 Thu Oct 10 09:38:53 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Oct 2024 09:38:53 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: (Matthias Apitz's message of "Wed, 9 Oct 2024 09:45:10 +0200") References: <87h69oh0ue.fsf@city17.xyz> <87plo9py51.fsf@jacob.g10code.de> Message-ID: <87v7y0o19u.fsf@jacob.g10code.de> On Wed, 9 Oct 2024 09:45, Matthias Apitz said: > Could this tool be backported to 2.2 ? No. 2.2's end-of-life is Dezember 31 this year. 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 10 15:08:46 2024 From: mike at mdsresource.net (Mike Schleif) Date: Thu, 10 Oct 2024 08:08:46 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <874j5kpg14.fsf@jacob.g10code.de> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> <874j5kpg14.fsf@jacob.g10code.de> Message-ID: key: 41261F6446B51FDBD18FDDF8C4D62F13571F553F ownertrust.txt: 41261F6446B51FDBD18FDDF8C4D62F13571F553F:5: # /usr/bin/gpg --list-keys 9B51B2A5C71BDCEC pub rsa2048 2023-07-10 [SC] [expires: 2025-10-09] 41261F6446B51FDBD18FDDF8C4D62F13571F553F uid [ unknown] FISERV-SFG-NA-PROD-GPG-2K-23-193-01 (FISERV SFG NA PROD GPG 2K) sub rsa2048 2023-07-10 [E] [expires: 2025-10-09] encryption error: gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named user Is the _only_ solution to convert ALL keys to ultimate (6)? Please, advise. Thank you. ~ Mike On Thu, Oct 10, 2024 at 2:34?AM Werner Koch wrote: > On Wed, 9 Oct 2024 13:55, Mike Schleif said: > > > We do not want every key at level ultimate, and we do not want to > manually > > edit hundreds of keys to change each trust level. > > There is a an easier way: > > gpg --export-ownertrust >ownertrust.txt > > and then edit that file. You see lines like > > AEA84EDCF01AD86C4701C85C63113AE866587D0A:6: > > The first field is the fingerprint and the second field (6) gives the > ownertrust value: > > #define TRUST_MASK 15 > #define TRUST_UNKNOWN 0 /* o: not yet calculated/assigned */ > #define TRUST_EXPIRED 1 /* e: calculation may be invalid */ > #define TRUST_UNDEFINED 2 /* q: not enough information for calculation > */ > #define TRUST_NEVER 3 /* n: never trust this pubkey */ > #define TRUST_MARGINAL 4 /* m: marginally trusted */ > #define TRUST_FULLY 5 /* f: fully trusted */ > #define TRUST_ULTIMATE 6 /* u: ultimately trusted */ > /* Trust values not covered by the mask. */ > #define TRUST_FLAG_REVOKED 32 /* r: revoked */ > #define TRUST_FLAG_SUB_REVOKED 64 /* r: revoked but for subkeys */ > #define TRUST_FLAG_DISABLED 128 /* d: key/uid disabled */ > #define TRUST_FLAG_PENDING_CHECK 256 /* a check-trustdb is pending */ > #define TRUST_FLAG_TOFU_BASED 512 /* The trust value is based on > * the TOFU information. */ > > Thus setting the second fields to 5 and do a > > gpg --import-ownertrust < ownertrust.txt > gpg --check-trustdb > > should do what you have in mind. > > But let me note that this is not an official API - it works but it may > in theory be changed w/o notice. > > > 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 Bjorn at xn--rombobjrn-67a.se Thu Oct 10 17:09:42 2024 From: Bjorn at xn--rombobjrn-67a.se (=?UTF-8?B?QmrDtnJu?= Persson) Date: Thu, 10 Oct 2024 17:09:42 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> <874j5kpg14.fsf@jacob.g10code.de> Message-ID: <20241010170942.5b6db73e@tag.xn--rombobjrn-67a.se> Mike Schleif wrote: > ownertrust.txt: > 41261F6446B51FDBD18FDDF8C4D62F13571F553F:5: This is how much you trust the owner of that key when they sign other keys. Before you can trust the owner, you need to know who the key belongs to. > encryption error: > gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named > user Such assurance is provided by signing the key. Maybe the signatures have been lost somehow, or the key that signed all the other keys is missing or untrusted, or you never signed the keys in the first place. Use --list-sigs to see what signatures exist. Then use --check-sigs to see whether the signatures are valid. > Is the _only_ solution to convert ALL keys to ultimate (6)? You're supposed to verify that the key really does belong to "FISERV-SFG-NA-PROD-GPG-2K-23-193-01", and not to some attacker who is trying to fool you. After you have verified this, you assure it by signing the key with your own key. Then GPG will know that the key belongs to the named user. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signatur URL: From wk at gnupg.org Fri Oct 11 09:44:25 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Oct 2024 09:44:25 +0200 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <20241010170942.5b6db73e@tag.xn--rombobjrn-67a.se> (=?utf-8?Q?=22Bj=C3=B6rn?= Persson"'s message of "Thu, 10 Oct 2024 17:09:42 +0200") References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> <874j5kpg14.fsf@jacob.g10code.de> <20241010170942.5b6db73e@tag.xn--rombobjrn-67a.se> Message-ID: <877cafnkx2.fsf@jacob.g10code.de> On Thu, 10 Oct 2024 17:09, Bj?rn Persson said: > This is how much you trust the owner of that key when they sign other > keys. Before you can trust the owner, you need to know who the key > belongs to. Right, that is the case in the default trust model. My original answer was misleading. > Such assurance is provided by signing the key. Maybe the signatures > have been lost somehow, or the key that signed all the other keys is For example, in contrast to the command line the Kleopatra frontend creates non-exportable key signatures. On the command line or with edit-key you ca create such non-exportable signature by using --quick-lsign-key or "lsign". Now if you do an --export those signatures are not exported (they are non-exportable/local). GnuPG has a --export-option backup which exports everything but the old 2.0 version does not have this option. It might already have the "--export-options export-local-sigs", but I was not sure. Thus with 2.0 the export command gpg --export --export-options export-local-sigs >all-keys-with-all-sigs.pub might work. With 2.3 gpg --import --import-options restorre < all-keys-with-all-sigs.pub would do the jub. If the restore option is not yet implemented in that old 2.3 version it can be replaced by "import-local-sigs". 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 jcb62281 at gmail.com Sun Oct 13 04:36:54 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 12 Oct 2024 21:36:54 -0500 Subject: HOW to upgrade: 2.0.22 --> 2.3.3 ??? In-Reply-To: <20241010170942.5b6db73e@tag.xn--rombobjrn-67a.se> References: <87plogs55n.fsf@jacob.g10code.de> <878qv3sxxg.fsf@jacob.g10code.de> <87y12ypnzt.fsf@jacob.g10code.de> <878quxp7c8.fsf@jacob.g10code.de> <874j5kpg14.fsf@jacob.g10code.de> <20241010170942.5b6db73e@tag.xn--rombobjrn-67a.se> Message-ID: On 10/10/24 10:09, Bj?rn Persson wrote: > Mike Schleif wrote: > [...] >> encryption error: >> gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named >> user > Such assurance is provided by signing the key. Maybe the signatures > have been lost somehow, or the key that signed all the other keys is > missing or untrusted, or you never signed the keys in the first place. > Use --list-sigs to see what signatures exist. Then use --check-sigs to > see whether the signatures are valid. The thought occurs to me:? we already know that this user has a bunch of PGP2 keys in their keyring.? Could the local signatures intended to validate trust on other keys have been from now-unusable PGP2 keys? -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From 400thecat at ik.me Sun Oct 13 07:31:55 2024 From: 400thecat at ik.me (Fourhundred Thecat) Date: Sun, 13 Oct 2024 07:31:55 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: <87h69oh0ue.fsf@city17.xyz> References: <87h69oh0ue.fsf@city17.xyz> Message-ID: <2a035378-474f-003f-acf7-aad8727b6d54@ik.me> On 07/10/2024 08.40, jman wrote: > 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). thank you, but what is actually the command to unlock the agent without decrypting or signing a dummy file? same as I would do for ssh: ssh-add From mihirrabade at gmail.com Sun Oct 13 10:32:01 2024 From: mihirrabade at gmail.com (Mihir Rabade) Date: Sun, 13 Oct 2024 14:02:01 +0530 Subject: Pinentry programs not offering to save passwords Message-ID: Hello! I have configured git commit signing, which uses gpg. While trying to commit, a pinentry gui popup comes up where I enter the password for my gpg key. I also configured KeepassXC's Freedesktop secret service integration to save passwords after disabling kwallet & uninstalling gnome keyring. Installed apps are correctly querying the API & keepassxc notifies which process queried for password. (For eg Neochat, VS Code, Zed editor, etc) Now my issue is, that pinentry program is not offering to save passwords. Nor does it query for gpg password. This was working perfectly in KDE Neon with pinentry-gnome3. But not Fedora 40 or EndeavourOS. I even tried other pinentry programs (-gtk, -qt, -tty, -qt5, -gnome3...), but all of them ask for password on prompt and none offer to save password. I have even asked on respective OS forums: https://forum.endeavouros.com/t/pinentry-program-not-offering-to-save-password/60456 https://discussion.fedoraproject.org/t/pinentry-programs-not-offering-to-save-passwords/132129 But no luck. I'm currently using Endeavour OS & the pinentry version installed is 1.3.1-5 Any solutions on how to get any pinentry program to save passwords in secret service? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Oct 13 21:58:00 2024 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Sun, 13 Oct 2024 21:58:00 +0200 Subject: Pinentry programs not offering to save passwords In-Reply-To: References: Message-ID: <26604930.1r3eYUQgxm@daneel> On Sonntag, 13. Oktober 2024 10:32:01 MESZ Mihir Rabade via Gnupg-users wrote: > I have configured git commit signing, which uses gpg. While trying to > commit, a pinentry gui popup comes up where I enter the password for my gpg > key. > I also configured KeepassXC's Freedesktop secret service integration to > save passwords after disabling kwallet & uninstalling gnome keyring. > Installed apps are correctly querying the API & keepassxc notifies which > process queried for password. (For eg Neochat, VS Code, Zed editor, etc) > > Now my issue is, that pinentry program is not offering to save passwords. > Nor does it query for gpg password. > This was working perfectly in KDE Neon with pinentry-gnome3. > But not Fedora 40 or EndeavourOS. I even tried other pinentry programs > (-gtk, -qt, -tty, -qt5, -gnome3...), but all of them ask for password on > prompt and none offer to save password. The possibility to use a password manager via the secret service API is available in pinentry-qt*. I don't know anything about the others. Are you using KDE Plasma? In this case you will have to set the environment variable PINENTRY_KDE_USE_WALLET to a non-empty value. By default, pinentry- qt* will disable support for secret service if it detects that it's running in KDE Plasma to prevent a deadlock with KWallet using gpg to protect the passwords. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From mihirrabade at gmail.com Mon Oct 14 05:18:05 2024 From: mihirrabade at gmail.com (Mihir Rabade) Date: Mon, 14 Oct 2024 08:48:05 +0530 Subject: Pinentry programs not offering to save passwords In-Reply-To: <26604930.1r3eYUQgxm@daneel> References: <26604930.1r3eYUQgxm@daneel> Message-ID: I'm using KDE Plasma 6.2.0 I have disabled KDE Wallet integration. I have enabled KeepassXC's Secret Integration. I'm using Endeavour OS which is arch based. Earlier I referred https://wiki.archlinux.org/title/GnuPG#pinentry so I switched between pinentry, pinentry-gnome3, -gtk, -qt, -qt5, but it didn't work. Then I added in ~/.bashrc this: (and also checked https://dev.gnupg.org/D599 for any syntax issue) > export PINENTRY_KDE_USE_WALLET=1 Rebooted, switched through all pinentry programs (reloading gpg-agent on every switch). Still didn't work as expected, i.e., pinentry program didn't offer to save password. The result I'm expecting: Pinentry will offer to save passwords. And those passwords will get saved inside KeepassXC (as I enabled secret service integration) Steps I'm performing: I created a fresh new local git repository inside VS Code Created a new file Used commit editor in VS Code to write my commit Click on Commit button Pinentry pops up - doesn't offer to save password, let alone auto retrieve from KeepassXC On Mon, 14 Oct 2024 at 02:43, Ingo Kl?cker wrote: > On Sonntag, 13. Oktober 2024 10:32:01 MESZ Mihir Rabade via Gnupg-users > wrote: > > I have configured git commit signing, which uses gpg. While trying to > > commit, a pinentry gui popup comes up where I enter the password for my > gpg > > key. > > I also configured KeepassXC's Freedesktop secret service integration to > > save passwords after disabling kwallet & uninstalling gnome keyring. > > Installed apps are correctly querying the API & keepassxc notifies which > > process queried for password. (For eg Neochat, VS Code, Zed editor, etc) > > > > Now my issue is, that pinentry program is not offering to save passwords. > > Nor does it query for gpg password. > > This was working perfectly in KDE Neon with pinentry-gnome3. > > But not Fedora 40 or EndeavourOS. I even tried other pinentry programs > > (-gtk, -qt, -tty, -qt5, -gnome3...), but all of them ask for password on > > prompt and none offer to save password. > > The possibility to use a password manager via the secret service API is > available in pinentry-qt*. I don't know anything about the others. > > Are you using KDE Plasma? In this case you will have to set the > environment > variable PINENTRY_KDE_USE_WALLET to a non-empty value. By default, > pinentry- > qt* will disable support for secret service if it detects that it's > running in > KDE Plasma to prevent a deadlock with KWallet using gpg to protect the > passwords. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Mon Oct 14 13:40:51 2024 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Mon, 14 Oct 2024 13:40:51 +0200 Subject: Pinentry programs not offering to save passwords In-Reply-To: References: <26604930.1r3eYUQgxm@daneel> Message-ID: <4906623.OV4Wx5bFTl@daneel> On Montag, 14. Oktober 2024 05:18:05 MESZ Mihir Rabade via Gnupg-users wrote: > I'm using KDE Plasma 6.2.0 > I have disabled KDE Wallet integration. > I have enabled KeepassXC's Secret Integration. > I'm using Endeavour OS which is arch based. > > Earlier I referred https://wiki.archlinux.org/title/GnuPG#pinentry so I > switched between pinentry, pinentry-gnome3, -gtk, -qt, -qt5, but it didn't > work. > > Then I added in ~/.bashrc this: (and also checked https://dev.gnupg.org/D599 > for any syntax issue) > > > export PINENTRY_KDE_USE_WALLET=1 Try putting an executable shell script with this export line in a folder named $HOME/.config/plasma-workspace/env . This will make sure that the environment variable is known to all processes started in the Plasma session. See https://userbase.kde.org/Session_Environment_Variables for details. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From mihirrabade at gmail.com Mon Oct 14 15:24:22 2024 From: mihirrabade at gmail.com (Mihir Rabade) Date: Mon, 14 Oct 2024 18:54:22 +0530 Subject: Pinentry programs not offering to save passwords In-Reply-To: <4906623.OV4Wx5bFTl@daneel> References: <26604930.1r3eYUQgxm@daneel> <4906623.OV4Wx5bFTl@daneel> Message-ID: > > Try putting an executable shell script with this export line in a folder > named > $HOME/.config/plasma-workspace/env . I did that and found out that it still didn't work. But after removing that variable export from ~/.bashrc & reboot, it worked! Thanks for the solution! So here is the solution summary: This line: > export PINENTRY_KDE_USE_WALLET=1 > Should be put in a script located at: > $HOME/.config/plasma-workspace/env For eg: > $HOME/.config/plasma-workspace/env/pinentry-kde-fix.sh Should *not* be present inside ~/.bashrc else it won't work. On Mon, 14 Oct 2024 at 17:11, Ingo Kl?cker wrote: > On Montag, 14. Oktober 2024 05:18:05 MESZ Mihir Rabade via Gnupg-users > wrote: > > I'm using KDE Plasma 6.2.0 > > I have disabled KDE Wallet integration. > > I have enabled KeepassXC's Secret Integration. > > I'm using Endeavour OS which is arch based. > > > > Earlier I referred https://wiki.archlinux.org/title/GnuPG#pinentry so I > > switched between pinentry, pinentry-gnome3, -gtk, -qt, -qt5, but it > didn't > > work. > > > > Then I added in ~/.bashrc this: (and also checked > https://dev.gnupg.org/D599 > > for any syntax issue) > > > > > export PINENTRY_KDE_USE_WALLET=1 > > Try putting an executable shell script with this export line in a folder > named > $HOME/.config/plasma-workspace/env . > > This will make sure that the environment variable is known to all > processes > started in the Plasma session. See > https://userbase.kde.org/Session_Environment_Variables for details. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johh.soo at arista.com Mon Oct 14 20:27:21 2024 From: johh.soo at arista.com (John Soo) Date: Mon, 14 Oct 2024 12:27:21 -0600 Subject: Rectify agent/client mismatch 2.2.27/2.3.3 In-Reply-To: <87ttdmpnbg.fsf@jacob.g10code.de> References: <87ttdmpnbg.fsf@jacob.g10code.de> Message-ID: Hi there! Thank you for following up - after wiping the forwarded ~/.gnupg directory and trying again this was fixed. Could this be related to the keyboxd change? --- John -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at city17.xyz Fri Oct 18 11:37:09 2024 From: gnupg-users at city17.xyz (jman) Date: Fri, 18 Oct 2024 11:37:09 +0200 Subject: decrypting to stdout does not work properly In-Reply-To: <2a035378-474f-003f-acf7-aad8727b6d54@ik.me> (Fourhundred Thecat via Gnupg-users's message of "Sun, 13 Oct 2024 07:31:55 +0200") References: <87h69oh0ue.fsf@city17.xyz> <2a035378-474f-003f-acf7-aad8727b6d54@ik.me> Message-ID: <877ca57nwa.fsf@city17.xyz> Fourhundred Thecat via Gnupg-users writes: > thank you, but what is actually the command to unlock the agent without > decrypting or signing a dummy file? I'm not sure. I suspect that if you pipe the output of gpg-agent straight into something else it's difficult to catch a clean prompt for a passphrase. Do you have the env var $PINENTRY_USER_DATA set? When set to `tty` or `curses`, the prompt will be on the CLI (just like you're seeing now). Are you in a GUI Linux environment? If yes, you could try setting it to something else and it should popup a little GUI window (GTK, QT, etc.) to prompt for the passphrase. After you input your passphrase the output will be automatically piped to the next command. For this to work you need to install the correct pinentry-* package for your distribution. Hope this helps. Cheers, From buo.ren.lin at gmail.com Mon Oct 21 14:04:51 2024 From: buo.ren.lin at gmail.com (=?UTF-8?B?5p6X5Y2a5LuBQnVvLXJlbiBMaW4=?=) Date: Mon, 21 Oct 2024 20:04:51 +0800 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: Werner, First of all, apologies for the ignorance. > You should configure proxy settings and other keyserver options in > dirmngr.conf and not on the gpg comnand line or conf file. Thanks for the info, I'll check it out. > That is why we have our own resolver. The whole thing has been > explained in the ticket and elsewhere. GnuPG's resolver won't work for network environments that don't have a working DNS name resolution(including but not limited to some corporate networks and TetherFi[1]), GnuPG must delegate the resolution task to the proxy service[2] otherwise this behavior will only cause frustration for users in these networking scenarios. If GnuPG maintainers don't want to support these networking scenarios, please at least document it in the FAQ[3] so that affected users won't bother trying in the first place, thank you. Regards, ???(Buo-ren Lin) buo.ren.lin at gmail.com [1]: https://github.com/pyamsoft/tetherfi/issues/296 [2]: https://serverfault.com/a/352180 [3]: https://www.gnupg.org/faq/gnupg-faq.html From cozzovj at gmail.com Mon Oct 21 23:50:15 2024 From: cozzovj at gmail.com (Vincent Cozzo) Date: Mon, 21 Oct 2024 21:50:15 +0000 Subject: Question on Kyber Encryption (Key Gen) Message-ID: Hi GPG Users/Developers, I am doing research on Post Quantum Cryptography, and I had a question about the GPG 2.5.1 development release, since I read that it allegedly features an implementation of Kyber. >From analyzing the codebase (g10/keygen.c), it is clear that the only way to generate a Kyber public key is to add a _subkey_ to an existing ECC key (right?). But whenever I try to test this out (by creating a new ECC Key Pair and then edit it by adding a subkey with the numerical code 16), I keep getting the error: ``` gpg: agent_genkey failed for second algo: Invalid public key algorithm gpg: Key generation failed: Invalid public key algorithm ``` I see that `generate_subkeypair` calls ask_algo, which sets the algo parameter equal to PUKEY_ALGO_KYBER, and then delegates to `do_create` which calls `gen_kyber`... but I am having trouble finding where this particular error message is output. Could anyone help shed light on where this is failing? What "base Key" do I need to make in order to satisfy the "public key algorithm" requirement? Thanks, -Vince From wk at gnupg.org Tue Oct 22 12:34:27 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Oct 2024 12:34:27 +0200 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: (Vincent Cozzo via Gnupg-users's message of "Mon, 21 Oct 2024 21:50:15 +0000") References: Message-ID: <87jze01l58.fsf@jacob.g10code.de> Hi! On Mon, 21 Oct 2024 21:50, Vincent Cozzo said: > way to generate a Kyber public key is to add a _subkey_ to an existing > ECC key (right?). You can also do: gpg -v --quick-gen-key --batch \ --passphrase='' pqc-test-20241022 at example.org pqc Which generates such a key: sec brainpoolP384r1 2024-10-22 [SC] [expires: 2027-10-22] D9F7435AF96EF89EF5D4BD9E57396E9C2CA268E8 uid [ultimate] pqc-test-20241022 at example.org ssb ky768_bp256 2024-10-22 [E] 57A0441BF54B3149A52EBA962CACF19BFFA3555B60084B146D012D16E5BD2154 > But whenever I try to test this out (by creating a new ECC Key Pair > and then edit it by adding a subkey with the numerical code 16), I > keep getting the error: > ``` > gpg: agent_genkey failed for second algo: Invalid public key algorithm Let's try using my current developemnt tree but there have been no relevant changes since 2.5.1: $ gpg --edit-key D9F7435AF96EF89EF5D4BD9E57396E9C2CA268E8 gpg: WARNING: unsafe permissions on homedir '/home/wk/b/gnupg/test-pqc' gpg (GnuPG) 2.5.2-beta36; Copyright (C) 2024 g10 Code GmbH This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Secret key is available. sec brainpoolP384r1/57396E9C2CA268E8 created: 2024-10-22 expires: 2027-10-22 usage: SC trust: ultimate validity: ultimate ssb ky768_bp256/57A0441BF54B3149 created: 2024-10-22 expires: never usage: E [ultimate] (1). pqc-test-20241022 at example.org gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (10) ECC (sign only) (12) ECC (encrypt only) (14) Existing key from card (16) Kyber (encrypt only) Your selection? 16 Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec brainpoolP384r1/57396E9C2CA268E8 created: 2024-10-22 expires: 2027-10-22 usage: SC trust: ultimate validity: ultimate ssb ky768_bp256/57A0441BF54B3149 created: 2024-10-22 expires: never usage: E ssb ky768_bp256/F6BD9A2253968078 created: 2024-10-22 expires: never usage: E [ultimate] (1). pqc-test-20241022 at example.org > gpg: Key generation failed: Invalid public key algorithm Did you build with a proper Libgcrypt version? What is the output of gpgconf -V > I see that `generate_subkeypair` calls ask_algo, which sets the algo > parameter equal to PUKEY_ALGO_KYBER, and then delegates to `do_create` > which calls `gen_kyber`... but I am having trouble finding where this > particular error message is output. Could anyone help shed light on The above error messages is prinbted at several palces - thus it depends on the exact context of what you did. > where this is failing? What "base Key" do I need to make in order to > satisfy the "public key algorithm" requirement? You may use any primary key. Sometimes the option --expert is needed but not in this case. My gpg.conf only has a with-subkey-fingerprint line. 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: