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: From cozzovj at gmail.com Wed Oct 23 17:07:18 2024 From: cozzovj at gmail.com (Vincent Cozzo) Date: Wed, 23 Oct 2024 15:07:18 +0000 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: <87jze01l58.fsf@jacob.g10code.de> References: <87jze01l58.fsf@jacob.g10code.de> Message-ID: Hi Werner, If it helps at all, here is the stacktrace when I run my executable through GDB: ``` #0 common_gen (keyparms=keyparms at entry=0x55555569c920 "(genkey(ecc(curve 15:brainpoolP256r1)(flags nocomp)))", keyparms2=keyparms2 at entry=0x5555556471d7 "(genkey(kyber768))", algo=algo at entry=8, algoelem=algoelem at entry=0x55555564fa38 "", pub_root=pub_root at entry=0x55555568aa50, timestamp=timestamp at entry=1729663031, expireval=39312000, is_subkey=1, keygen_flags=4, passphrase=0x0, cache_nonce_addr=0x7fffffffe130, passwd_nonce_addr=0x7fffffffe138, common_gen_cb_parm=0x0, common_gen_cb=0x0) at ../../g10/keygen.c:1837 #1 0x00005555555dcf77 in gen_kyber (algo=8, common_gen_cb=0x0, common_gen_cb_parm=0x0, passwd_nonce_addr=0x7fffffffe138, cache_nonce_addr=0x7fffffffe130, passphrase=0x0, keygen_flags=0x7fffffffe108, is_subkey=1, expireval=39312000, timestamp=1729663031, pub_root=0x55555568aa50, curve=0x555555646e4d "brainpoolP256r1", nbits=) at ../../g10/keygen.c:2219 #2 do_create (algo=, nbits=, curve=, pub_root=pub_root at entry=0x55555568aa50, timestamp=timestamp at entry=1729663031, expiredate=39312000, is_subkey=1, keygen_flags=0x7fffffffe108, passphrase=0x0, cache_nonce_addr=0x7fffffffe130, passwd_nonce_addr=0x7fffffffe138, common_gen_cb_parm=0x0, common_gen_cb=0x0) at ../../g10/keygen.c:3731 #3 0x00005555555e5802 in generate_subkeypair (ctrl=ctrl at entry=0x55555568a9a0, keyblock=0x55555568aa50, algostr=algostr at entry=0x0, usagestr=usagestr at entry=0x0, expirestr=expirestr at entry=0x0) at ../../g10/keygen.c:6789 #4 0x0000555555579660 in keyedit_menu (ctrl=ctrl at entry=0x55555568a9a0, username=username at entry=0x55555567e990 "E32483030E004974DF9ABB322D2CB79326383D77", locusr=0x0, commands=, commands at entry=0x0, quiet=quiet at entry=0, seckey_check=seckey_check at entry=1) at ../../g10/keyedit.c:1801 #5 0x000055555556d543 in main (argc=, argv=) at ../../g10/gpg.c:4764 ``` So, the first `agent_genkey` call works just fine (`err` code is zero), but the subsequent agent_genkey returns `16777220`... Anyway, to answer your question: the result of gpgconf is: ``` gpgconf: running /usr/local/bin/dirmngr failed (exitcode=127): Success * GnuPG 2.5.1 (72ef316aab22cf9ec22c432747564cba7120ac86) GNU/Linux * Libgcrypt 1.11.0 (9d94d784) version:1.11.0:10b00:1.50:13200: cc:100201:gcc:10.2.1 20210110: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3: rnd-mod:getentropy: cpu-arch:x86:amd64: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-rdtsc: fips-mode:n::: rng-type:standard:1:3030000:1: compliance::: * GpgRT 1.50 (bb73261) [error: can't get further info] ``` So there is very possibly a problem with how I installed the new binary. In full disclosure, I tried to "compile" the GnuPG binaries without "installing" them, which might be the root cause of my errors. But I really don't understand how... I am setting the LD_LIBRARY_PATH so that the binaries should be using the new Libgcrypt 1.11.0 (and it is!). I'll keep testing and let you know if I solve it. Thanks, -Vince On Tue, Oct 22, 2024 at 10:34?AM Werner Koch wrote: > > 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 From gniibe at fsij.org Thu Oct 24 07:50:25 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Oct 2024 14:50:25 +0900 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: References: <87jze01l58.fsf@jacob.g10code.de> Message-ID: <87plnqf3ry.fsf@akagi.fsij.org> Hello, Vincent Cozzo wrote: > So, the first `agent_genkey` call works just fine (`err` code is > zero), but the subsequent agent_genkey returns `16777220`... [...] > So there is very possibly a problem with how I installed the new > binary. In full disclosure, I tried to "compile" the GnuPG binaries > without "installing" them, which might be the root cause of my errors. I think that this is the case. In this case, as the function name suggests (agent_genkey), it is actually the gpg-agent which uses libgcrypt for key generation. If your gpg-agent is using the old version of libgcrypt, it fails. For testing, you can invoke a shell under gpg-agent by doing like: $ export GNUPGHOME=$(mktemp -d) $ LD_LIBARRY_PATH= gpg-agent --daemon /bin/bash [...] $ gpg ... $ exit Then, followng gpg invocations will connect to the agent which runs with the LD_LIBARRY_PATH specified. -- From jason at devnullwiththeboys.com Sun Oct 27 23:58:07 2024 From: jason at devnullwiththeboys.com (jason laughman) Date: Sun, 27 Oct 2024 18:58:07 -0400 Subject: MacOS "dyld[58144]: missing symbol called" on import Message-ID: <5D6D1E1D-54B5-4D0B-B396-E9C1ADEA53A5@devnullwiththeboys.com> I recently built and installed GnuPG and required libraries from scratch. What led me down that road was I wanted to update bash on my MacOS 14.7 (Sonoma) machine and needed to verify the download. All of this was done manually from the CLI using configure & make, not a package manager. I had to make two changes to get all the reqs to build, one was a three-line patch to fix environ not being created (I forget which package that was, maybe libgpg-error), and another was to add std=gnu98 to CFLAGS for libassuan to fix a duplicate symbol error. Other than those two changes, everything compiled and installed cleanly and the gpg binary mostly appears to work, but importing keys fails thusly: $ gpg -v --import ./sign.asc gpg: enabled compatibility flags: gpg: pub rsa3072/BCEF7E294B092E28 2017-03-17 Andre Heinecke (Release Signing Key) dyld[58268]: missing symbol called Abort trap: 6 This happens with 2.5.1 and 2.4.5 when using a file as an arg, redirecting stdin, or c&p the contents of sign.asc directly. sign.asc is the ASCII contents of https://gnupg.org/signature_key.asc. I also tried with the .asc of the bash maintainer and got the same results. If I try to verify a .sig, I get this (I understand this is expected behavior, I?m just showing that the binary I built works in other use cases): $ gpg -dv gnupg-2.5.1.tar.bz2.sig gpg: enabled compatibility flags: gpg: assuming signed data in 'gnupg-2.5.1.tar.bz2' gpg: Signature made Thu Sep 12 05:51:57 2024 EDT gpg: using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA gpg: Can't check signature: No public key gpg: Signature made Thu Sep 12 22:55:28 2024 EDT gpg: using EDDSA key AC8E115BF73E2D8D47FA9908E98E9B2D19C6C8BD gpg: Can't check signature: No public key -------------- next part -------------- An HTML attachment was scrubbed... URL: From cozzovj at gmail.com Mon Oct 28 17:25:07 2024 From: cozzovj at gmail.com (Vincent Cozzo) Date: Mon, 28 Oct 2024 16:25:07 +0000 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: <87plnqf3ry.fsf@akagi.fsij.org> References: <87jze01l58.fsf@jacob.g10code.de> <87plnqf3ry.fsf@akagi.fsij.org> Message-ID: Hey all, I do have an update on this effort, though to make a long story short, "the code works and I don't know why." When I try to install gpg 2.5.1 "system-wide," the executables end up in /usr/local/bin. This sounds fine and normal, but in this state, I encounter two problems: 1. the prior error regarding "invalid public key alg" and even the gpgconf error persist; 2. when I try to do an `apt update`, the package manager gets confused and says "Unknown error executing apt-key." Thankfully, I can remedy this error by overwriting the /usr/local/bin executables with version 2.4.5 of the library. if I try setting the GNUPGHOME variable (which is something I admit I do not fully understand) and then copy the "pinentry" binaries to the right directory, the system actually works and generates a Kyber key -- and encryption/decryption appears to work when selecting that subkey! In any case, thank you so much. -Vince On Thu, Oct 24, 2024 at 5:50?AM NIIBE Yutaka wrote: > > Hello, > > Vincent Cozzo wrote: > > So, the first `agent_genkey` call works just fine (`err` code is > > zero), but the subsequent agent_genkey returns `16777220`... > [...] > > So there is very possibly a problem with how I installed the new > > binary. In full disclosure, I tried to "compile" the GnuPG binaries > > without "installing" them, which might be the root cause of my errors. > > I think that this is the case. In this case, as the function name > suggests (agent_genkey), it is actually the gpg-agent which uses > libgcrypt for key generation. If your gpg-agent is using the old > version of libgcrypt, it fails. > > For testing, you can invoke a shell under gpg-agent by doing like: > > $ export GNUPGHOME=$(mktemp -d) > $ LD_LIBARRY_PATH= gpg-agent --daemon /bin/bash > [...] > $ gpg ... > $ exit > > Then, followng gpg invocations will connect to the agent which > runs with the LD_LIBARRY_PATH specified. > -- From kloecker at kde.org Mon Oct 28 22:07:45 2024 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Mon, 28 Oct 2024 22:07:45 +0100 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: References: <87plnqf3ry.fsf@akagi.fsij.org> Message-ID: <2280862.vFx2qVVIhK@daneel> On Montag, 28. Oktober 2024 17:25:07 Mitteleurop?ische Normalzeit Vincent Cozzo via Gnupg-users wrote: > I do have an update on this effort, though to make a long story short, > "the code works and I don't know why." > > When I try to install gpg 2.5.1 "system-wide," the executables end up > in /usr/local/bin. This sounds fine and normal, but in this state, I > encounter two problems: > 1. the prior error regarding "invalid public key alg" and even the > gpgconf error persist; > 2. when I try to do an `apt update`, the package manager gets confused > and says "Unknown error executing apt-key." Thankfully, I can remedy > this error by overwriting the /usr/local/bin executables with version > 2.4.5 of the library. > > if I try setting the GNUPGHOME variable (which is something I admit I > do not fully understand) and then copy the "pinentry" binaries to the > right directory, the system actually works and generates a Kyber key > -- and encryption/decryption appears to work when selecting that > subkey! Maybe systemd gets in the way and starts a gpg-agent 2.4.5 which doesn't know anything about Kyber and therefore trying to create a key with your self- compiled gpg 2.5.1 fails. If you use a different GNUPGHOME then systemd's socket activation cannot get into the way. Usually gpg warns you if an older gpg-agent is running. So, unless you ignored this warning there's probably something else mixed up on your system. 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 wk at gnupg.org Tue Oct 29 10:05:37 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Oct 2024 10:05:37 +0100 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: (Vincent Cozzo via Gnupg-users's message of "Mon, 28 Oct 2024 16:25:07 +0000") References: <87jze01l58.fsf@jacob.g10code.de> <87plnqf3ry.fsf@akagi.fsij.org> Message-ID: <87plnjuvmm.fsf@jacob.g10code.de> Hi! you should really set aside problems wit the distribution and use the speedo variant to build eberthing. This is somewhat similar to an AppImage. From the README: To quickly build all required software without installing it, the Speedo target may be used: make -f build-aux/speedo.mk native This target downloads all required libraries and does a native build of GnuPG to PLAY/inst/. GNU make and the patchelf tool are required. After the build the entire software including all libraries can be installed into an arbitrary location using for example: make -f build-aux/speedo.mk install SYSROOT=/usr/local/gnupg26 and run the binaries like /usr/local/gnupg26/bin/gpg which will also start any daemon from the same directory. Make sure to stop already running daemons or use a different GNUPGHOME. We may eventually extend gpgconf.ctl file to allow setting of a different default home directory. For now you can use the GNUPGHOME envvar which also steps aside problems with systemd. 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 29 15:20:51 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Oct 2024 15:20:51 +0100 Subject: [Announce] GnuPG 2.4.6 released Message-ID: <87frofuh18.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: version 2.4.6. This version fixes a couple of bugs, comes with a few new features, and has now full support for Portuguese. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.4.6 =================================== * gpg: New command --quick-set-ownertrust. [rG967678d972] * gpg: Indicate disabled keys in key listings and add list option "show-ownertrust". [rG2a0a706eb2] * gpg: Make sure a DECRYPTION_OKAY is never issued for a bad OCB tag. [T7042] * gpg: Do not allow to accidently set the RENC usage. [T7072] * gpg: Accept armored files without CRC24 checksum. [T7071] * gpg: New --import-option "only-pubkeys". [T7146] * gpg: Repurpose the AKL mechanism "ldap" to work like the keyserver mechnism but only for LDAP keyservers. [rG6551281ca3] * gpg: ADSKs are now configurable for new keys. [T6882] * gpg: New option --proc-all-sigs. [T7261] * gpg: Fix a wrong decryption failed status for signed and OCB encrypted messages without a signature verification key. [T7042] * gpg: Make --no-literal work again for -c and --store. [T5852] * gpg: Fix getting key by IPGP. [T7288] * gpg: Validate the trustdb after the import of a trusted key. [T7200] * gpg: Exclude expired trusted keys from the key validation process. [T7200] * gpgsm: New option --assert-signer. [T7286] * gpgsm: Emit user IDs with an empty Subject also in colon mode. [T7171] * keyboxd: Fix a race condition on the database handle. [T7294] * agent: Consider an empty pattern file as valid. [rGc27534de95] * agent: Fix error handling of READKEY. [T6012] * agent: Avoid random errors when storing key in ephemeral mode. [T7129, rG19d93a239d] * agent: Make "SCD DEVINFO --watch" more robust. [T7151] * agent: Fix detection of the yet unused trustflag de-vs. [T5079] * scd: Improve KDF data object handling for OpenPGP cards. [T7058] * scd: Avoid buffer overrun with more than 16 PC/SC readers. [T7129, rG524e3a9345] * scd: Fix how the scdaemon on its pipe connection finishes. [T7160] * gpgconf: Check readability of some files with -X and change its output format. [rG759adb2493] * gpg-mail-tube: New tool to apply PGP/MIME encryption to a mail. [rGa564a9f66c] * Fix a race condition in creating the socket directory. [T7332] * Fix some uninitialized variables and double frees in error code paths. [T7129] Release-info: https://dev.gnupg.org/T7030 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.6.tar.bz2 (7923k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.6.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.6_20241029.exe (5488k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.6_20241029.exe.sig The source used to build this Windows installer can be found in the same directory with a ".tar.xz" suffix. A new release of Gpg4win has not yet been done because we are still working on GUI improvements. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.4.6.tar.bz2 you would use this command: gpg --verify gnupg-2.4.6.tar.bz2.sig gnupg-2.4.6.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.4.6.tar.bz2, you run the command like this: sha1sum gnupg-2.4.6.tar.bz2 and check that the output matches the next line: 2d8aa2662c398d60f1f8e0bf46fd163eae703189 gnupg-2.4.6.tar.bz2 f296bcb4e252975b818246771102f8db057e24ad gnupg-w32-2.4.6_20241029.tar.xz 6d6b2017152fea4532afe38ce00e38a438b1e4bb gnupg-w32-2.4.6_20241029.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7030 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From cozzovj at gmail.com Tue Oct 29 17:29:02 2024 From: cozzovj at gmail.com (Vincent Cozzo) Date: Tue, 29 Oct 2024 16:29:02 +0000 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: <87plnjuvmm.fsf@jacob.g10code.de> References: <87jze01l58.fsf@jacob.g10code.de> <87plnqf3ry.fsf@akagi.fsij.org> <87plnjuvmm.fsf@jacob.g10code.de> Message-ID: One minor correction: I'm not running systemd (there's a reason I run Devuan!). But still, maybe there's a sysvinit thing that is doing a similar operation, who knows. Thanks for the response. I will have to read this more thoroughly. On Tue, Oct 29, 2024 at 9:04?AM Werner Koch wrote: > Hi! > > you should really set aside problems wit the distribution and use the > speedo variant to build eberthing. This is somewhat similar to an > AppImage. From the README: > > To quickly build all required software without installing it, the > Speedo target may be used: > > make -f build-aux/speedo.mk native > > This target downloads all required libraries and does a native build > of GnuPG to PLAY/inst/. GNU make and the patchelf tool are > required. After the build the entire software including all > libraries can be installed into an arbitrary location using for > example: > > make -f build-aux/speedo.mk install SYSROOT=/usr/local/gnupg26 > > and run the binaries like > > /usr/local/gnupg26/bin/gpg > > which will also start any daemon from the same directory. Make sure > to stop already running daemons or use a different GNUPGHOME. > > We may eventually extend gpgconf.ctl file to allow setting of a > different default home directory. For now you can use the GNUPGHOME > envvar which also steps aside problems with systemd. > > > Salam-Shalom, > > Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schmtzway at yahoo.com Tue Oct 29 16:50:15 2024 From: schmtzway at yahoo.com (wayne schlemitz) Date: Tue, 29 Oct 2024 15:50:15 +0000 (UTC) Subject: using aes256 References: <1001830981.7587704.1730217015676.ref@mail.yahoo.com> Message-ID: <1001830981.7587704.1730217015676@mail.yahoo.com> I am having no luck with trying to encrypt a file with a key that I would like to use.this is the command I used:??? gpg -e -a --symmetric --cipher-algo AES256 -k keysupplied --input file.txt --output file .gpgwhat am I doing incorrect?Is AES256 using ecb or cbc mode?Can I use my key that with this system? Appreciate your help with this.Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Oct 29 19:07:46 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Oct 2024 14:07:46 -0400 Subject: using aes256 In-Reply-To: <1001830981.7587704.1730217015676@mail.yahoo.com> References: <1001830981.7587704.1730217015676.ref@mail.yahoo.com> <1001830981.7587704.1730217015676@mail.yahoo.com> Message-ID: Please don't send HTML to this list. Some of the people you really hope will see your email won't look at HTML email. :) > I am having no luck with trying to encrypt a file with a key that I > would like to use. This isn't really a GnuPG use case. If you're looking for an AES256 encryption or decryption tool there are other things that will work better. GnuPG is pretty tightly integrated with RFC4880, which means your output won't just be AES256 but AES256 with additional metadata, framing, etc. > this is the command I used:??? gpg -e -a --symmetric --cipher-algo > AES256 -k keysupplied --input file.txt --output file .gpg Are you sure that -k does what you think? Try running "gpg -k". -k lists the available public certificates. It doesn't specify a symmetric key to use. :) Unfortunately, I don't remember offhand whether there's a command-line flag to force a particular AES256 key. Hope this helps! -------------- 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 rjh at sixdemonbag.org Tue Oct 29 19:21:15 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Oct 2024 14:21:15 -0400 Subject: using aes256 In-Reply-To: <1001830981.7587704.1730217015676@mail.yahoo.com> References: <1001830981.7587704.1730217015676.ref@mail.yahoo.com> <1001830981.7587704.1730217015676@mail.yahoo.com> Message-ID: <6726929a-919d-4554-b848-5428c2a31e7f@sixdemonbag.org> > Is AES256 using ecb or cbc mode? Depends on which version of GnuPG you're using. Older versions used an idiosyncratic cipher feedback mode, newer versions use counter mode (I believe). From dgouttegattat at incenp.org Tue Oct 29 20:41:52 2024 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 29 Oct 2024 19:41:52 +0000 Subject: using aes256 In-Reply-To: References: <1001830981.7587704.1730217015676.ref@mail.yahoo.com> <1001830981.7587704.1730217015676@mail.yahoo.com> Message-ID: <26621099.1r3eYUQgxm@borealin.local.incenp.org> On Tuesday, 29 October 2024 18:07:46 GMT Robert J. Hansen via Gnupg-users wrote: > Unfortunately, I don't remember offhand whether there's a command-line > flag to force a particular AES256 key. There is --override-session-key, but IIRC it can only be used to *decrypt*, not *encrypt*. I agree with the assertion that this not a GnuPG use case. That --override-session-key option (which incidentally is listed in the man page in the ?stuff you normally don?t want to do? section :D ) is only intended to allow someone to decrypt a message (e.g. if legally obliged to do so) without handing over their private secret key, it?s not for routine use. - Damien -------------- 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 ralph at ml.seichter.de Wed Oct 30 02:53:08 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Wed, 30 Oct 2024 02:53:08 +0100 Subject: call to undeclared function 'write' (Re: GnuPG 2.4.6 released) In-Reply-To: <87frofuh18.fsf@jacob.g10code.de> References: <87frofuh18.fsf@jacob.g10code.de> Message-ID: * Werner Koch via Gnupg-users: > We are pleased to announce the availability of a new stable GnuPG > release: version 2.4.6. I am having problems building version 2.4.6 on macOS (Sequoia). The compiler reports errors like this one: app.c:386:5: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] Please see the attached build log excerpt for more information. -Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: build-1730252509.log Type: text/x-log Size: 3678 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 30 09:54:00 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2024 09:54:00 +0100 Subject: call to undeclared function 'write' (Re: GnuPG 2.4.6 released) In-Reply-To: (Ralph Seichter via Gnupg-users's message of "Wed, 30 Oct 2024 02:53:08 +0100") References: <87frofuh18.fsf@jacob.g10code.de> Message-ID: <877c9qug2f.fsf@jacob.g10code.de> On Wed, 30 Oct 2024 02:53, Ralph Seichter said: > I am having problems building version 2.4.6 on macOS (Sequoia). The > compiler reports errors like this one: > > app.c:386:5: error: call to undeclared function 'write'; ISO C99 and I see, unistd.h is missing. It has not been backported from master's commit 1d5cfa9b7fd22e1c46eeed5fa9fed2af6f81d34f . Thanks for reporting. 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 Wed Oct 30 10:00:51 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2024 10:00:51 +0100 Subject: using aes256 In-Reply-To: <6726929a-919d-4554-b848-5428c2a31e7f@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Tue, 29 Oct 2024 14:21:15 -0400") References: <1001830981.7587704.1730217015676.ref@mail.yahoo.com> <1001830981.7587704.1730217015676@mail.yahoo.com> <6726929a-919d-4554-b848-5428c2a31e7f@sixdemonbag.org> Message-ID: <8734keufr0.fsf@jacob.g10code.de> On Tue, 29 Oct 2024 14:21, Robert J. Hansen said: > Depends on which version of GnuPG you're using. Older versions used > an idiosyncratic cipher feedback mode, newer versions use counter mode The classical mode is CFB with a slightly different handling of the IV. Modern versions create keys which indicate that OCB mode is to be used. OCB mode only used if the keys of all recipients carry that capability information. Or you use --force-ocb for symmetric-only or if you want to ignore the capabilities announced by the keys. Counter modes are evil and thus not used. 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: