From u.kleine-koenig at baylibre.com Fri May 2 16:07:38 2025 From: u.kleine-koenig at baylibre.com (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=) Date: Fri, 2 May 2025 16:07:38 +0200 Subject: list option show-unusable-uids has no effect on show-only-fpr-mbox output In-Reply-To: <202504171004.54827.bernhard@intevation.de> References: <202504171004.54827.bernhard@intevation.de> Message-ID: Hello Bernhard, sorry for not replying earlier, I missed your mail as I'm not subscribed to gnupg-users. On Thu, Apr 17, 2025 at 10:04:48AM +0200, Bernhard Reiter via Gnupg-users wrote: > using gnupg 2.2.40-1.1 on Debian GNU/Linux > I can confirm the behaviour you are seeing. > > rm -r ~/tmp/dot.gnupg/ > GNUPGHOME=~/tmp/dot.gnupg/ bash > gpg --locate-external-keys \ > mkorpershoek at baylibre.com u.kleine-koenig at baylibre.com > > gpg --list-options show-unusable-uids--list-keys > gpg --list-options \ > show-unusable-uids,show-only-fpr-mbox --list-keys > > interesting enough adding --with-colons does show both pubkeys. > > Am Dienstag 15 April 2025 16:17:44 schrieb Uwe Kleine-K?nig: > > To generate the WKD content, I'm using > > > > test at taurus:~$ gpg --list-options show-only-fpr-mbox,show-unusable-uids > > --list-keys 0D2511F322BFAB1C1580266BE2DCDD9132669BD6 > > u.kleine-koenig at baylibre.com > > > > (and pipe that into `gpg-wks-client -C $docroot --install-key`). > > Because you are using it in a script, --with-colons is usually recommended to > keep the interface more stable. That does not easily output the email > address. I switched from using gpg --list-options show-only-fpr-mbox,show-unusable-uids --list-public-keys to gpg --with-colons --list-public-keys | awk -F: '$1 == "fpr" { fpr = $10 } $1 == "uid" { email = gensub("^[^<]*<([^>]*)>$", "\\1", "g", $10);if (email != $10) { print fpr " " email } }' > > Here the list-option `show-unusable-uids` doesn't have the desired > > effect and no line is generated for Mattijs's key and email address. > > I wonder if this is a defect at all as the documentation says: > > https://gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-list_002doptions_003ashow_002donly_002dfpr_002dmbox > > | For each user-id which has a valid mail address print > | only the fingerprint followed by the mail address. > > As the user-id is revoked, > it somehow is not a _valid_ email address, isn't it? Depends on the definition of valid email address I guess. I would claim that revoking an uid doesn't make the contained email address invalid. What you read from there is something I'd describe as: For each valid user-id which has a mail address print only the fingerprint followed by the mail address. *shrug* that's a very little detail. > > With `show-unusable-uids` in the list-options I would have expected that > > had this effect on the fpr-mbox listing in the same way as on the > > default format. > > I also wonder: > What sense would it make to put a pubkey for an invalid uid on the WKD? The baylibre WKD published the key belonging to mkorpershoek at baylibre.com in the past and both the company and Mattijs don't want that key/email combo to be used in the future. So it makes sense to distribute the revoked uid. > However either the documentation or the behaviour could be improved somehow I > guess. Ack, I'd argue that "valid" is dropped from the documentation to rule out your interpretation of it, and fix `--list-options show-only-fpr-mbox,show-unusable-uids` to behave consistent as I expected it. Best regards Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From wk at gnupg.org Tue May 6 11:48:49 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 May 2025 11:48:49 +0200 Subject: S/MIME which certificate format In-Reply-To: <20241105171135.6d3d4807@ryz.dorfdsl.de> (Marco Moock via Gnupg-users's message of "Tue, 5 Nov 2024 17:11:35 +0100") References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> Message-ID: <87wmau3w8u.fsf@jacob.g10code.de> Hi! This is a bit late for a reply but for the records: On Tue, 5 Nov 2024 17:11, Marco Moock said: > m at ryz:~$ gpgsm --show-cert zertifikat-smime/PKCS7_File/PKCS7.p7b > gpgsm: enabled debug flags: ipc > gpgsm: enabled compatibility flags: > gpgsm: ksba_cert_hash failed: Kein Wert > gpgsm: ksba_cert_hash failed: Kein Wert Using current GnuPG (master, 2.5.6-beta): I get this: ID: 0x520AB3F9 S/N: 00CDB882CF52A4258A4CB6FA03C415DDBD (dec): 273449774896932489317308577343912402365 Issuer: CN=Sectigo RSA Client Authentication and Secure Email CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB Subject: [error] aka: sha2_fpr: DE:DB:58:6F:AA:72:31:A2:91:5C:FC:1E:55:27:77:3C:F0:27:03:DB:28:CB:83:BE:49:15:0A:01: which sounds okay. gpgsm (GnuPG) 2.4.8-beta3 libgcrypt 1.11.0 libksba 1.6.7-beta9 works fine as well. A likely fix was this one in Libksba Noteworthy changes in version 1.6.7 (2024-06-21) [C22/A14/R7] ------------------------------------------------ * Allow for an empty Subject in certs. [T7171] I assume that you used a 1.6.6 or older. 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 May 6 12:14:32 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 May 2025 12:14:32 +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: <87seli3v1z.fsf@jacob.g10code.de> Hi! Yeah an old mail from your but let me explain the problem: On Tue, 1 Oct 2024 17:40, Albrecht Dre? said: > 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 > This signature is a certificate-only message: $ ~/b/libksba/tests/t-cms-parser SIG.bin *** checking `SIG.bin' *** identified as: signed data stop reason: 2 ContentType: 1.2.840.113549.1.7.2 stop reason: 3 EncapsulatedContentType: 1.2.840.113549.1.7.1 DigestAlgorithms: 2.16.840.1.101.3.4.2.1 Detached signature stop reason: 6 this is a certs-only message *** all checks done This is a dump of your signature 0 1294: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 1279: [0] { 19 1275: SEQUENCE { 23 1: INTEGER 1 26 15: SET { 28 13: SEQUENCE { 30 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) 41 0: NULL : } : } 43 11: SEQUENCE { 45 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 56 869: [0] { 60 865: SEQUENCE { 64 457: SEQUENCE { 68 3: [0] { 70 1: INTEGER 2 : } [...] And here is a proper detached signature: 0 NDEF: SEQUENCE { 2 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 17 1: INTEGER 1 20 13: SET { 22 11: SEQUENCE { 24 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) : } : } 35 11: SEQUENCE { 37 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 48 8613: [0] { 52 1965: SEQUENCE { 56 1429: SEQUENCE { 60 3: [0] { 62 1: INTEGER 2 : } [...] Your signature is missing the part of the signature which is in the proper signature from offset 17..47. Instead it starts off directly with the list of certificates indicated by a context tag 0 at offset 15 which starts in the proper signature at offset 35 What we should do is to print a message that this is a cert-only signature in the same way the LibKSBA test tool does it. 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 mm at dorfdsl.de Tue May 6 17:11:37 2025 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 6 May 2025 17:11:37 +0200 Subject: S/MIME which certificate format In-Reply-To: <87wmau3w8u.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87wmau3w8u.fsf@jacob.g10code.de> Message-ID: <20250506171128.3d18c562@ryz.dorfdsl.de> Am 06.05.2025 um 11:48:49 Uhr schrieb Werner Koch: > On Tue, 5 Nov 2024 17:11, Marco Moock said: > > m at ryz:~$ gpgsm --show-cert zertifikat-smime/PKCS7_File/PKCS7.p7b > > gpgsm: enabled debug flags: ipc > > gpgsm: enabled compatibility flags: > > gpgsm: ksba_cert_hash failed: Kein Wert > > gpgsm: ksba_cert_hash failed: Kein Wert > > Using current GnuPG (master, 2.5.6-beta): I get this: > > ID: 0x520AB3F9 > S/N: 00CDB882CF52A4258A4CB6FA03C415DDBD > (dec): 273449774896932489317308577343912402365 > Issuer: CN=Sectigo RSA Client Authentication and Secure Email > CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB Subject: > [error] aka: > sha2_fpr: > DE:DB:58:6F:AA:72:31:A2:91:5C:FC:1E:55:27:77:3C:F0:27:03:DB:28:CB:83:BE:49:15:0A:01: > > which sounds okay. > > gpgsm (GnuPG) 2.4.8-beta3 > libgcrypt 1.11.0 > libksba 1.6.7-beta9 > > works fine as well. A likely fix was this one in Libksba > > Noteworthy changes in version 1.6.7 (2024-06-21) [C22/A14/R7] > ------------------------------------------------ > > * Allow for an empty Subject in certs. [T7171] > > I assume that you used a 1.6.6 or older. I used libksba8:amd64 1.6.7-2+b1 gnupg 2.4.7-17 and those versions give an error, so it is not only the libksba 1.6.6 version. gpgsm: ksba_cert_hash failed: Kein Wert ksba: ber-decoder: node `?': TLV length too large File ........: zertifikat-smime/PKCS7_File/PKCS7.p7b ID: 0xFFFFFFFF S/N: keine (dec): keine Issuer: [error] Subject: [error] sha2_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF sha1_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF md5_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF certid: error keygrip: error notBefore: keine notAfter: keine hashAlgo: (null) keyType: [error] subjKeyId: [none] authKeyId: [none] keyUsage: [none] extKeyUsage: [none] policies: [none] chainLength: [none] crlDP: [none] authInfo: [none] subjInfo: [none] If needed, I can try to build other versions, but this takes time as I have to create Debian packets first. Most systems need gnupg and I can't manually build and install it, as is breaks the dependency system. -- Gru? Marco Send unsolicited bulk mail to 1746524929muell at cartoonies.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From u.kleine-koenig at baylibre.com Tue May 6 21:58:33 2025 From: u.kleine-koenig at baylibre.com (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=) Date: Tue, 6 May 2025 21:58:33 +0200 Subject: gpg --with-colon contains non-UTF-8 data Message-ID: <3didbomwcocpq7r7fxrvisw2p54j6z7k5pbitxpj5foufdap22@v3mgt2i4uc2v> Hello, [I would have put this in the bug tracker, but I cannot create an account there. The hint says to request access on the mailing list, but https://lists.gnupg.org/pipermail/gnupg-users/2025-April/067578.html didn't work. So here comes another bug report on this mailing list.] $ gpg --version gpg (GnuPG) 2.4.7 libgcrypt 1.11.0 Copyright (C) 2024 g10 Code GmbH 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: /home/uwe/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ gpg --recv-keys --keyserver hkps://keyserver.ubuntu.com DE6162B5616BA9C9CAAC03074A55C497F744F705 ... $ gpg --list-keys --with-colons DE6162B5616BA9C9CAAC03074A55C497F744F705 | file - /dev/stdin: ISO-8859 text file considers this ISO-8859 because one of the UIDs isn't proper UTF-8, but "Toke H?iland-J?rgensen " encoded in latin1. It's clear that this UID is invalid, but I'd claim that there is a bug in the documentation (gpg(1) claims in the description for --with-colons that the output is UTF-8) or in gpg itself (because it doesn't quote the invalid chars). Fun fact: Without --with-colons the UID is emitted as: uid [ unknown] Toke H\xf8\x69land-J\xf8\x72gensen which is UTF-8 and needlessly encodes the i and the r following the two ? as hex escape. I wonder if cleaning the key should remove that UID? Best regards U\x77e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From kloecker at kde.org Wed May 7 09:26:00 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Wed, 07 May 2025 09:26:00 +0200 Subject: gpg --with-colon contains non-UTF-8 data In-Reply-To: <3didbomwcocpq7r7fxrvisw2p54j6z7k5pbitxpj5foufdap22@v3mgt2i4uc2v> References: <3didbomwcocpq7r7fxrvisw2p54j6z7k5pbitxpj5foufdap22@v3mgt2i4uc2v> Message-ID: <3624498.dWV9SEqChM@daneel> On Dienstag, 6. Mai 2025 21:58:33 Mitteleurop?ische Sommerzeit Uwe Kleine- K?nig wrote: > [I would have put this in the bug tracker, but I cannot create an > account there. The hint says to request access on the mailing list, but > https://lists.gnupg.org/pipermail/gnupg-users/2025-April/067578.html > didn't work. So here comes another bug report on this mailing list.] I guess Werner overlooked your request for an account. > $ gpg --recv-keys --keyserver hkps://keyserver.ubuntu.com > DE6162B5616BA9C9CAAC03074A55C497F744F705 ... > $ gpg --list-keys --with-colons DE6162B5616BA9C9CAAC03074A55C497F744F705 | > file - /dev/stdin: ISO-8859 text The relevant output is uid:-::::1254225361::DAE1213A33A1912544622223DEA25CE02D212561::Toke H?iland- J?rgensen :::::::::1746601390:1: uid:-::::1390257493::F7C00C8A2EAFD18CBEAA5AD703F7DAAF0A9FF40D::Toke H?iland- J?rgensen :::::::::1746601390:1: uid:-::::1254436708::5BB9504785E4BDFB1A528C5657D2548881DE3267::Toke H?iland- J?rgensen :::::::::1746601390:1: uid:-::::1254436103::F9CE85F6CBFD7011C8318DBF4E373959E9324987::Toke H?iland- J?rgensen :::::::::1746601390:1: uid:-::::1254225297::2639847E42B838E0E5114670190C51AFC09B1E7E::Toke H?iland- J?rgensen :::::::::1746601390:1: > file considers this ISO-8859 because one of the UIDs isn't proper UTF-8, > but "Toke H?iland-J?rgensen " encoded in latin1. Yes, apparently one UID was created with a non-compliant OpenPGP app. I'm wondering why they didn't revoke it since they added the same UID properly encoded just a few minutes later. > It's clear that this UID is invalid, but I'd claim that there is a bug > in the documentation (gpg(1) claims in the description for --with-colons > that the output is UTF-8) or in gpg itself (because it doesn't quote the > invalid chars). I don't think there's a bug. --with-colons assumes correctly UTF-8 encoded UIDs and therefore outputs the UIDs as-is. It's impossible to guess the encoding that was used if it's not UTF-8. More than 20 years ago I added some heuristics for correcting wrongly encoded UIDs to KMail and it worked somewhat for my sample of OpenPGP keys, but this sample was very latin-1-biased. > Fun fact: Without --with-colons the UID is emitted as: > > uid [ unknown] Toke H\xf8\x69land-J\xf8\x72gensen > > > which is UTF-8 and needlessly encodes the i and the r following the two > ? as hex escape. The output function probably assumes an unprintable 2-byte UTF-8 character and therefore escapes 2 bytes. > I wonder if cleaning the key should remove that UID? Why should it? The UID is neither expired nor revoked. That the UID is not UTF-8 encoded has no influence whatsoever on the validity UID. 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 Wed May 7 14:33:28 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2025 14:33:28 +0200 Subject: gpg --with-colon contains non-UTF-8 data In-Reply-To: <3624498.dWV9SEqChM@daneel> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22'?= =?utf-8?Q?s?= message of "Wed, 07 May 2025 09:26:00 +0200") References: <3didbomwcocpq7r7fxrvisw2p54j6z7k5pbitxpj5foufdap22@v3mgt2i4uc2v> <3624498.dWV9SEqChM@daneel> Message-ID: <877c2s4n3b.fsf@jacob.g10code.de> On Wed, 7 May 2025 09:26, Ingo Kl?cker said: > I guess Werner overlooked your request for an account. As did the other admins. Frankly, I noticed that Bernard replied and thus I did not even read it. I send you a confirmantion mail for your account. dev.gnupg.org is often under heavy DoS by AI bots or webspiders and thus please don't give up if you get a forbidden or other strange error messages. > Yes, apparently one UID was created with a non-compliant OpenPGP app. I'm PGP never cared about the encoding because umlauts are not a mtter in the US ;-) Thus many older keys are often Latin-1. We can try heuristics only at the display stage but not at any API. 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 May 7 14:47:52 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2025 14:47:52 +0200 Subject: S/MIME which certificate format In-Reply-To: <20250506171128.3d18c562@ryz.dorfdsl.de> (Marco Moock via Gnupg-users's message of "Tue, 6 May 2025 17:11:37 +0200") References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87wmau3w8u.fsf@jacob.g10code.de> <20250506171128.3d18c562@ryz.dorfdsl.de> Message-ID: <8734dg4mfb.fsf@jacob.g10code.de> On Tue, 6 May 2025 17:11, Marco Moock said: > libksba8:amd64 1.6.7-2+b1 > gnupg 2.4.7-17 I can only say that it works for me using slighly newer versions. I also doubt that your gpgsm's behaviour this is due to the many Debian patches. > If needed, I can try to build other versions, but this takes time as I > have to create Debian packets first. Most systems need gnupg and I > can't manually build and install it, as is breaks the dependency system. May I suggest to build gnupg 2.5.5 using the speedo system. This allows you to test it all independently of the system's software. Below are the instructions from the README. To avoid problems with systemd trying to start a different gpg-agent you should run your tests in a new shell: cd /some/test/dir GNUPGHOME='pwd' /usr/local/gnupg26/bin/gpg-agent --daemon bash Setting the homedir make sure that a different socket is used for IPC and thus leaves systemd out of the game. You may do this als with 2.4.7 but I am not 100% sure that the speedo works as well as ot does for 2.5.5. Shalom-Salam, Werner ======== ** Quick build method on Unix To quickly build all required software without installing it, the Speedo target may be used. But first you need to make sure that the toolchain is installed. On a Debian based system it should be sufficient to run as root: apt-get install build-essential libusb-1.0-0-dev libsqlite3-dev patchelf Then as regular user run make -f build-aux/speedo.mk native This target downloads all required libraries and does a native build of GnuPG to PLAY/inst/. 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. If you want to use the gnupg-w32-n.m.n_somedate.tar.xz tarball you only need to change the first make invocation to make -f build-aux/speedo.mk this-native The advantage of this alternative tarball is that all libraries are included and thus the Makefile does not need to download new tarballs. Note that in any case all downloaded files come with signatures which are verified by the Makefile commands. The patchelf command is required to change the search path for the shared libraries in the binaries to relative directories. -- 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 May 7 18:11:36 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2025 18:11:36 +0200 Subject: schnorr /secp256k1 In-Reply-To: (Louis Holbrook via Gnupg-users's message of "Wed, 16 Apr 2025 00:09:47 +0100") References: Message-ID: <87y0v82yfb.fsf@jacob.g10code.de> Hi! > Is it possible to use gnupg / libgcrypt to calculate the schnorr > signatures used by Nostr? I have not looked at the details. However, Libgcrypt exposes enough of its internal API to build other low-level crypto. For example GNUnet uses Libcrypt for their custom signature scheme. Sorry for the brief answer. If you have concrete questions rearding the use we will try to help you. 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 kevinotech at proton.me Wed May 7 18:23:36 2025 From: kevinotech at proton.me (kevinotech at proton.me) Date: Wed, 07 May 2025 16:23:36 +0000 Subject: Opengpg smartcard specs for kyber (PQC) algorithm Message-ID: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> Hello , i was trying to find if there was any work being done to support the kyber (PQC) aglorithm on the opengpg smartcard spec. The latest spec for opengpg smartcard is v 3.4.1 which doesn't have support for kyber algorithm. I think with the release of opengpg v2.6 , kyber algorithm would be in the stable releases stage. So i am wondering if this is planned for smart card too or already in the works. thanks kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: =?UTF-8?B?cHVibGlja2V5IC0ga2V2aW 5vdGVjaEBwcm90b24ubWUgLSAweEY5RjQzRTQ5LmFzYw==?= Type: application/pgp-keys Size: 843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 322 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Wed May 7 19:26:10 2025 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 7 May 2025 19:26:10 +0200 Subject: S/MIME which certificate format In-Reply-To: <8734dg4mfb.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87wmau3w8u.fsf@jacob.g10code.de> <20250506171128.3d18c562@ryz.dorfdsl.de> <8734dg4mfb.fsf@jacob.g10code.de> Message-ID: <20250507192610.79f83b25@ryz.dorfdsl.de> Am 07.05.2025 um 14:47:52 Uhr schrieb Werner Koch: > On Tue, 6 May 2025 17:11, Marco Moock said: > > > libksba8:amd64 1.6.7-2+b1 > > gnupg 2.4.7-17 > > I can only say that it works for me using slighly newer versions. I > also doubt that your gpgsm's behaviour this is due to the many Debian > patches. I now used Slackware and the tarballs from the website. I built and installed them using ./configure && make && make install I removed Slackware's packages first. root at localhost:~/libgcrypt-1.11.0# gpgsm --version gpgsm (GnuPG) 2.5.5 libgcrypt 1.11.0 libksba 1.6.7 Copyright (C) 2025 g10 Code GmbH 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 Unterst?tzte Verfahren: Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256 Pubkey: RSA, ECC, ECC Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL root at localhost:~/libgcrypt-1.11.0# gpgsm --show-cert /home/m/PKCS7.p7b gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert ksba: ber-decoder: node `?': TLV length too large File ........: /home/m/PKCS7.p7b ID: 0xFFFFFFFF S/N: keine (dec): keine Issuer: [error] Subject: [error] sha2_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF sha1_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF md5_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF certid: error keygrip: error notBefore: keine notAfter: keine hashAlgo: (null) keyType: [error] subjKeyId: [none] authKeyId: [none] keyUsage: [none] extKeyUsage: [none] policies: [none] chainLength: [none] crlDP: [none] authInfo: [none] subjInfo: [none] [GNUPG:] FAILURE gpgsm-exit 50331649 root at localhost:~/libgcrypt-1.11.0# If needed, please let me know which info you need. -- Gru? Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From albrecht.dress at posteo.de Wed May 7 19:45:56 2025 From: albrecht.dress at posteo.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Wed, 07 May 2025 17:45:56 +0000 Subject: gpgsm unable to extract signers from a valid (?) signature In-Reply-To: <87seli3v1z.fsf@jacob.g10code.de> Message-ID: Am 06.05.25 12:14 schrieb(en) Werner Koch: [snip] > This signature is a certificate-only message: > > $ ~/b/libksba/tests/t-cms-parser SIG.bin > *** checking `SIG.bin' *** > identified as: signed data > stop reason: 2 > ContentType: 1.2.840.113549.1.7.2 > stop reason: 3 > EncapsulatedContentType: 1.2.840.113549.1.7.1 > DigestAlgorithms: 2.16.840.1.101.3.4.2.1 > Detached signature > stop reason: 6 > this is a certs-only message > *** all checks done [snip] > Your signature is missing the part of the signature which is in the > proper signature from offset 17..47. Instead it starts off directly > with the list of certificates indicated by a context tag 0 at offset 15 > which starts in the proper signature at offset 35 Ok, thanks for the detailed explanation! > What we should do is to print a message that this is a cert-only > signature in the same way the LibKSBA test tool does it. Well, this doesn't solve the issue from the user's perspective IMHO. Apparently Thunderbird (and maybe other MUA's, too?) *is* able to deal with this signature, including a warning if the message has been tampered with, whilst any application using the gpgsm through gpgme or directly isn't which of course is a pity. I agree that this format seems to be rarely used (I actually saw it in messages from my electric supply company only, probably produced by some kind of crypto gateway; the headers don't give any further indication), but it would be great if gpgsm/libksba could deal with this kind of corner cases. Thanks, Albrecht. -------------- 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 accounts-gnupg at holbrook.no Wed May 7 21:42:54 2025 From: accounts-gnupg at holbrook.no (Louis Holbrook) Date: Wed, 7 May 2025 20:42:54 +0100 Subject: schnorr /secp256k1 In-Reply-To: <87y0v82yfb.fsf@jacob.g10code.de> Message-ID: Thanks. I will reach out if I end up doing some work on this. I would definitely need advice along the way. On Wed, May 07, 2025 at 06:11:36PM +0200, Werner Koch wrote: > Hi! > > > Is it possible to use gnupg / libgcrypt to calculate the schnorr > > signatures used by Nostr? > > I have not looked at the details. However, Libgcrypt exposes enough of > its internal API to build other low-level crypto. For example GNUnet > uses Libcrypt for their custom signature scheme. > > Sorry for the brief answer. If you have concrete questions rearding the > use we will try to help you. > > > 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: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From dan.git at lispclub.com Wed May 7 16:54:41 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Wed, 07 May 2025 15:54:41 +0100 Subject: Compiling error with pinentry Message-ID: <8734dglbda.fsf@lispclub.com> Hello. I am not subscribe to this mailing list, so please CC me if you are replying to the mailing list. Thanks! I am having trouble compiling pinentry. I always compile all the GnuPG suite, so I don't install any GnuPG program by my package manager (which is pacman). My operating system is Parabola. Can someone tell me if they can reproduce this compiling error issue below, and ways for me to solve this? Here is the compile error that I get: ``` $ ./autogen.sh autogen.sh: Running aclocal -I m4 ... autogen.sh: Running autoheader... autogen.sh: Running automake --gnu ... autogen.sh: Running autoconf ... configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:21: AM_ICONV_LINK is expanded from... m4/iconv.m4:246: AM_ICONV is expanded from... configure.ac:341: the top level configure.ac:341: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:21: AM_ICONV_LINK is expanded from... m4/iconv.m4:246: AM_ICONV is expanded from... configure.ac:341: the top level configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:9870: error: possibly undefined macro: AC_LIB_RPATH configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR autogen.sh: You may now run: ./configure --enable-maintainer-mode && make $ ./configure --enable-maintainer-mode checking for a BSD-compatible install... /usr/bin/install -c checking whether sleep supports fractional seconds... yes checking filesystem timestamp resolution... 0.01 checking whether build environment is sane... yes checking for a race-free mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking xargs -n works... yes checking whether make supports the include directive... yes (GNU style) checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking whether to enable maintainer-specific portions of Makefiles... yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking for gcc... (cached) gcc checking whether the compiler supports GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to enable C11 features... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for g++... g++ checking whether the compiler supports GNU C++... yes checking whether g++ accepts -g... yes checking for g++ option to enable C++11 features... none needed checking dependency style of g++... gcc3 checking whether ln -s works... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for windres... no checking for gitlog-to-changelog... no checking if gcc ignores unknown -Wno-* options... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wpointer-arith... yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for langinfo.h... yes checking for termio.h... yes checking for locale.h... yes checking for utime.h... yes checking for wchar.h... (cached) yes checking for seteuid... yes checking for stpcpy... yes checking for mmap... yes checking for stat... yes checking for mlock... yes checking for sysconf... yes checking for getpagesize... yes checking whether mlock is broken... no checking for uint32_t... yes checking for gpg-error-config... no checking for gpgrt-config... /usr/local/bin/gpgrt-config configure: Use gpgrt-config with /usr/local/lib as gpg-error-config checking for GPG Error - version >= 1.16... yes (1.51) configure: Use gpgrt-config as libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (3.0.0) checking LIBASSUAN API version... okay checking for byte... no checking for ulong... yes checking for u64... no checking for ncursesw... yes checking for ncurses include dir... none ./configure: line 9875: syntax error near unexpected token `iconv' ./configure: line 9875: ` AC_LIB_LINKFLAGS_BODY(iconv)' ``` -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From jcb62281 at gmail.com Thu May 8 06:40:08 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 7 May 2025 23:40:08 -0500 Subject: Compiling error with pinentry In-Reply-To: <8734dglbda.fsf@lispclub.com> References: <8734dglbda.fsf@lispclub.com> Message-ID: <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> On 5/7/25 09:54, Daniel Cerqueira wrote: > Hello. > > I am not subscribe to this mailing list, so please CC me if you are > replying to the mailing list. Thanks! > > I am having trouble compiling pinentry. I always compile all the GnuPG > suite, so I don't install any GnuPG program by my package manager (which > is pacman). > > My operating system is Parabola. > > Can someone tell me if they can reproduce this compiling error issue > below, and ways for me to solve this? > > Here is the compile error that I get: > > ``` > $ ./autogen.sh > autogen.sh: Running aclocal -I m4 ... > autogen.sh: Running autoheader... > autogen.sh: Running automake --gnu ... > autogen.sh: Running autoconf ... > configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd > m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > m4/iconv.m4:246: AM_ICONV is expanded from... > configure.ac:341: the top level > configure.ac:341: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > m4/iconv.m4:246: AM_ICONV is expanded from... > configure.ac:341: the top level > configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:9870: error: possibly undefined macro: AC_LIB_RPATH > configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY > configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR > [...] Check your Autoconf installation.? A quick Web search suggests that you may need to install the "gettext" package. -- Jacob From wk at gnupg.org Thu May 8 09:48:55 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 May 2025 09:48:55 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> (kevin via Gnupg-users's message of "Wed, 07 May 2025 16:23:36 +0000") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> Message-ID: <87plgj35lk.fsf@jacob.g10code.de> Hi! On Wed, 7 May 2025 16:23, kevin said: > support for kyber algorithm. I think with the release of opengpg v2.6 > , kyber algorithm would be in the stable releases stage. So i am > wondering if this is planned for smart card too or already in the I have seen a report that Infinion has a new chip with Kyber support. I guess it will be a long way until this will generally be available. However, such a smartcard also needs to implement another ECDH capable algorithm because we use (as per BSI requirement) two public key algorithms as a safeguard on case that Kyber truns out to have weaknesses. If you are interested in smartcard support I would suggest to use a smartcard with an ECC algorithm and an on-disk Kyber key. GnuPG 2.5.5 already supports this by allowing to specify the keys used for a new OpenPGP certificate using two keygrips: At the "Enter the Keygrip:" prompt give both keygrips delimuted by a command. For the Kyber part first create a dummy key (or use gpg-connect-agent to create the Kyber key part) and use its keygrip along with the keygrip of an on-card ECC key. Given the threat of store-now-decrypt-later the Kyber part of the encryption is sufficient to counter this attack. The ECC part on the smartcard the protects the classical attacks. How if someone gets hold of your disk and the passphrase it would be more useful for him to get the plaintext directly and not to wait for the Heffalump. Shalom-Salam, Werner p.s. Here is how you can create a plain kyber key which is stored in the private keys directory. Leave the --no-protection out if you want to protect the key with a passphrase. $ gpg-connect-agent > /let param (genkey(kyber1024)) > /definq KEYPARAM param > /datafile a.pub > genkey --no-protection S INQUIRE_MAXLEN 1024 INQUIRE KEYPARAM S KEYGRIP EF99623FD1F2F8AE91D305689C769245E5C53DCF OK The public key can be found as an s-expression in a.out. Do this without prompst this way: $ gpg-connect-agent "/let param (genkey(kyber1024))" \ "/definq KEYPARAM param" "/datafile a.pub" "genkey --no-protection" /bye -- 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 May 8 09:51:45 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 May 2025 09:51:45 +0200 Subject: S/MIME which certificate format In-Reply-To: <20250507192610.79f83b25@ryz.dorfdsl.de> (Marco Moock via Gnupg-users's message of "Wed, 7 May 2025 19:26:10 +0200") References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87wmau3w8u.fsf@jacob.g10code.de> <20250506171128.3d18c562@ryz.dorfdsl.de> <8734dg4mfb.fsf@jacob.g10code.de> <20250507192610.79f83b25@ryz.dorfdsl.de> Message-ID: <87ldr735gu.fsf@jacob.g10code.de> On Wed, 7 May 2025 19:26, Marco Moock said: > root at localhost:~/libgcrypt-1.11.0# gpgsm --show-cert /home/m/PKCS7.p7b > gpgsm: ksba_cert_hash failed: Kein Wert Please send me the PKCS7.p7b file again by private mail and gzip it first to avoid any problems. 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 May 8 09:55:56 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 May 2025 09:55:56 +0200 Subject: gpgsm unable to extract signers from a valid (?) signature In-Reply-To: ("Albrecht =?utf-8?Q?Dre=C3=9F=22's?= message of "Wed, 07 May 2025 17:45:56 +0000") References: Message-ID: <87h61v359v.fsf@jacob.g10code.de> On Wed, 7 May 2025 17:45, Albrecht Dre? said: > Apparently Thunderbird (and maybe other MUA's, too?) *is* able to deal > with this signature, including a warning if the message has been > tampered with, whilst any application using the gpgsm through gpgme or > directly isn't which of course is a pity. But there is no signature. It is a proper certs-only message which as far as I remeber is weel defined by CMS. gpgsm simply didn't showed the message because you gave a data file. I improved that diagnostic meanwhile. I would appreciate if someone else with CMS knowledge could look at that signature to check my findings. 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 dan.git at lispclub.com Thu May 8 10:30:00 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Thu, 08 May 2025 09:30:00 +0100 Subject: Compiling error with pinentry In-Reply-To: <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> (Jacob Bachmeyer's message of "Wed, 7 May 2025 23:40:08 -0500") References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> Message-ID: <87cycjqzcn.fsf@lispclub.com> Jacob Bachmeyer writes: > On 5/7/25 09:54, Daniel Cerqueira wrote: >> Hello. >> >> I am not subscribe to this mailing list, so please CC me if you are >> replying to the mailing list. Thanks! >> >> I am having trouble compiling pinentry. I always compile all the GnuPG >> suite, so I don't install any GnuPG program by my package manager (which >> is pacman). >> >> My operating system is Parabola. >> >> Can someone tell me if they can reproduce this compiling error issue >> below, and ways for me to solve this? >> >> Here is the compile error that I get: >> >> ``` >> $ ./autogen.sh >> autogen.sh: Running aclocal -I m4 ... >> autogen.sh: Running autoheader... >> autogen.sh: Running automake --gnu ... >> autogen.sh: Running autoconf ... >> configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd >> m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... >> m4/iconv.m4:21: AM_ICONV_LINK is expanded from... >> m4/iconv.m4:246: AM_ICONV is expanded from... >> configure.ac:341: the top level >> configure.ac:341: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd >> m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... >> m4/iconv.m4:21: AM_ICONV_LINK is expanded from... >> m4/iconv.m4:246: AM_ICONV is expanded from... >> configure.ac:341: the top level >> configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> configure:9870: error: possibly undefined macro: AC_LIB_RPATH >> configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY >> configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR >> [...] > > Check your Autoconf installation.? A quick Web search suggests that > you may need to install the "gettext" package. Hi Jacob. First, thank you for your reply. I already had gettext installed. I have also have now updated gettext, to the latest version (0.25), and I still get the same error message as above. Any thoughts on this? CONFIDENTIALITY WARNING The information transmitted in this message is for the exclusive use of the person or entity to which it is addressed and might contain privileged and or confidential information. If you are not the intended recipient of this message, you are prohibited from printing, duplicating, disseminating or otherwise using or acting in reliance upon this information. If you have received this message in error, please notify the sender immediately, delete this information from your computer and destroy all copies. GDPR SECURITY I use end-to-end encryption on my communications by emails. You should too! Ask me "How can I also end-to-end cipher my communications by email?", and I'll share how. -- The pioneers of a warless world are the youth that refuse military service. ~ Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From simon at josefsson.org Thu May 8 10:43:29 2025 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 May 2025 10:43:29 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87plgj35lk.fsf@jacob.g10code.de> (Werner Koch via Gnupg-users's message of "Thu, 08 May 2025 09:48:55 +0200") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87plgj35lk.fsf@jacob.g10code.de> Message-ID: <87ikmbijbi.fsf@josefsson.org> Werner Koch via Gnupg-users writes: > If you are interested in smartcard support I would suggest to use a > smartcard with an ECC algorithm and an on-disk Kyber key. GnuPG 2.5.5 > already supports this by allowing to specify the keys used for a new > OpenPGP certificate using two keygrips: At the "Enter the Keygrip:" > prompt give both keygrips delimuted by a command. For the Kyber part > first create a dummy key (or use gpg-connect-agent to create the Kyber > key part) and use its keygrip along with the keygrip of an on-card ECC > key. Oh! Is there a step-by-step instruction how to create a key like this? I've not been that interested in PQ PGP because I am so heavily reliant on my GNUK for everyday GnuPG usage. I also have doubts if Kyber is the only PQ alternative, and would want to migrate first when there are alternatives on the table, to have some mitigation plan ready on cryptographic weaknesses. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From kloecker at kde.org Thu May 8 21:07:05 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Thu, 08 May 2025 21:07:05 +0200 Subject: Compiling error with pinentry In-Reply-To: <87cycjqzcn.fsf@lispclub.com> References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> <87cycjqzcn.fsf@lispclub.com> Message-ID: <4956776.OV4Wx5bFTl@daneel> On Donnerstag, 8. Mai 2025 10:30:00 Mitteleurop?ische Sommerzeit Daniel Cerqueira wrote: > Jacob Bachmeyer writes: > > On 5/7/25 09:54, Daniel Cerqueira wrote: > >> I am having trouble compiling pinentry. I always compile all the GnuPG > >> suite, so I don't install any GnuPG program by my package manager (which > >> is pacman). [...] > >> Here is the compile error that I get: > >> > >> ``` > >> $ ./autogen.sh > >> autogen.sh: Running aclocal -I m4 ... > >> autogen.sh: Running autoheader... > >> autogen.sh: Running automake --gnu ... > >> autogen.sh: Running autoconf ... > >> configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not > >> m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > >> m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > >> m4/iconv.m4:246: AM_ICONV is expanded from... > >> configure.ac:341: the top level > > > > Check your Autoconf installation. A quick Web search suggests that > > you may need to install the "gettext" package. > > I already had gettext installed. I have also have now updated gettext, > to the latest version (0.25), and I still get the same error message as > above. On my system, AC_LIB_PREPARE_PREFIX is defined in /usr/share/aclocal/lib-prefix.m4 which is part of the gettext-tools package. By the way, you wouldn't run into this problem if you build pinentry (and the rest of GnuPG) from the official release tarballs. 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 albrecht.dress at posteo.de Thu May 8 21:10:16 2025 From: albrecht.dress at posteo.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Thu, 08 May 2025 19:10:16 +0000 Subject: gpgsm unable to extract signers from a valid (?) signature In-Reply-To: <87h61v359v.fsf@jacob.g10code.de> Message-ID: <7GGQV2MO.KGIAZCD5.CUEJLLKW@EKIG5KST.UJR7KP3Z.CDKIIMYW> Am 08.05.25 09:55 schrieb(en) Werner Koch: > > Apparently Thunderbird (and maybe other MUA's, too?) *is* able to deal > > with this signature, including a warning if the message has been > > tampered with, whilst any application using the gpgsm through gpgme or > > directly isn't which of course is a pity. > > But there is no signature. It is a proper certs-only message which as > far as I remeber is weel defined by CMS. gpgsm simply didn't showed the > message because you gave a data file. I improved that diagnostic > meanwhile. Well, all I can tell from the dumb user's perspective is that Thunderbird *does* actually report a valid signature (see attached combined screenshot): The dialogue for a message signed with my personal business certificate (left) looks similar to the ?strange? one (right). Gpgsm (through gpgme) is able to process the former, but not the latter. Thanks, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: thunderbird.png Type: image/png Size: 98921 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 dan.git at lispclub.com Thu May 8 22:06:05 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Thu, 08 May 2025 21:06:05 +0100 Subject: Compiling error with pinentry In-Reply-To: <4956776.OV4Wx5bFTl@daneel> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22'?= =?utf-8?Q?s?= message of "Thu, 08 May 2025 21:07:05 +0200") References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> <87cycjqzcn.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> Message-ID: <871psyrhoy.fsf@lispclub.com> Ingo Kl?cker writes: > On Donnerstag, 8. Mai 2025 10:30:00 Mitteleurop?ische Sommerzeit Daniel > Cerqueira wrote: >> Jacob Bachmeyer writes: >> > On 5/7/25 09:54, Daniel Cerqueira wrote: >> >> I am having trouble compiling pinentry. I always compile all the GnuPG >> >> suite, so I don't install any GnuPG program by my package manager (which >> >> is pacman). > [...] >> >> Here is the compile error that I get: >> >> >> >> ``` >> >> $ ./autogen.sh >> >> autogen.sh: Running aclocal -I m4 ... >> >> autogen.sh: Running autoheader... >> >> autogen.sh: Running automake --gnu ... >> >> autogen.sh: Running autoconf ... >> >> configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not >> >> m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... >> >> m4/iconv.m4:21: AM_ICONV_LINK is expanded from... >> >> m4/iconv.m4:246: AM_ICONV is expanded from... >> >> configure.ac:341: the top level >> > >> > Check your Autoconf installation. A quick Web search suggests that >> > you may need to install the "gettext" package. >> >> I already had gettext installed. I have also have now updated gettext, >> to the latest version (0.25), and I still get the same error message as >> above. > > On my system, AC_LIB_PREPARE_PREFIX is defined in > /usr/share/aclocal/lib-prefix.m4 which is part of the gettext-tools package. > > By the way, you wouldn't run into this problem if you build pinentry (and the > rest of GnuPG) from the official release tarballs. > > Regards, > Ingo Hi Ingo. My AC_LIB_PREPARE_PREFIX is at /usr/share/gettext/m4/lib-prefix.m4 , which comes with the gettext package. Which was already installed. I still get the same error, when compiling pinentry from the official tarball: ``` $ wget https://www.gnupg.org/ftp/gcrypt/pinentry/pinentry-1.3.1.tar.bz2 (...) $ tar xf pinentry-1.3.1.tar.bz2 $ cd pinentry-1.3.1/ $ ./autogen.sh autogen.sh: Running aclocal -I m4 ... autogen.sh: Running autoheader... autogen.sh: Running automake --gnu ... autogen.sh: Running autoconf ... configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:21: AM_ICONV_LINK is expanded from... m4/iconv.m4:246: AM_ICONV is expanded from... configure.ac:341: the top level configure.ac:341: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:21: AM_ICONV_LINK is expanded from... m4/iconv.m4:246: AM_ICONV is expanded from... configure.ac:341: the top level configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:9870: error: possibly undefined macro: AC_LIB_RPATH configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR autogen.sh: You may now run: ./configure --enable-maintainer-mode && make $ ./configure --enable-maintainer-mode checking for a BSD-compatible install... /usr/bin/install -c checking whether sleep supports fractional seconds... yes checking filesystem timestamp resolution... 0.01 checking whether build environment is sane... yes checking for a race-free mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking xargs -n works... yes checking whether make supports the include directive... yes (GNU style) checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking whether to enable maintainer-specific portions of Makefiles... yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking for gcc... (cached) gcc checking whether the compiler supports GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to enable C11 features... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for g++... g++ checking whether the compiler supports GNU C++... yes checking whether g++ accepts -g... yes checking for g++ option to enable C++11 features... none needed checking dependency style of g++... gcc3 checking whether ln -s works... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for windres... no checking for gitlog-to-changelog... no checking if gcc ignores unknown -Wno-* options... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wpointer-arith... yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for langinfo.h... yes checking for termio.h... yes checking for locale.h... yes checking for utime.h... yes checking for wchar.h... (cached) yes checking for seteuid... yes checking for stpcpy... yes checking for mmap... yes checking for stat... yes checking for mlock... yes checking for sysconf... yes checking for getpagesize... yes checking whether mlock is broken... no checking for uint32_t... yes checking for gpg-error-config... no checking for gpgrt-config... /usr/local/bin/gpgrt-config configure: Use gpgrt-config with /usr/local/lib as gpg-error-config checking for GPG Error - version >= 1.16... yes (1.51) configure: Use gpgrt-config as libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (3.0.0) checking LIBASSUAN API version... okay checking for byte... no checking for ulong... yes checking for u64... no checking for ncursesw... yes checking for ncurses include dir... none ./configure: line 9875: syntax error near unexpected token `iconv' ./configure: line 9875: ` AC_LIB_LINKFLAGS_BODY(iconv)' ``` Ingo, can you try to see if you also get this error, and tell me your result? Can someone tell me if is just my system that gets this error? CONFIDENTIALITY WARNING The information transmitted in this message is for the exclusive use of the person or entity to which it is addressed and might contain privileged and or confidential information. If you are not the intended recipient of this message, you are prohibited from printing, duplicating, disseminating or otherwise using or acting in reliance upon this information. If you have received this message in error, please notify the sender immediately, delete this information from your computer and destroy all copies. GDPR SECURITY I use end-to-end encryption on my communications by emails. You should too! Ask me "How can I also end-to-end cipher my communications by email?", and I'll share how. -- The pioneers of a warless world are the youth that refuse military service. ~ Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From wk at gnupg.org Fri May 9 14:28:09 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 May 2025 14:28:09 +0200 Subject: [Announce] GnuPG 2.5.6 and Gpg4win-5-Beta190 released Message-ID: <87ecwy7yue.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.6. This release is another one in a series of public testing releases eventually leading to a new stable version 2.6. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of Kyber (FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. 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.5.6 (2025-05-08) ================================================ [compared to version 2.5.5] * gpg: Add a flag to the filter expressions for left anchored substring match. [rGc12b7d047e] * gpg: New list option "show-trustsig" to avoid resorting to colon mode for this info. [rG41d6ae8f41] * gpg: New command --quick-tsign-key to create a trust signature. [rGd90b290f97] * gpg: New keygen parameter "User-Id". [rGcfd597c603] * gpg: New list options "show-trustsig". [rGrG41d6ae8f41] * gpg: Fix double free of internal data in no-sig-cache mode [T7547] * gpg: Signatures from revoked or expired keys do not anymore show up as missing keys. Fixes regression in 2.5.5. [T7583] * gpgsm: Extend --learn-card by an optional s/n argument. [T7379] * gpgsm: Skip expired certificates when selection a certificate by subject. [rG4cf83273e8] * card: New command "ll" as alias for "list --cards". [rGd6ee7adebe] * scd: Fix posssible lockup on Windows due to a lost select result. [rGa7ec3792c5] * scd:p15: Accept P15 cards with a zero-length label. [rGdb25aa9887] * keyboxd: Use case-insensitive search for mail addresses. [T7576] * dirmngr: Fix a problem in libdns related to an address change from 127.0.0.1. [T4021] * gpgconf: Fix reload and kill of keyboxd. [T7569] * Fix logic for certain recsel conditions. [rG8968e84903] * Add Solaris support to get_signal_name. [T7638] * Fix build error of the test shell on AIX. [T7632] Release-info: https://dev.gnupg.org/T7586 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 file 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.5.6.tar.bz2 (7997k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.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.5.6_20250508.exe (5503k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.6_20250508.exe.sig The source used to build this installer for 64-bit Windows is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.6_20250508.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.6_20250508.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Windows Installer ================= A *Beta* version of Gpg4win, our full featured Windows installer including this version of GnuPG as well as the Kleopatra GUI and a PDF editor can be retrieved from here: https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.exe (41M) https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.exe.sig with the source code at: https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.tar.xz (276M) https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.tar.xz.sig 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.5.6.tar.bz2 you would use this command: gpg --verify gnupg-2.5.6.tar.bz2.sig gnupg-2.5.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.5.6.tar.bz2, you run the command like this: sha1sum gnupg-2.5.6.tar.bz2 and check that the output matches the next line: ca4502c7153ff18670668fbe687d96dc633f23bf gnupg-2.5.6.tar.bz2 5c229b07433513f14585d1b257575b33410e3c4c gnupg-w32-2.5.6_20250508.tar.xz d5ba24e7f1996dc14e49d4573d73af6a4ca2f455 gnupg-w32-2.5.6_20250508.exe ad579452ec9a2faedf025a37b0b0589ec4dadd1d gpg4win-5.0.0-beta190.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/T7586 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. A team of 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: 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 kloecker at kde.org Fri May 9 16:16:48 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Fri, 09 May 2025 16:16:48 +0200 Subject: Compiling error with pinentry In-Reply-To: <871psyrhoy.fsf@lispclub.com> References: <8734dglbda.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> <871psyrhoy.fsf@lispclub.com> Message-ID: <26882987.1r3eYUQgxm@daneel> On Donnerstag, 8. Mai 2025 22:06:05 Mitteleurop?ische Sommerzeit Daniel Cerqueira wrote: > Ingo Kl?cker writes: > > On Donnerstag, 8. Mai 2025 10:30:00 Mitteleurop?ische Sommerzeit Daniel > > > > Cerqueira wrote: > >> Jacob Bachmeyer writes: > >> > On 5/7/25 09:54, Daniel Cerqueira wrote: > >> >> I am having trouble compiling pinentry. I always compile all the > >> >> GnuPG > >> >> suite, so I don't install any GnuPG program by my package manager > >> >> (which > >> >> is pacman). > > > > [...] > > > >> >> Here is the compile error that I get: > >> >> > >> >> ``` > >> >> $ ./autogen.sh > >> >> autogen.sh: Running aclocal -I m4 ... > >> >> autogen.sh: Running autoheader... > >> >> autogen.sh: Running automake --gnu ... > >> >> autogen.sh: Running autoconf ... > >> >> configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > >> >> not > >> >> m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > >> >> m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > >> >> m4/iconv.m4:246: AM_ICONV is expanded from... > >> >> configure.ac:341: the top level > >> > > >> > Check your Autoconf installation. A quick Web search suggests that > >> > you may need to install the "gettext" package. > >> > >> I already had gettext installed. I have also have now updated gettext, > >> to the latest version (0.25), and I still get the same error message as > >> above. > > > > On my system, AC_LIB_PREPARE_PREFIX is defined in > > /usr/share/aclocal/lib-prefix.m4 which is part of the gettext-tools > > package. > > > > By the way, you wouldn't run into this problem if you build pinentry (and > > the rest of GnuPG) from the official release tarballs. > > My AC_LIB_PREPARE_PREFIX is at /usr/share/gettext/m4/lib-prefix.m4 , > which comes with the gettext package. Which was already installed. > > I still get the same error, when compiling pinentry from the official > tarball: No idea. Looks like your distribution is broken. Maybe it installs the m4 files in the wrong location. Or it does not properly tell the autotools where to look for m4 files. > ``` > $ wget https://www.gnupg.org/ftp/gcrypt/pinentry/pinentry-1.3.1.tar.bz2 > (...) > > $ tar xf pinentry-1.3.1.tar.bz2 > > $ cd pinentry-1.3.1/ > > $ ./autogen.sh Here's the problem. Don't run ./autogen.sh unless you compile straight from a checkout of the git repository. The release tarballs come with a pre-built ready-to-use configure script. > $ ./configure --enable-maintainer-mode Just run ./configure. The --enable-maintainer-mode option is not useful for people building the tarballs. > ``` > > Ingo, can you try to see if you also get this error, and tell me your > result? I don't get this error. And I build pinentry frequently. 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 fg.gnupg at shimps.de Fri May 9 19:00:50 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Fri, 9 May 2025 19:00:50 +0200 Subject: Compiling error with pinentry In-Reply-To: <871psyrhoy.fsf@lispclub.com> References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> <87cycjqzcn.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> <871psyrhoy.fsf@lispclub.com> Message-ID: <20250509190050.7d30c217@incubator.example.net> Hello Daniel. I don't know much about Parabola but can provide some hints from the Debian world, which lead to an educated guess. On Thu, 08 May 2025 21:06:05 +0100 Daniel Cerqueira wrote: > > My AC_LIB_PREPARE_PREFIX is at /usr/share/gettext/m4/lib-prefix.m4 , > which comes with the gettext package. Which was already installed. $ apt-file find lib-prefix.m4 gettext: /usr/share/aclocal/lib-prefix.m4 > I still get the same error, when compiling pinentry from the official > tarball: > [...] > $ ./autogen.sh > autogen.sh: Running aclocal -I m4 ... > autogen.sh: Running autoheader... > autogen.sh: Running automake --gnu ... > autogen.sh: Running autoconf ... > configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd Without gettext installed, I can reproduce this warning. > configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX > If this token and others are legitimate, please use > m4_pattern_allow. See the Autoconf documentation. > configure:9870: error: possibly undefined macro: AC_LIB_RPATH > configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY > configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR I cannot reproduce these errors. > $ ./configure --enable-maintainer-mode > [...] > ./configure: line 9875: syntax error near unexpected token `iconv' > ./configure: line 9875: ` AC_LIB_LINKFLAGS_BODY(iconv)' Without gettext installed, I can reproduce this error (with a different line number). When I install gettext and run autogen.sh again, the warning doesn't show up again and the obtained configure script doesn't throw any errors anymore. > Can someone tell me if is just my system that gets this error? My guess is: despite having gettext installed, the autogen.sh script doesn't know the location where the required data is installed on your system. This leads to effects similar as if gettext wasn't installed at all. The next step would be to figure out the reason why the gettext data seems to be unknown, which might require some better knowledge of Parabola than I can provide. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From dan.git at lispclub.com Fri May 9 16:38:12 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Fri, 09 May 2025 15:38:12 +0100 Subject: Compiling error with pinentry In-Reply-To: <8734dglbda.fsf@lispclub.com> (Daniel Cerqueira's message of "Wed, 07 May 2025 15:54:41 +0100") References: <8734dglbda.fsf@lispclub.com> Message-ID: <87cychq27f.fsf@lispclub.com> Daniel Cerqueira writes: > Hello. > > I am not subscribe to this mailing list, so please CC me if you are > replying to the mailing list. Thanks! > > I am having trouble compiling pinentry. I always compile all the GnuPG > suite, so I don't install any GnuPG program by my package manager (which > is pacman). > > My operating system is Parabola. > > Can someone tell me if they can reproduce this compiling error issue > below, and ways for me to solve this? > > Here is the compile error that I get: > > ``` > $ ./autogen.sh > autogen.sh: Running aclocal -I m4 ... > autogen.sh: Running autoheader... > autogen.sh: Running automake --gnu ... > autogen.sh: Running autoconf ... > configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd > m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > m4/iconv.m4:246: AM_ICONV is expanded from... > configure.ac:341: the top level > configure.ac:341: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > m4/iconv.m4:246: AM_ICONV is expanded from... > configure.ac:341: the top level > configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:9870: error: possibly undefined macro: AC_LIB_RPATH > configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY > configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR > autogen.sh: You may now run: > ./configure --enable-maintainer-mode && make > > $ ./configure --enable-maintainer-mode > checking for a BSD-compatible install... /usr/bin/install -c > checking whether sleep supports fractional seconds... yes > checking filesystem timestamp resolution... 0.01 > checking whether build environment is sane... yes > checking for a race-free mkdir -p... /usr/bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking xargs -n works... yes > checking whether make supports the include directive... yes (GNU style) > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether the compiler supports GNU C... yes > checking whether gcc accepts -g... yes > checking for gcc option to enable C11 features... none needed > checking whether gcc understands -c and -o together... yes > checking dependency style of gcc... gcc3 > checking for stdio.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for strings.h... yes > checking for sys/stat.h... yes > checking for sys/types.h... yes > checking for unistd.h... yes > checking for wchar.h... yes > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking whether _XOPEN_SOURCE should be defined... no > checking whether to enable maintainer-specific portions of Makefiles... yes > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking whether make sets $(MAKE)... (cached) yes > checking whether build environment is sane... yes > checking for gcc... (cached) gcc > checking whether the compiler supports GNU C... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to enable C11 features... (cached) none needed > checking whether gcc understands -c and -o together... (cached) yes > checking dependency style of gcc... (cached) gcc3 > checking how to run the C preprocessor... gcc -E > checking for ranlib... ranlib > checking for g++... g++ > checking whether the compiler supports GNU C++... yes > checking whether g++ accepts -g... yes > checking for g++ option to enable C++11 features... none needed > checking dependency style of g++... gcc3 > checking whether ln -s works... yes > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for windres... no > checking for gitlog-to-changelog... no > checking if gcc ignores unknown -Wno-* options... yes > checking if gcc supports -Wdeclaration-after-statement... yes > checking if gcc supports -Wpointer-arith... yes > checking for string.h... (cached) yes > checking for unistd.h... (cached) yes > checking for langinfo.h... yes > checking for termio.h... yes > checking for locale.h... yes > checking for utime.h... yes > checking for wchar.h... (cached) yes > checking for seteuid... yes > checking for stpcpy... yes > checking for mmap... yes > checking for stat... yes > checking for mlock... yes > checking for sysconf... yes > checking for getpagesize... yes > checking whether mlock is broken... no > checking for uint32_t... yes > checking for gpg-error-config... no > checking for gpgrt-config... /usr/local/bin/gpgrt-config > configure: Use gpgrt-config with /usr/local/lib as gpg-error-config > checking for GPG Error - version >= 1.16... yes (1.51) > configure: Use gpgrt-config as libassuan-config > checking for LIBASSUAN - version >= 2.1.0... yes (3.0.0) > checking LIBASSUAN API version... okay > checking for byte... no > checking for ulong... yes > checking for u64... no > checking for ncursesw... yes > checking for ncurses include dir... none > ./configure: line 9875: syntax error near unexpected token `iconv' > ./configure: line 9875: ` AC_LIB_LINKFLAGS_BODY(iconv)' > ``` > I still haven't been able to compile pinentry. Here is the lines (in ./configure) that are causing the error: ``` $ nl configure | grep -B 10 -A 10 "AC_LIB_LINKFLAGS_BODY(iconv)" 8922 if test "$pinentry_curses" = "yes" \ 8923 -o "$fallback_curses" = "yes" ; then 8924 AC_LIB_PREPARE_PREFIX 8925 AC_LIB_RPATH * 8926 AC_LIB_LINKFLAGS_BODY(iconv) 8927 am_save_CPPFLAGS="$CPPFLAGS" 8928 AC_LIB_APPENDTOVAR(CPPFLAGS, $INCICONV) 8929 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for iconv" >&5 $ nl configure | grep -B 10 -A 10 9875 9869 have_x11=yes 9870 fi 9871 if test "$have_x11" = "yes"; then 9872 printf "%s\n" "#define HAVE_X11 1" >>confdefs.h 9873 fi 9874 fi * 9875 have_kf5waylandclient=no 9876 if test "$have_w32_system" != "yes"; then 9877 pkg_failed=no 9878 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for KF5WaylandClient >= 5.60" >&5 9879 printf %s "checking for KF5WaylandClient >= 5.60... " >&6; } 9880 if test -n "$PKG_CONFIG"; then 9881 if test -n "$KF5WAYLANDCLIENT_CFLAGS"; then 9882 pkg_cv_KF5WAYLANDCLIENT_CFLAGS="$KF5WAYLANDCLIENT_CFLAGS" 9883 else ``` -- The pioneers of a warless world are the youth that refuse military service. ~ Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From dan.git at lispclub.com Sat May 10 10:28:27 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Sat, 10 May 2025 09:28:27 +0100 Subject: Compiling error with pinentry In-Reply-To: <20250509190050.7d30c217@incubator.example.net> (Frank Guthausen's message of "Fri, 9 May 2025 19:00:50 +0200") References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> <87cycjqzcn.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> <871psyrhoy.fsf@lispclub.com> <20250509190050.7d30c217@incubator.example.net> Message-ID: <87wmaoc1jo.fsf@lispclub.com> Frank Guthausen writes: > Hello Daniel. > > I don't know much about Parabola but can provide some > hints from the Debian world, which lead to an educated > guess. > > On Thu, 08 May 2025 21:06:05 +0100 > Daniel Cerqueira wrote: >> >> My AC_LIB_PREPARE_PREFIX is at /usr/share/gettext/m4/lib-prefix.m4 , >> which comes with the gettext package. Which was already installed. > > $ apt-file find lib-prefix.m4 > gettext: /usr/share/aclocal/lib-prefix.m4 > >> I still get the same error, when compiling pinentry from the official >> tarball: >> [...] >> $ ./autogen.sh >> autogen.sh: Running aclocal -I m4 ... >> autogen.sh: Running autoheader... >> autogen.sh: Running automake --gnu ... >> autogen.sh: Running autoconf ... >> configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but >> not m4_defun'd > > Without gettext installed, I can reproduce this warning. > >> configure:9869: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX >> If this token and others are legitimate, please use >> m4_pattern_allow. See the Autoconf documentation. >> configure:9870: error: possibly undefined macro: AC_LIB_RPATH >> configure:9875: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY >> configure:9883: error: possibly undefined macro: AC_LIB_APPENDTOVAR > > I cannot reproduce these errors. > >> $ ./configure --enable-maintainer-mode >> [...] >> ./configure: line 9875: syntax error near unexpected token `iconv' >> ./configure: line 9875: ` AC_LIB_LINKFLAGS_BODY(iconv)' > > Without gettext installed, I can reproduce this error (with a different > line number). > > When I install gettext and run autogen.sh again, the warning doesn't > show up again and the obtained configure script doesn't throw any > errors anymore. > >> Can someone tell me if is just my system that gets this error? > > My guess is: despite having gettext installed, the autogen.sh > script doesn't know the location where the required data is > installed on your system. This leads to effects similar as if > gettext wasn't installed at all. > > The next step would be to figure out the reason why the gettext data > seems to be unknown, which might require some better knowledge of > Parabola than I can provide. Hi Frank. Thank you for your comprehensive reply. Means a lot to me :-) . I will be talking to the Parabola community about this. I know that my computer's privacy has been abused, by some Internet crackers. Unfortunately, a reality I have to deal with. CONFIDENTIALITY WARNING The information transmitted in this message is for the exclusive use of the person or entity to which it is addressed and might contain privileged and or confidential information. If you are not the intended recipient of this message, you are prohibited from printing, duplicating, disseminating or otherwise using or acting in reliance upon this information. If you have received this message in error, please notify the sender immediately, delete this information from your computer and destroy all copies. GDPR SECURITY I use end-to-end encryption on my communications by emails. You should too! Ask me "How can I also end-to-end cipher my communications by email?", and I'll share how. -- The pioneers of a warless world are the youth that refuse military service. ~ Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From dan.git at lispclub.com Sat May 10 10:35:17 2025 From: dan.git at lispclub.com (Daniel Cerqueira) Date: Sat, 10 May 2025 09:35:17 +0100 Subject: Compiling error with pinentry In-Reply-To: <26882987.1r3eYUQgxm@daneel> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22?= =?utf-8?Q?'s?= message of "Fri, 09 May 2025 16:16:48 +0200") References: <8734dglbda.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> <871psyrhoy.fsf@lispclub.com> <26882987.1r3eYUQgxm@daneel> Message-ID: <87selcc18a.fsf@lispclub.com> Ingo Kl?cker writes: > On Donnerstag, 8. Mai 2025 22:06:05 Mitteleurop?ische Sommerzeit Daniel > Cerqueira wrote: >> Ingo Kl?cker writes: >> > On Donnerstag, 8. Mai 2025 10:30:00 Mitteleurop?ische Sommerzeit Daniel >> > >> > Cerqueira wrote: >> >> Jacob Bachmeyer writes: >> >> > On 5/7/25 09:54, Daniel Cerqueira wrote: >> >> >> I am having trouble compiling pinentry. I always compile all the >> >> >> GnuPG >> >> >> suite, so I don't install any GnuPG program by my package manager >> >> >> (which >> >> >> is pacman). >> > >> > [...] >> > [...] >> >> > >> >> > Check your Autoconf installation. A quick Web search suggests that >> >> > you may need to install the "gettext" package. >> >> >> >> I already had gettext installed. I have also have now updated gettext, >> >> to the latest version (0.25), and I still get the same error message as >> >> above. [...] > > No idea. Looks like your distribution is broken. Maybe it installs the m4 files > in the wrong location. Or it does not properly tell the autotools where to > look for m4 files. > Indeed. It is broken. [...] > Just run ./configure. The --enable-maintainer-mode option is not useful for > people building the tarballs. > >> ``` >> >> Ingo, can you try to see if you also get this error, and tell me your >> result? > > I don't get this error. And I build pinentry frequently. Thank you Ingo. I compiled successfully using the tarballs and following your instructions. CONFIDENTIALITY WARNING The information transmitted in this message is for the exclusive use of the person or entity to which it is addressed and might contain privileged and or confidential information. If you are not the intended recipient of this message, you are prohibited from printing, duplicating, disseminating or otherwise using or acting in reliance upon this information. If you have received this message in error, please notify the sender immediately, delete this information from your computer and destroy all copies. GDPR SECURITY I use end-to-end encryption on my communications by emails. You should too! Ask me "How can I also end-to-end cipher my communications by email?", and I'll share how. -- The pioneers of a warless world are the youth that refuse military service. ~ Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From atod101101 at gmail.com Sun May 11 18:08:46 2025 From: atod101101 at gmail.com (Nick) Date: Sun, 11 May 2025 12:08:46 -0400 Subject: gpgsm: can't sign using 'email@gmail.com': No public key Message-ID: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> I can?t sign using my public key which --list-keys shows. Does anyone have a solution or pointers on how to debug this further? Is it because --list-keys shows 0 for signed keys? $ echo "signme" |gpgsm -s -u email at gmail.com gpgsm: can't sign using 'email at gmail.com ': No public key $ gpg2 --list-keys gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2028-03-15 [keyboxd] --------- pub ed25519 2025-05-11 [SC] [expires: 2031-05-10] XD uid [ultimate] X > sub cv25519 2025-05-11 [E] [expires: 2031-05-10] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbs at brandes.xyz Sun May 11 18:17:20 2025 From: dbs at brandes.xyz (Daniel Brandes) Date: Sun, 11 May 2025 18:17:20 +0200 Subject: gpgsm: can't sign using 'email@gmail.com': No public key In-Reply-To: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> References: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> Message-ID: <9ACEF9BC-8835-4D04-A857-DA5832C0B3D8@brandes.xyz> An HTML attachment was scrubbed... URL: From atod101101 at gmail.com Sun May 11 16:39:46 2025 From: atod101101 at gmail.com (Nick) Date: Sun, 11 May 2025 10:39:46 -0400 Subject: gpgsm: can't sign using 'email@gmail.com': No public key Message-ID: I can?t sign using my public key which --list-keys shows. Does anyone have a solution or pointers on how to debug this further? Is it because --list-keys shows 0 for signed keys? $ echo "signme" |gpgsm -s -u email at gmail.comgpgsm: can't sign using 'email at gmail.com': No public key $ gpg2 --list-keysgpg: checking the trustdbgpg: marginals needed: 3 completes needed: 1 trust model: pgpgpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2ugpg: next trustdb check due at 2028-03-15 [keyboxd]---------pub ed25519 2025-05-11 [SC] [expires: 2031-05-10] XDuid [ultimate] X sub cv25519 2025-05-11 [E] [expires: 2031-05-10] -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon May 12 10:56:00 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2025 10:56:00 +0200 Subject: Compiling error with pinentry In-Reply-To: <20250509190050.7d30c217@incubator.example.net> (Frank Guthausen's message of "Fri, 9 May 2025 19:00:50 +0200") References: <8734dglbda.fsf@lispclub.com> <0ce6e48a-4bb2-408b-a730-bff44a5b1c2f@gmail.com> <87cycjqzcn.fsf@lispclub.com> <4956776.OV4Wx5bFTl@daneel> <871psyrhoy.fsf@lispclub.com> <20250509190050.7d30c217@incubator.example.net> Message-ID: <874ixq8axr.fsf@jacob.g10code.de> On Fri, 9 May 2025 19:00, Frank Guthausen said: > My guess is: despite having gettext installed, the autogen.sh > script doesn't know the location where the required data is autogen.sh is a maintainer-only script and it should not be used by standard users who want to build gnupg. We prepare tarballs for a reason. If you want to build from Git you should report problems to gnupg-devel - after you have done your hacker due diligence ;-) 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 Mon May 12 15:27:00 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2025 15:27:00 +0200 Subject: gpgsm: can't sign using 'email@gmail.com': No public key In-Reply-To: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> (Nick via Gnupg-users's message of "Sun, 11 May 2025 12:08:46 -0400") References: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> Message-ID: <87o6vy6jtn.fsf@jacob.g10code.de> On Sun, 11 May 2025 12:08, Nick said: > Is it because --list-keys shows 0 for signed keys? You are using "gpg --list-keys" (aka "gpg -k") this lists OpenPGP keys and not S/MIME (i.e. X.509) keys. For that you need to run "gpgsm --list-keys" (or "gpgsm -k"). However, if you want to use a key for signing you need the private (secret) key and thus it is better to use gpgsm --list-secret-keys or shorter gpgsm -K (note the capital 'K'). This lists only keys/certificates for which you have the private (secret) key. > gpgsm: can't sign using 'email at gmail.com ': No > public key The error message might be confusing, as it should show "no secret key" but in your case it seems that you don't vene have the public key for "email at gmail.com". BTW, having mailto: as part of the mail address in angle brackets is not the best idea: For gpg any many other tools this looks like the real mail address is "mailto:email at gmail.com" and not "email at gmail.com". 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 atod101101 at gmail.com Mon May 12 18:47:38 2025 From: atod101101 at gmail.com (Nick) Date: Mon, 12 May 2025 12:47:38 -0400 Subject: gpgsm: can't sign using 'email@gmail.com': No public key In-Reply-To: <87o6vy6jtn.fsf@jacob.g10code.de> References: <729DDE7E-FDD1-45F7-8280-082964DB9A37@gmail.com> <87o6vy6jtn.fsf@jacob.g10code.de> Message-ID: <1704F1CD-4C99-4D35-BFA2-B8A11AB3EC16@gmail.com> > On May 12, 2025, at 9:27 AM, Werner Koch wrote: > > On Sun, 11 May 2025 12:08, Nick said: > >> Is it because --list-keys shows 0 for signed keys? >> gpgsm: can't sign using 'email at gmail.com ': No >> public key > > The error message might be confusing, as it should show "no secret key" > but in your case it seems that you don't vene have the public key for > "email at gmail.com". > > BTW, having mailto: as part of the mail address in angle brackets is not > the best idea: For gpg any many other tools this looks like the real > mail address is "mailto:email at gmail.com" and not "email at gmail.com?. mailto: per your description was part of the problem from what I recall. From atod101101 at gmail.com Tue May 13 09:01:14 2025 From: atod101101 at gmail.com (Atod Bora) Date: Tue, 13 May 2025 03:01:14 -0400 Subject: Should you include your email address on key server? Message-ID: What are the best practices and/or pros/cons of including your email address on the key server? For instance now, I have not included my email address, yet it is in the signature. I was reluctant to include it because of spam harvesting, however I have read it may not be an issue. Thanks -- (atod101101 at gmail.com) (htp://keys.openpgp.org "114F 10E4 10E0 2C96 1C9E 1B4A F743 7A0F 4292 EA2D") From wk at gnupg.org Tue May 13 10:10:35 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 May 2025 10:10:35 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87ikmbijbi.fsf@josefsson.org> (Simon Josefsson via Gnupg-users's message of "Thu, 08 May 2025 10:43:29 +0200") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87plgj35lk.fsf@jacob.g10code.de> <87ikmbijbi.fsf@josefsson.org> Message-ID: <8734d96idg.fsf@jacob.g10code.de> Hi! On Thu, 8 May 2025 10:43, Simon Josefsson said: > Oh! Is there a step-by-step instruction how to create a key like > this? Not yet. However some folks obviously experimented with this and found that smartcard support does not yet work. Damien reported this as https://dev.gnupg.org/T7648 and Gniibe fixed that in the repo. Actually there was even a comment in the code which indicates this. > on my GNUK for everyday GnuPG usage. I also have doubts if Kyber is the > only PQ alternative, and would want to migrate first when there are > alternatives on the table, to have some mitigation plan ready on > cryptographic weaknesses. Given the threat model of store-now-decrypt-after-first-contact-day any alternative PQC algorithm will not be very helpful. Unless we use ECC+Kyber+OtherPQC and risk that the key combiner gets broken. 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 fa-ml at ariis.it Tue May 13 10:09:13 2025 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 13 May 2025 10:09:13 +0200 Subject: Should you include your email address on key server? In-Reply-To: References: Message-ID: Hello Atod, Il 13 maggio 2025 alle 03:01 Atod Bora via Gnupg-users ha scritto: > What are the best practices and/or pros/cons of including your email > address on the key server? For instance now, I have not included my > email address, yet it is in the signature. > > I was reluctant to include it because of spam harvesting, however I have > read it may not be an issue. My experience: I have a personal email address I use only for private communications. I do not use it to subscribe to sites or anything similar. I added it to a keyserver in 2012; I have yet to receive a single spam email. Maybe email harvesting is not profitable anymore ?F From look at my.amazin.horse Tue May 13 11:23:33 2025 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 13 May 2025 11:23:33 +0200 Subject: Should you include your email address on key server? In-Reply-To: References: Message-ID: Hey Atod, this depends on the keyserver. For keys.openpgp.org I can say that, in accordance to our [privacy policy], email addresses can not be listed and are never handed collectively ("as a dump") to third parties, and are thus safe from harvesting. Cheers [privacy policy]: https://keys.openpgp.org/about/privacy - V On 13.05.25 09:01, Atod Bora via Gnupg-users wrote: > What are the best practices and/or pros/cons of including your email > address on the key server? For instance now, I have not included my > email address, yet it is in the signature. > > I was reluctant to include it because of spam harvesting, however I have > read it may not be an issue. > > Thanks > From wk at gnupg.org Tue May 13 14:13:40 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 May 2025 14:13:40 +0200 Subject: Should you include your email address on key server? In-Reply-To: (Atod Bora via Gnupg-users's message of "Tue, 13 May 2025 03:01:14 -0400") References: Message-ID: <87wmak674b.fsf@jacob.g10code.de> On Tue, 13 May 2025 03:01, Atod Bora said: > What are the best practices and/or pros/cons of including your email > address on the key server? For instance now, I have not included my Use only the mail address if you are using the this for mail. If you like add your name but that is optional and not needed. The key belongs to your mail address and thus you need to add the mail address. Do no use public keyservers. They are not useful because of DoS and the false assumption that a key belongs to the claimed mail address. Better ask for a key by mail, embed the key in your signature, attach the mail to the mail, or use the Web Key Directory. Keyserver can only be useful for distributing revocation certificates but in many cases this can also be done by the Web Key Directory (in fact gpg-wks-client appends revocations of old keys to new keys). For other use cases a mail address might not be needed. For example I use this key to sign tarballs etc. pub ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA6E64A76D2840571B4902528897B826403ADA uid [ full ] Werner Koch (dist signing 2020) Other use cases are keys shared within a project without a corresponding mail address. > I was reluctant to include it because of spam harvesting, however I have 20 years ago or so I have seen a few spams coming from keyserver harvested keys. But that is too rare than too care about. See above regarding my opinion on keyservers. Salam-Shalom, Werner p.s. BTW: Although I use for historic reasons a @jabber.gnupg.org address for Jabber (XMPP) modern jabber ids would just use the domain name (for me thus wk at gnupg.org) and then it is not easy to distinguish between mail use of a key and use for jabber (e.g. using Conversations.im). Thus I consider to propose a new key flag to mark a subkey for use with chat program in contrast to mail/data use. This would allow to use the same key for mail and chat without risking to put the more valuable mail encryption key on a easier to attack smartphone. -- 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 May 13 15:32:56 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 May 2025 15:32:56 +0200 Subject: S/MIME which certificate format In-Reply-To: <87ldr735gu.fsf@jacob.g10code.de> (Werner Koch via Gnupg-users's message of "Thu, 08 May 2025 09:51:45 +0200") References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87wmau3w8u.fsf@jacob.g10code.de> <20250506171128.3d18c562@ryz.dorfdsl.de> <8734dg4mfb.fsf@jacob.g10code.de> <20250507192610.79f83b25@ryz.dorfdsl.de> <87ldr735gu.fsf@jacob.g10code.de> Message-ID: <87ikm463g7.fsf@jacob.g10code.de> On Thu, 8 May 2025 09:51, Werner Koch said: > Please send me the PKCS7.p7b file again by private mail and gzip it > first to avoid any problems. Thanks. That file is a certs-only CMS object. It is base64 encoded w/o the header lines. After converting this to binary I get: $ gpgsm -v --import ~/tmp/PKCS7_m.p7 [...] gpgsm: certificate imported gpgsm: certificate is good gpgsm: certificate imported gpgsm: certificate is good gpgsm: certificate imported gpgsm: certificate is good gpgsm: certificate is good gpgsm: certificate imported gpgsm: no subject found in certificate gpgsm: total number processed: 4 gpgsm: imported: 4 [GNUPG:] FAILURE gpgsm-exit 50331649 Thus all certificates where imported but due to a missing subject in of of it, gpgsm returns with an error (the code is General Error). A gpgsm -k gives (with some redaction): S/N: 01 Issuer: /CN=AAA Certificate Services/O=Comodo CA Limited/L=Salford/ST=Greater Manchester/C=GB Subject: [Same as /CN=AAA Certificate Services/O=Comodo CA Limited/L=Salford/ST=Greater Manchester/C=GB S/N: 3972443AF922B751D7D36C10DD313595 (dec): 76359301477803385872276235234032301461 Issuer: /CN=AAA Certificate Services/O=Comodo CA Limited/L=Salford/ST=Greater Manchester/C=GB Subject: /CN=USERTrust RSA Certification Authority/O=The USERTRUST Network/L=Jersey City/ST=New Jersey/C=US S/N: 4D942C10D43BE09409C5812D3A2B064F Issuer: /CN=USERTrust RSA Certification Authority/O=The USERTRUST Network/L=Jersey City/ST=New Jersey/C=US Subject: /CN=Sectigo RSA Client Authentication and Secure Email CA/O=Sectigo Limited/L=Salford/ST=Greater Manchester/C=GB ID: 0x520AB3F9 S/N: 00CDB882CF52A4258A4CB6FA03C415DDBD Issuer: /CN=Sectigo RSA Client Authentication and Secure Email CA/O=Sectigo Limited/L=Salford/ST=Greater Manchester/C=GB Subject: [Error - No name] aka: Because gpgsm does by default only detect armored and binary data you need to tell it that the input is base64 only: $ gpgsm -v --import --assume-base64 ~/tmp/PKCS7_m.p7b That will yield the same result as my import from the binary version. Takeaway is that we can handle an empty subject but that return an error. I just fixed this for for master and 2.4. See https://dev.gnupg.org/T7171 Auto detecting plain base64 will not be implemented (in your sample this is just one long 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 andrewg at andrewg.com Tue May 13 18:47:42 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 13 May 2025 17:47:42 +0100 Subject: Should you include your email address on key server? In-Reply-To: <87wmak674b.fsf@jacob.g10code.de> References: <87wmak674b.fsf@jacob.g10code.de> Message-ID: On 13 May 2025, at 13:13, Werner Koch via Gnupg-users wrote: > Keyserver can only be useful for distributing revocation certificates > but in many cases this can also be done by the Web Key Directory (in > fact gpg-wks-client appends revocations of old keys to new keys). Note however that many clients cannot import the revocations as generated by gpg-wks-client. Because it appends detached signature packets to valid TPKs, these appear to be revocation signatures over the preceding primary key - but in most cases the last signable component of a TPK is a subkey, meaning that these primary key revocation sigs form an invalid packet sequence and so are often discarded on import. This is why hockeypuck always _pre_pends detached revocation packets, although it?s not clear whether all clients cleanly import those either? If gnupg would just implement T6900 this problem would go away of course. :-P > Thus I > consider to propose a new key flag to mark a subkey for use with chat > program in contrast to mail/data use. It might be more useful to define a generic domain separation scheme whereby a subkey could be tied to one or more applications (as represented by mime types or domains). This would avoid having to maintain a centrally-approved list of categories. Also remember we already struggle to make a clear distinction between the existing two categories of encryption usage. Does DeltaChat count as ?email? or ?chat?? > This would allow to use the same > key for mail and chat without risking to put the more valuable mail > encryption key on a easier to attack smartphone. Smartphones are pretty robust these days. I?d sooner trust an iphone to keep my secret key safe than Windows 11, for example. Since most normal people want to be able to read email on their phones, the main issue for them is how to get the secret key material onto the phone without using a transport mechanism that?s less secure than the devices on either end. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kyrieuon at gmail.com Tue May 13 23:18:19 2025 From: kyrieuon at gmail.com (Richard Stoughton) Date: Tue, 13 May 2025 23:18:19 +0200 Subject: Signing a file given its hash only Message-ID: Hi, We have three servers H -> M -> L with high, medium, and low security. The private signature key is known to H only and must never leave H. Artifacts that must be signed are produced on M which is capable of calculating hashes (e.g. SHA-256 hashes). H has the ability to read these hashes but cannot access the artifacts. The artifacts are then being transported to L where they are considered valid if there is also a valid signature for them. H is expected to push the respective signatures to L. The question is: Is it possible to gpg-sign a file given its hash only? -- Thanks in advance, Alex From dgouttegattat at incenp.org Tue May 13 23:10:45 2025 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 13 May 2025 22:10:45 +0100 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <8734d96idg.fsf@jacob.g10code.de> References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> Message-ID: <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> On Tuesday, 13 May 2025 09:10:35 BST Werner Koch via Gnupg-users wrote: > On Thu, 8 May 2025 10:43, Simon Josefsson said: > > Oh! Is there a step-by-step instruction how to create a key like > > this? > > Not yet. However some folks obviously experimented with this I am one of those experimenting folks. :D Here?s a quick write-up of what I did: Starting from a point where you already have a ECC key on a token, first thing is to get the keygrip of that key: $ gpg -K --with-keygrip [keyboxd] sec ed25519 2020-05-14 [SC] 0E3E30F7E0C3B7F2CBF4D4145A7FD609833CCD4A Keygrip = 2139B71E586D798EC5ADF4AA2EEDDE5A21351AE7 uid [ultimate] Alice ssb cv25519 2020-05-14 [E] BD13A83426BAE9BC5C41A33745EDD81BCE62E9BD Card serial no. = FFFE 12345678 Keygrip = Then, you need to generate the Kyber part of the new Kyber+ECC key. There are several ways to do that. One is to use the command given by Werner: $ gpg-connect-agent "/let param (genkey(kyber1024))" \ "/definq KEYPARAM param" "genkey --no-protection" /bye S INQUIRE_MAXLEN 1024 INQUIRE KEYPARAM S KEYGRIP OK Take note of the . In fact, make sure you have the ECC_KEYGRIP and the KYBER_KEYGRIP in a text file somewhere, ready to be copy-pasted. (Another way to obtain a Kyber key: ask GnuPG to generate a brand new Kyber+ECC key, then take note of the keygrip for the Kyber part and delete the ECC part that you do not need.) Then, launch GnuPG?s key editor in expert mode: $ gpg --expert --edit-key alice Add a new subkey: gpg> addkey Please select what kind of key you want: [...] Select "(13) Existing key". At the "Enter the keygrip" prompt, paste the ECC_KEYGRIP, followed by a comma, followed by the KYBER_KEYGRIP: Enter the keygrip: ECC_KEYGRIP,KYBER_KEYGRIP GnuPG will recognize that as Kyber key that can only be used for encryption, so select "(Q) Finished" at the next prompt: Possible actions for this Kyber key: Encrypt Current allowed actions: Encrypt (E) Toggle the encrypt capability (Q) Finished Your selection? Q Then follow the rest of the key generation procedure (selection of expiration date, confirmation, really create), then save your modifications and exit the key editor. You can run `gpg -K --with-keygrip` again to confirm the presence of your new Kyber+ECC key which shares a keygrip with your pre-existing, on-token ECC key: $ gpg -K --with-keygrip [keyboxd] sec ed25519 2020-05-14 [SC] 0E3E30F7E0C3B7F2CBF4D4145A7FD609833CCD4A Keygrip = 2139B71E586D798EC5ADF4AA2EEDDE5A21351AE7 uid [ultimate] Alice ssb cv25519 2020-05-14 [E] BD13A83426BAE9BC5C41A33745EDD81BCE62E9BD Card serial no. = FFFE 12345678 Keygrip = ssb ky1024_cv25519 2025-05-13 [E] FC1283D6D0A12637A6EB0E8044ADD592FC362FBB5B1676B03F6B0EA8F60F3544 Card serial no. = FFFE 12345678 Keygrip = , Here you are, I hope this helps. Few things to be aware of: First, maybe wait until GnuPG 2.5.7 has been released before publishing such a key, because as of GnuPG 2.5.6 decryption will _not_ work when the ECC part is on a token. Or patch your version of GnuPG with Gniibe?s 309cfb3a4c91 commit. Second, as you?ll have noticed the Kyber key has been generated without a passphrase ("genkey --no-protection"). If you do want to protect that key, it?s better to do that at the time you generate it (by leaving aside the "--no-protection" parameter), because GnuPG will not allow you to set a passphrase on that key afterwards: if you try the "passwd" command in the key editor, GnuPG will notice that the ECC part is on a token, and will therefore claim that there is no passphrase to change -- ignoring the fact that the Kyber part is on disk (maybe this could be considered a bug, or at least a missing feature; then again all of this is clearly experimental, so this is to be expected.) Have fun! - 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 mysidia at gmail.com Wed May 14 00:58:56 2025 From: mysidia at gmail.com (Jay Acuna) Date: Tue, 13 May 2025 17:58:56 -0500 Subject: Signing a file given its hash only In-Reply-To: References: Message-ID: On Tue, May 13, 2025 at 5:20?PM Richard Stoughton via Gnupg-users wrote: > Hi, > > We have three servers H -> M -> L with high, medium, and low security. > The private signature key is known to H only and must never leave H. > > The question is: Is it possible to gpg-sign a file given its hash only? Your options with GPG are essentially to sign a text file or message that lists the hash. Then have L verify the GPG signature and then verify the hash listed in the signed file matches the file to be verified. Or you can forward the Gpg-agent from H to M using remote gpg agent forwarding over SSH, and run the Gpg signing command on M, so that M performs the hashing and H performs the key operation. Or files on M could possibly be made available to H using a network-based mount, such as SSHFS or NFS. Other than that; the GPG client had to have access to a file in order for it to be capable of signing that file. -- -JA From vedaal at nym.hush.com Wed May 14 01:11:26 2025 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 13 May 2025 19:11:26 -0400 Subject: Signing a file given its hash only In-Reply-To: Message-ID: <96f0eb8c3abe8029d1093e03d9f28166a864c7b3c7839cca@smtp.hushmail.com> On 5/13/2025 at 6:22 PM, "Richard Stoughton via Gnupg-users" wrote:Hi, We have three servers H -> M -> L with high, medium, and low security. The private signature key is known to H only and must never leave H. Artifacts that must be signed are produced on M which is capable of calculating hashes (e.g. SHA-256 hashes). H has the ability to read these hashes but cannot access the artifacts. The artifacts are then being transported to L where they are considered valid if there is also a valid signature for them. H is expected to push the respective signatures to L. The question is: Is it possible to gpg-sign a file given its hash only? ===== The same thing can be accomplished by having H sign the hash itself. Assuming that the signing algorithm is secure, then anyone reading L, and having M's public key, can verify that the hash from M, matches the artifact on L. - vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at mattborja.dev Wed May 14 02:21:48 2025 From: me at mattborja.dev (Matt Borja) Date: Wed, 14 May 2025 00:21:48 +0000 Subject: Signing a file given its hash only In-Reply-To: References: Message-ID: Hi there, Unless I?m missing something, this is a pattern I see used in release management where a list of SHA256 checksums for deliverables are provided in a file, and that checksum file is then clearsigned (or detached if you prefer). Also known also ?signing your checksums file.? Examples: - https://releases.ubuntu.com/focal/ - https://www.debian.org/CD/verify The security of this process in the scenario you described, however, would be contingent upon a) the transport security between M and H, and b) whether H in fact trusts M to produce valid and trustworthy checksums. Assuming everything is okay here, you then ship both the checksums file and its corresponding GPG signature to L. In this manner, H does not require access to artifacts on M due to their SHA256 representatives (presumed to be cryptographically ensured) and L of course is presumed to be secure because it only involves the use of public keys, cryptography, and resultant signatures needing to be verified by external consumers, etc. I would offer, though, that M should actually be considered just as sensitive as H since it is producing artifacts (aka attestations) that H is going to end up signing for. If you?re automating this (as in DevOps), consider supply chain threat scenarios and the implications of a compromised M producing some nullifying claim or malicious code that ends up getting certified as ?valid? by H. Regards, Matt On Tue, May 13, 2025 at 15:22, Richard Stoughton via Gnupg-users < [gnupg-users at gnupg.org](mailto:On Tue, May 13, 2025 at 15:22, Richard Stoughton via Gnupg-users < wrote: > Hi, > > We have three servers H -> M -> L with high, medium, and low security. > > The private signature key is known to H only and must never leave H. > > Artifacts that must be signed are produced on M which is capable of > calculating hashes (e.g. SHA-256 hashes). H has the ability to read > these hashes but cannot access the artifacts. > > The artifacts are then being transported to L where they are > considered valid if there is also a valid signature for them. H is > expected to push the respective signatures to L. > > The question is: Is it possible to gpg-sign a file given its hash only? > > -- > Thanks in advance, > Alex > > _______________________________________________ > 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 simon at josefsson.org Wed May 14 09:03:19 2025 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 14 May 2025 09:03:19 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> (Damien Goutte-Gattat via Gnupg-users's message of "Tue, 13 May 2025 22:10:45 +0100") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> Message-ID: <87ikm3wu6g.fsf@josefsson.org> Damien Goutte-Gattat via Gnupg-users writes: > On Tuesday, 13 May 2025 09:10:35 BST Werner Koch via Gnupg-users wrote: >> On Thu, 8 May 2025 10:43, Simon Josefsson said: >> > Oh! Is there a step-by-step instruction how to create a key like >> > this? >> >> Not yet. However some folks obviously experimented with this > > I am one of those experimenting folks. :D > > Here?s a quick write-up of what I did: Thank you! I think we are now close to iterate this towards a functional recipe. What's missing for me is to build and install the tools in some usable way. What system are you using, and which packages did you have to build and how did you install them? It was hard for me to get anything to work on a Debian-derived distribution because they ship a GnuPG fork that interacts badly with genuine GnuPG. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From wk at gnupg.org Wed May 14 09:57:22 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2025 09:57:22 +0200 Subject: list option show-unusable-uids has no effect on show-only-fpr-mbox output In-Reply-To: ("Uwe =?utf-8?Q?Kleine-K=C3=B6nig=22's?= message of "Tue, 15 Apr 2025 16:17:44 +0200") References: Message-ID: <87zfff4obh.fsf@jacob.g10code.de> On Tue, 15 Apr 2025 16:17, Uwe Kleine-K?nig said: > Recently a UID of a key in the WKD I maintain was revoked. While trying > to add the key with the revoked UID to the WKD I noticed this > inconsistency (which made it unnecessarily hard to add the key to the > WKD): Thanks for the report. The reason that show-unusable-uids was not considred is due to the use of a simplified listing functions for the show-only-fpr-mbox case. The fix was easy and has just been pushed to master and 2.4. https://dev.gnupg.org/rGd5a4a2dc890ea21e371662872fcfd43ed9d16142 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 May 14 10:00:47 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2025 10:00:47 +0200 Subject: Should you include your email address on key server? In-Reply-To: (Andrew Gallagher via Gnupg-users's message of "Tue, 13 May 2025 17:47:42 +0100") References: <87wmak674b.fsf@jacob.g10code.de> Message-ID: <87v7q34o5s.fsf@jacob.g10code.de> On Tue, 13 May 2025 17:47, Andrew Gallagher said: > Note however that many clients cannot import the revocations as > generated by gpg-wks-client. Because it appends detached signature Well, then I would suggest to update the clients ;-) From practical experience this is a pretty useful feature. Gpg has had always the feature to handle stand-alone revocation certificates. I know that PGP does not handle them, this is why we don't do this by default and only in the WKD context. 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 May 14 10:08:40 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2025 10:08:40 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> (Damien Goutte-Gattat via Gnupg-users's message of "Tue, 13 May 2025 22:10:45 +0100") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> Message-ID: <87o6vv4nsn.fsf@jacob.g10code.de> > the "passwd" command in the key editor, GnuPG will notice that the ECC > part is on a token, and will therefore claim that there is no > passphrase to change -- ignoring the fact that the Kyber part is on > disk (maybe this could be considered a bug, or at least a missing > feature; then again all of this is clearly experimental, so this is to Yes, this should be fixed. https://dev.gnupg.org/T7653 Workaround is to use gpg-connect-agent 'passwd KYBER_KEYGRIP' /bye 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 Wed May 14 10:13:59 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2025 10:13:59 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87ikm3wu6g.fsf@josefsson.org> (Simon Josefsson via Gnupg-users's message of "Wed, 14 May 2025 09:03:19 +0200") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87ikm3wu6g.fsf@josefsson.org> Message-ID: <87jz6j4njs.fsf@jacob.g10code.de> On Wed, 14 May 2025 09:03, Simon Josefsson said: > did you have to build and how did you install them? It was hard for me > to get anything to work on a Debian-derived distribution because they > ship a GnuPG fork that interacts badly with genuine GnuPG. Speedo is the way to go. The easiest way is to download the gnupg-w32 tarball which has almost all required packages. In brief from the README: $ apt-get install build-essential libusb-1.0-0-dev libsqlite3-dev patchelf $ make -f build-aux/speedo.mk this-native $ make -f build-aux/speedo.mk install SYSROOT=/usr/local/gnupg26 Then start gpg using /usr/local/gnupg26/bin/gpg and everything should work fine. Make sure that systemd does not start the default gpg-agent either by disabling the autostart via systemd thing or by using a different GNUPGHOME. 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 dgouttegattat at incenp.org Wed May 14 10:21:42 2025 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 14 May 2025 09:21:42 +0100 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87o6vv4nsn.fsf@jacob.g10code.de> References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87o6vv4nsn.fsf@jacob.g10code.de> Message-ID: <4790017.vXUDI8C0e8@borealin.local.incenp.org> On Wednesday, 14 May 2025 09:08:40 BST Werner Koch wrote: > Workaround is to use > > gpg-connect-agent 'passwd KYBER_KEYGRIP' /bye Thanks! In my case I?m actually fine with the Kyber key not being passphrase-protected, but it?s good to know there is a workaround. - 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 andrewg at andrewg.com Wed May 14 10:36:07 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 May 2025 09:36:07 +0100 Subject: Should you include your email address on key server? In-Reply-To: <87v7q34o5s.fsf@jacob.g10code.de> References: <87wmak674b.fsf@jacob.g10code.de> <87v7q34o5s.fsf@jacob.g10code.de> Message-ID: On 14 May 2025, at 09:00, Werner Koch wrote: > > On Tue, 13 May 2025 17:47, Andrew Gallagher said: > >> Note however that many clients cannot import the revocations as >> generated by gpg-wks-client. Because it appends detached signature > > Well, then I would suggest to update the clients ;-) > > From practical experience this is a pretty useful feature. Gpg has had > always the feature to handle stand-alone revocation certificates. I agree, it?s a very useful feature. My complaint is the ambiguous wire format, which is difficult to parse cleanly. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From dgouttegattat at incenp.org Wed May 14 10:49:41 2025 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 14 May 2025 09:49:41 +0100 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87ikm3wu6g.fsf@josefsson.org> References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87ikm3wu6g.fsf@josefsson.org> Message-ID: <5731703.ZASKD2KPVS@borealin.local.incenp.org> On Wednesday, 14 May 2025 08:03:19 BST Simon Josefsson wrote: > What's missing for me is to build and install the > tools in some usable way. What system are you using, and which packages > did you have to build and how did you install them? It was hard for me > to get anything to work on a Debian-derived distribution I use Slackware. I build my own packages for all GnuPG stuff (libgpg-error, libassuan, libgcrypt, gnupg, etc.) and use them instead of the system-provided packages, so that I can always use the latest version (and apply patches when needed). Slackware makes it very easy to do things like that, but I am not sure how easy it would be to do something similar on a Debian-based system. Debian packaging is, well, a thing in itself. If you don?t mind installing programs that are not under the control of your system?s package manager, another option is to build and install an entire GnuPG stack *in parallel* to your system-managed one, somewhere under /usr/local (or even somewhere in your own home directory if you don?t want to mess with your system at all). The ?speedo.mk? build script (in gnupg?s build-aux directory) comes in very handy for that, try running `make -f build-aux/speedo.mk help` for details. > because they ship a GnuPG fork that interacts badly with genuine GnuPG. o_O - 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 andrewg at andrewg.com Wed May 14 11:07:49 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 May 2025 10:07:49 +0100 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87ikm3wu6g.fsf@josefsson.org> References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87ikm3wu6g.fsf@josefsson.org> Message-ID: <4ED8B084-43B6-4AAC-89AA-B16D635C461F@andrewg.com> On 14 May 2025, at 08:03, Simon Josefsson via Gnupg-users wrote: > > It was hard for me > to get anything to work on a Debian-derived distribution because they > ship a GnuPG fork that interacts badly with genuine GnuPG. In what way does it interact badly? Is it worse than just a version mismatch? Debian is still shipping 2.2 in stable, but 2.4 is now in trixie. Remember that kyber is not supported in either, as it is only in the experimental 2.5 branch. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed May 14 12:30:12 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2025 12:30:12 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <4ED8B084-43B6-4AAC-89AA-B16D635C461F@andrewg.com> (Andrew Gallagher via Gnupg-users's message of "Wed, 14 May 2025 10:07:49 +0100") References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87ikm3wu6g.fsf@josefsson.org> <4ED8B084-43B6-4AAC-89AA-B16D635C461F@andrewg.com> Message-ID: <87ecwr4h8r.fsf@jacob.g10code.de> On Wed, 14 May 2025 10:07, Andrew Gallagher said: > In what way does it interact badly? Is it worse than just a version Systemd tries to start /usr/bin/gpg-agent as soon as another process (e.g. /usr/local/bin/gpg) tries to connect to the gpg-agent socket. Thus gpg will connect to a gpg-agent which is not the one installed under /usr/local/bin (or whereever gnupg was installed). Here is an untested hack to avoid this by using the gpgconf.ctl hack. Add a line socketdir = /run/user/$USERS_UID/localgnupg into the gpgconf.ctl (a Speedo build creates this) and put into ~/.bashrc or similar export USERS_UID=$(id -u) 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 ametzler at bebt.de Wed May 14 18:48:06 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 14 May 2025 18:48:06 +0200 Subject: Opengpg smartcard specs for kyber (PQC) algorithm In-Reply-To: <87ecwr4h8r.fsf@jacob.g10code.de> References: <8GCUwLrLcHZ7fprOf1s4FR6K9QnBE_-l9aHqKeLaXTKObyxX4ILUV2u_lwxDaS7fw3VxMdtCE_2pOM7SpfJbaUFU_empkSlCO0PIqOlzUGI=@proton.me> <87ikmbijbi.fsf@josefsson.org> <8734d96idg.fsf@jacob.g10code.de> <3552428.sQuhbGJ8Bu@borealin.local.incenp.org> <87ikm3wu6g.fsf@josefsson.org> <4ED8B084-43B6-4AAC-89AA-B16D635C461F@andrewg.com> <87ecwr4h8r.fsf@jacob.g10code.de> Message-ID: On 2025-05-14 Werner Koch via Gnupg-users wrote: > On Wed, 14 May 2025 10:07, Andrew Gallagher said: > > In what way does it interact badly? Is it worse than just a version > Systemd tries to start /usr/bin/gpg-agent as soon as another process > (e.g. /usr/local/bin/gpg) tries to connect to the gpg-agent socket. > Thus gpg will connect to a gpg-agent which is not the one installed > under /usr/local/bin (or whereever gnupg was installed). > Here is an untested hack to avoid this by using the gpgconf.ctl hack. [...] Hello, If the problem really is that gnupg 2.5 is installed alongside the distro gnupg 2.4 packages and the wrong agent (2.4) is started via systemd then the natural way to fix this is to mask the system user-units as described in /usr/share/doc/gpg-agent/README.Debian cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From chd at chud.net Wed May 14 21:15:37 2025 From: chd at chud.net (Chris DeYoung) Date: Wed, 14 May 2025 12:15:37 -0700 Subject: Signing a file given its hash only In-Reply-To: <96f0eb8c3abe8029d1093e03d9f28166a864c7b3c7839cca@smtp.hushmail.com> References: <96f0eb8c3abe8029d1093e03d9f28166a864c7b3c7839cca@smtp.hushmail.com> Message-ID: > Artifacts that must be signed are produced on M which is capable of > calculating hashes (e.g. SHA-256 hashes). H has the ability to read > these hashes but cannot access the artifacts. How does H know that the hash is valid? H could just sign the hash if it trusts what M generates, but it isn't obvious to me how that's more secure than just having M sign it. -C