From klaus at vink-slott.dk Thu Jan 1 18:16:06 2026 From: klaus at vink-slott.dk (Klaus Vink Slott) Date: Thu, 1 Jan 2026 18:16:06 +0100 Subject: pinentryQT timeout In-Reply-To: <2580878.XAFRqVoOGU@daneel> References: <9941ad91-3182-4f2c-8fd2-5e19a47cc2de@vink-slott.dk> <2580878.XAFRqVoOGU@daneel> Message-ID: Den 31.12.2025 kl. 19.22 skrev Ingo Kl?cker: > On Mittwoch, 31. Dezember 2025 10:38:01 Mitteleurop?ische Normalzeit Klaus > Vink Slott via Gnupg-users wrote: ... >> I've searched through the options in the PIN entry program for a "stay >> on top" option, not finding any - also tried to add an extended time to >> the gpg-agent.conf file, but it didn't help. >> >> Do you have any ideas, or should I give up on the KDE relaunch feature? > > Maybe you can set Special Window settings or Special Application settings for > pinentry-qt to keep its window on top. Right-click on the title bar of > pinentry, select More Actions... and then Configure Special Window Settings... > Then add the "Keep above other windows" property (under Arrangement & Access). That was a good hint ? I can now keep the Window on top. Unfortunately it still looses focus, but at least I can regain focus quick as the window itself stays on top. I will have to dig a bit deeper into KDE setting if I can avoid loosing focus. -- Klaus From dev at nixonnet.org Mon Jan 5 02:50:03 2026 From: dev at nixonnet.org (Bow) Date: Sun, 4 Jan 2026 17:50:03 -0800 Subject: Securing multiple keys with one smart card References: Message-ID: Hello GnuPG Users, Is there a known way to encrypt multiple/all private keys in the keyring with a single smart card? Use case: I have separate keys for separate identities (e.g. personal and professional) and I would like to secure these keys with a smart card (actual ISO 7816 card, not a USB token) such that I can access the private keys using the card and a PIN or PINs. My goal is to have the ease of a card and shorter PIN, and the security of needing two factors. I will be installing the OpenPGP Card applet onto the card myself, so modified versions are an option. Using one card per identity is cost and convenience prohibitive. Currently I am using GPG 2.4.8 with libcrypt 1.11.2 installed from the Arch Linux repository. Thank you for your time, Bow -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 6 08:50:35 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Jan 2026 08:50:35 +0100 Subject: Securing multiple keys with one smart card In-Reply-To: (Bow via Gnupg-users's message of "Sun, 4 Jan 2026 17:50:03 -0800") References: Message-ID: <87pl7nnpro.fsf@jacob.g10code.de> Hi! > Is there a known way to encrypt multiple/all private keys in the > keyring with a single smart card? Do you mean to replace the passphrase by some kind of encryption using a smartcard? This is not possible but it may be worth to discuss such an option. > Using one card per identity is cost and convenience prohibitive. In theory you can create several *PGP keys with the same physical key on the smartcard. But there are some problems. It is better to use smartcard which allows to store/create several keys and not just the 3 keys we specified for the OpenPGP card. An updated specification of the OpenPGP card will support more keys. The drawback of this all is that smartcards may build up a defect and you would loose access to all your private keys.q 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: 284 bytes Desc: not available URL: From poontele at gmail.com Tue Jan 6 19:43:48 2026 From: poontele at gmail.com (=?UTF-8?B?6Zmz5b2l5L2Q?=) Date: Wed, 7 Jan 2026 02:43:48 +0800 Subject: Inquiry regarding official GnuPG recommendation for Android Message-ID: <8a4c714f-922b-4a40-9bbb-04482ef0bdf0@gmail.com> Hello, I noticed that gnupg.org currently references the Guardian Project for Android support. However, the Guardian Project's official page states that the project is unmaintained and now recommends OpenKeychain. Could you please clarify whether there is currently an officially supported or recommended GnuPG application for Android? I am specifically looking for a maintained solution that is available on F-Droid. Thank you for your assistance. From dev at nixonnet.org Tue Jan 6 22:40:50 2026 From: dev at nixonnet.org (Bow) Date: Tue, 6 Jan 2026 13:40:50 -0800 Subject: Securing multiple keys with one smart card In-Reply-To: <87pl7nnpro.fsf@jacob.g10code.de> References: <87pl7nnpro.fsf@jacob.g10code.de> Message-ID: > Do you mean to replace the passphrase by some kind of encryption > using a smartcard? I did, but I understand that is not supported by GnuPG (currently). I was hoping that I was mistaken about that limitation or that there was a work-around of some sort. My goal is have my private key material protected by more than just a usable (that is, a long but not very long) password. Ideally with a card as a second factor. > It is better to use smartcard which allows to store/create several > keys and not just the 3 keys we specified for the OpenPGP card. It is my understanding that GnuPG only supports OpenPGP Card smart cards. Is there another card type that would work? My card has space for plenty of keys so storing all the keys on-card is feasible and would work very well for me. > An updated specification of the OpenPGP card will support more keys. I saw some discussion in a dev. mailing list about supporting more than 3 keys, but got the impression it was not likely to happen. Do you have more information or can you point me to where I can learn more? With gratitude, Bow -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From soyeomul at doraji.xyz Wed Jan 7 05:15:49 2026 From: soyeomul at doraji.xyz (Byunghee HWANG (Gmailify)) Date: Wed, 07 Jan 2026 13:15:49 +0900 Subject: verifying gpg signature under opendkim-lua script Message-ID: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> Hellow GnuPG Hackers, This is a very uncommon situation. I am running some news-letter mailing under postfix mail server [yw-0919.doraji.xyz; Ubuntu 18.04.6 LTS] (Google Cloud's Compute Engine). That news-letter email is sent automatically every day by cron. And that email be signed with gpg signature in start time (ed25519; 0x031016E4BEA9EA6A3A0F7D4DF60CC059E52D9596; made by GnuPG 2.2.4). And outbond's mail server [yw-1204.doraji.xyz; Debian 11 (Bullseye)] has OpenDKIM filter (with lua script). If possible, i would like to verify the gpg fingerprint of that email with this OpenDKIM lua script. *This point is my real question.* Then the OpenDKIM filter do signing DKIM that email after verification (success). If gpg fingerprint verification fails, the DKIM signing will be withheld. Any comments, ideas, thoughts, advice welcome! Sincerely, Byunghee from South Korea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ThSchweikle at bfs.de Wed Jan 7 14:38:34 2026 From: ThSchweikle at bfs.de (Thomas Schweikle) Date: Wed, 7 Jan 2026 13:38:34 +0000 Subject: gpgpass.exe - the gpg4win gpg based password manager is missing Message-ID: <6fe57859-66f6-45b8-9eb5-232091baa143@bfs.de> Hi! From the install binary available at https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta479/gpg4win-5.0.0-beta479.exe The password manager gpgpass.exe is missing. It is not available within this installation. Is this only a bug, or ist this thing removed? -- Thomas From sebastian.wagner at intevation.de Wed Jan 7 17:54:24 2026 From: sebastian.wagner at intevation.de (Sebastian Wagner) Date: Wed, 7 Jan 2026 17:54:24 +0100 Subject: gpgpass.exe - the gpg4win gpg based password manager is missing In-Reply-To: <6fe57859-66f6-45b8-9eb5-232091baa143@bfs.de> References: <6fe57859-66f6-45b8-9eb5-232091baa143@bfs.de> Message-ID: <7301d016-c81f-4443-a2d8-486de2b4a5b2@intevation.de> Hi Thomas On 07/01/2026 14:38, Thomas Schweikle via Gnupg-users wrote: > From the install binary available at > https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta479/gpg4win-5.0.0-beta479.exe > The password manager gpgpass.exe is missing. It is not available within > this installation. > > Is this only a bug, or ist this thing removed? It appears the program has been removed: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=commit;h=10aa3f1ed73f91c8421e968c7a8107fd1ec47137 Best regards -- Sebastian Wagner | +49-541-335083-164 | https://intevation.de Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jan 8 05:46:03 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 7 Jan 2026 23:46:03 -0500 Subject: verifying gpg signature under opendkim-lua script In-Reply-To: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> References: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> Message-ID: <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> > This is a very uncommon situation. I am running some news-letter mailing > under postfix mail server [yw-0919.doraji.xyz; Ubuntu 18.04.6 LTS] > (Google Cloud's Compute Engine). That news-letter email is sent > automatically every day by cron. And that email be signed with gpg > signature in start time (ed25519; > 0x031016E4BEA9EA6A3A0F7D4DF60CC059E52D9596; made by GnuPG 2.2.4). > > And outbond's mail server [yw-1204.doraji.xyz; Debian 11 (Bullseye)] has > OpenDKIM filter (with lua script). If possible, i would like to verify > the gpg fingerprint of that email with this OpenDKIM lua script. *This > point is my real question.* I've been holding off on this in the hopes someone better at Lua scripting than I would speak up, but apparently I'm what you get. My first question is, "what are you hoping to achieve by verifying the fingerprint?" Do you actually mean verifying the digital signature on the email? From soyeomul at doraji.xyz Thu Jan 8 07:23:30 2026 From: soyeomul at doraji.xyz (Byunghee HWANG) Date: Thu, 08 Jan 2026 15:23:30 +0900 Subject: verifying gpg signature under opendkim-lua script In-Reply-To: <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Wed, 7 Jan 2026 23:46:03 -0500") References: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> Message-ID: <87bjj4pqql.fsf@thinkpad-e495.home.arpa> Hellow Robert, "Robert J. Hansen via Gnupg-users" writes: >> This is a very uncommon situation. I am running some news-letter mailing >> under postfix mail server [yw-0919.doraji.xyz; Ubuntu 18.04.6 LTS] >> (Google Cloud's Compute Engine). That news-letter email is sent >> automatically every day by cron. And that email be signed with gpg >> signature in start time (ed25519; >> 0x031016E4BEA9EA6A3A0F7D4DF60CC059E52D9596; made by GnuPG 2.2.4). >> >> And outbond's mail server [yw-1204.doraji.xyz; Debian 11 (Bullseye)] has >> OpenDKIM filter (with lua script). If possible, i would like to verify >> the gpg fingerprint of that email with this OpenDKIM lua script. *This >> point is my real question.* > > I've been holding off on this in the hopes someone better at Lua > scripting than I would speak up, but apparently I'm what you get. > > My first question is, "what are you hoping to achieve by verifying the > fingerprint?" I don't archive it. The above was an example fingerprint used for questioning. > Do you actually mean verifying the digital signature on > the email? My ultimate goal is to route emails using gpg's fingerprinting. This is the first step toward that goal. That is all. Sincerely, -- ^????? _????_ ?????_^))// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Jan 8 08:01:56 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 8 Jan 2026 02:01:56 -0500 Subject: verifying gpg signature under opendkim-lua script In-Reply-To: <87bjj4pqql.fsf@thinkpad-e495.home.arpa> References: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> <87bjj4pqql.fsf@thinkpad-e495.home.arpa> Message-ID: > My ultimate goal is to route emails using gpg's fingerprinting. This is > the first step toward that goal. That is all. Lua doesn't have GPGME bindings, so you'll likely have to do this the error-prone way: fire up GnuPG and verify the signature, after hooking up --status-fd to a file descriptor of your choice. _Do not_ parse the normal console output: only the status-fd output should be used. When verifying a message with gpg --verify, you'll see a message stanza like: [GNUPG:] KEY_CONSIDERED CC11BE7CBBED77B120F37B011DCBDC01B44427C7 0 [GNUPG:] SIG_ID qtBYYa4lfH60IDd2oOz06S6QBjc 2026-01-08 1767855159 [GNUPG:] GOODSIG 1DCBDC01B44427C7 Robert J. Hansen The first, KEY_CONSIDERED, gives you the full fingerprint. If you then see GOODSIG the message has passed its signature verification and then you can have Lua do what you want with the message. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From m at gnupg.org Thu Jan 8 09:45:06 2026 From: m at gnupg.org (Meik Michalke) Date: Thu, 08 Jan 2026 09:45:06 +0100 Subject: gpgpass.exe - the gpg4win gpg based password manager is missing In-Reply-To: <6fe57859-66f6-45b8-9eb5-232091baa143@bfs.de> References: <6fe57859-66f6-45b8-9eb5-232091baa143@bfs.de> Message-ID: <3937190.i8XQvsm1lU@kasidy> [i replied yesterday, but didn't notice it wasn't also sent to the list...] hi thomas, Am Mittwoch, 7. Januar 2026, 14:38:34 CET schrieb Thomas Schweikle via Gnupg- users: > From the install binary available at > https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta479/gpg4win-5.0.0-beta479.e > xe The password manager gpgpass.exe is missing. It is not available within > this installation. > > Is this only a bug, or ist this thing removed? this was done on purpose. the tool is not dead, but there's still too many open issues and missing features that so we were not yet convinced to have it as part of a stable Gpg4Win 5.0 release. the alternative would have been to wait a lot longer for 5.0, but we think we're getting there soon. so after Gpg4Win 5.0 is out, it'll probably come back with one of the next beta versions and hopefully mature enough to no longer consider it "experimental". viele gr??e :: m.eik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jan 8 11:20:55 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Jan 2026 11:20:55 +0100 Subject: verifying gpg signature under opendkim-lua script In-Reply-To: (Robert J. Hansen via Gnupg-users's message of "Thu, 8 Jan 2026 02:01:56 -0500") References: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> <87bjj4pqql.fsf@thinkpad-e495.home.arpa> Message-ID: <87o6n4mmm0.fsf@jacob.g10code.de> On Thu, 8 Jan 2026 02:01, Robert J. Hansen said: > The first, KEY_CONSIDERED, gives you the full fingerprint. If you then but you may see severeal of these status lines. > see GOODSIG the message has passed its signature verification and then That is okay but if you need the fingerprint parse the also emitted [GNUPG:] VALIDSIG 6DAA6E64A76D2840571B4902528897B826403ADA 2025-12-30 1767102089 0 4 0 22 10 00 6DAA6E64A76D2840571B4902528897B826403ADA is the better option: The args are: - - - - - - - - - - [ ] This status indicates that the signature is cryptographically valid. This is similar to GOODSIG, EXPSIG, EXPKEYSIG, or REVKEYSIG (depending on the date and the state of the signature and signing key) but has the fingerprint as the argument. Multiple status lines (VALIDSIG and the other appropriate *SIG status) are emitted for a valid signature. All arguments here are on one long line. sig-timestamp is the signature creation time in seconds after the epoch. expire-timestamp is the signature expiration time in seconds after the epoch (zero means "does not expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a 2-byte hex value) are all straight from the signature packet. PRIMARY-KEY-FPR is the fingerprint of the primary key or identical to the first argument. This is useful to get back to the primary key without running gpg again for this purpose. The primary-key-fpr parameter is used for OpenPGP and not available for CMS signatures. The sig-version as well as the sig class is not defined for CMS and currently set to 0 and 00. Note, that *-TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'. 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: 284 bytes Desc: not available URL: From guru at unixarea.de Thu Jan 8 13:48:35 2026 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 8 Jan 2026 13:48:35 +0100 Subject: pass / gnupg is caching? Message-ID: I'm using the 'pass' command of password-store for all my stored credentials. While looking for some other problem I detected that it seems that gnupg (used by pass to decrypt the credentials) is storing the result of decryption somehow, at least it does not do again a read access to the file of the stored secret. In both cases I was asked for the PIN to unlock the OpenPGP card: $ ls -lu .password-store/test.gpg -rw------- 1 purism purism 585 Nov 26 14:45 .password-store/test.gpg $ pass test secret $ ls -lu .password-store/test.gpg -rw------- 1 purism purism 585 Jan 8 13:27 .password-store/test.gpg $ pass test secret $ ls -lu .password-store/test.gpg -rw------- 1 purism purism 585 Jan 8 13:27 .password-store/test.gpg i.e. the 2nd time does not modify the read access time of the file. Why? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From wk at gnupg.org Thu Jan 8 16:47:18 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Jan 2026 16:47:18 +0100 Subject: pass / gnupg is caching? In-Reply-To: (Matthias Apitz's message of "Thu, 8 Jan 2026 13:48:35 +0100") References: Message-ID: <875x9cm7i1.fsf@jacob.g10code.de> Hi Matthias, > i.e. the 2nd time does not modify the read access time of the file. Why? I don't think that pass as a shell script caches anything. Neither does gpg. I think you need to have "strictatime" in the mount options to get accurate atimes. The default seems to be "relatime" (Access time is only updated if the previous access time was earlier than the current modify or change time). 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: 284 bytes Desc: not available URL: From Bjorn at xn--rombobjrn-67a.se Thu Jan 8 16:40:45 2026 From: Bjorn at xn--rombobjrn-67a.se (=?UTF-8?B?QmrDtnJu?= Persson) Date: Thu, 8 Jan 2026 16:40:45 +0100 Subject: pass / gnupg is caching? In-Reply-To: References: Message-ID: <20260108164045.1a12e803@tag.xn--rombobjrn-67a.se> Matthias Apitz wrote: > i.e. the 2nd time does not modify the read access time of the file. Why? Is your filesystem perchance mounted with the "relatime" option? Writing a timestamp to the disk every time a file is read from the cache turned out to be bad for performance, and bad for the longevity of SSDs, so that's often omitted these days. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signatur URL: From guru at unixarea.de Fri Jan 9 09:49:46 2026 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 9 Jan 2026 09:49:46 +0100 Subject: pass / gnupg is caching? In-Reply-To: <875x9cm7i1.fsf@jacob.g10code.de> References: <875x9cm7i1.fsf@jacob.g10code.de> Message-ID: El d?a jueves, enero 08, 2026 a las 04:47:18p. m. +0100, Werner Koch via Gnupg-users escribi?: > Hi Matthias, > > > i.e. the 2nd time does not modify the read access time of the file. Why? > > I don't think that pass as a shell script caches anything. Neither does > gpg. I think you need to have "strictatime" in the mount options to get > accurate atimes. The default seems to be "relatime" (Access time is > only updated if the previous access time was earlier than the current > modify or change time). Hi Werner, Yes. The file system in my phone is mounted as: purism at pureos:~$ mount | grep ext4 /dev/mapper/crypt_root on / type ext4 (rw,relatime,errors=remount-ro) Thanks for the hints. matthias > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub An die deutsche Bundesregierung: Nein, meine S?hne geb' ich nicht f?r Ihren Krieg! Al Gobierno alem?n: ?No, no doy mis hijos para su guerra! To the German Government: No, I will not give my sons for your war! From me at paulapplegate.com Fri Jan 9 04:10:55 2026 From: me at paulapplegate.com (Paul Applegate) Date: Thu, 8 Jan 2026 22:10:55 -0500 Subject: GnuPG Development Hub Access Message-ID: <41C34F4A-ADF1-4912-8A96-B9B8B511B4AB@paulapplegate.com> May I have access to the GnuPG Development Hub ( https://dev.gnupg.org/ )? Username : mrapplegate Email : me at paulapplegate.com Thanks. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From fxkl47BF at protonmail.com Mon Jan 12 01:30:31 2026 From: fxkl47BF at protonmail.com (fxkl47BF at protonmail.com) Date: Mon, 12 Jan 2026 00:30:31 +0000 Subject: pass / gnupg is caching? In-Reply-To: <875x9cm7i1.fsf@jacob.g10code.de> References: <875x9cm7i1.fsf@jacob.g10code.de> Message-ID: <53q49r99-88q8-ooso-674r-6q3r21833946@cebgbaznvy.pbz> On Thu, 8 Jan 2026, Werner Koch via Gnupg-users wrote: > Hi Matthias, > >> i.e. the 2nd time does not modify the read access time of the file. Why? > > I don't think that pass as a shell script caches anything. Neither does > gpg. I think you need to have "strictatime" in the mount options to get > accurate atimes. The default seems to be "relatime" (Access time is > only updated if the previous access time was earlier than the current > modify or change time). the man page says caching is the default for symmetric encryption From steve at sawczyn.com Mon Jan 12 07:26:19 2026 From: steve at sawczyn.com (Steve Sawczyn) Date: Mon, 12 Jan 2026 00:26:19 -0600 Subject: Questions about web of trust, new keys, and whether it's even a thing any more Message-ID: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> I was going through some ancient backups and came across my original PGP 2.X keys from way back in the day. Back then, many of us worked hard to collect signatures to establish a web of trust. Of course this was ages ago now and as things have evolved, I?m now using newer keys. I?m not sure why this hadn?t occurred to me until now, but in migrating to newer keys, all those old signatures were lost. To be fair, I?m sure that most of those signatures could no longer be validated anyway since I?m sure everyone has moved on, but it got me thinking about the web of trust: Is that something people really even focus on any more? Also, how can the web of trust remain intact when there will inevitably come a time when key structures/algorithms will change again and people will need to generate new keys? What about key expiration, wouldn?t that cause a person to essentially have to start over with gathering signatures for new keys, or otherwise re-establishing trust? I?m sure I?m missing something very basic, but would really appreciate any thoughts or explanation. Thanks in advance, Steve From wk at gnupg.org Mon Jan 12 11:27:24 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Jan 2026 11:27:24 +0100 Subject: pass / gnupg is caching? In-Reply-To: <53q49r99-88q8-ooso-674r-6q3r21833946@cebgbaznvy.pbz> (fxkl47BF's message of "Mon, 12 Jan 2026 00:30:31 +0000") References: <875x9cm7i1.fsf@jacob.g10code.de> <53q49r99-88q8-ooso-674r-6q3r21833946@cebgbaznvy.pbz> Message-ID: <87ms2jktwz.fsf@jacob.g10code.de> On Mon, 12 Jan 2026 00:30, fxkl47BF--- said: > the man page says caching is the default for symmetric encryption Caching of ones own symmtric passphrase is a little hack and for most users not very useful: gpg caches the passphrase used for symmetric encryption so that a decrypt operation may not require that the user needs to enter the passphrase. The option --no-symkey-cache can be used to disable this feature. But that was not the question here. For the smartcard PIN's there is no caching but the smartcards decide on their own whether you need to enter the PIN for each signature/decryption. The only caching for those PINs is to overcome a problem wityh Yubikeys which do not keep the PIN-verified state when switching back and forth between the applications (OpenPGP <-> PIV) 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: 284 bytes Desc: not available URL: From wk at gnupg.org Mon Jan 12 11:34:00 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Jan 2026 11:34:00 +0100 Subject: Questions about web of trust, new keys, and whether it's even a thing any more In-Reply-To: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> (Steve Sawczyn via Gnupg-users's message of "Mon, 12 Jan 2026 00:26:19 -0600") References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> Message-ID: <87ikd7ktlz.fsf@jacob.g10code.de> On Mon, 12 Jan 2026 00:26, Steve Sawczyn said: > migrating to newer keys, all those old signatures were lost. To be > fair, I?m sure that most of those signatures could no longer be That's right and shows tha the WebofTrust does not really work to its full extend in real life. The reasons why old PGP 2 keys can't be used anymore are: - GnuPG 2.x dropped almost all support for those v3 (and v2) keys. - GnuPG does not anymore support the really broken MD5 hash algorithm - Some people fear collission attacks on SHA-1 keys and thus by default SHA-1 key signatures, as done for may years, are now not anymore usable. Note that gpg 1.4 is still available to decrypt old encrypted data. > change again and people will need to generate new keys? What about > key expiration, wouldn?t that cause a person to essentially have to > start over with gathering signatures for new keys, or otherwise It is possible and suggested to prolong the expiration time of a key. However, some folks used a signature expiration time when doing their 3rd party key signatures; this can only be solved by issuing a new key signature. 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: 284 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Jan 12 17:17:58 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 12 Jan 2026 11:17:58 -0500 Subject: Questions about web of trust, new keys, and whether it's even a thing any more In-Reply-To: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> Message-ID: <7fc7ec58-826d-487a-a0b6-f06971a27e28@sixdemonbag.org> tl;dr: your questions are good ones, but there are solid answers to them. :) > Is [the Web of Trust] something people really even focus on any > more? As with most things, there is no easy yes or no answer here. Everyone has their own particular GnuPG use case and threat model: under some of these the Web of Trust is irrelevant, and under others the Web of Trust is irreplaceable. As an example of irreplaceable Web of Trust usage: businesses that wish for all employees to automatically treat other employee certificates as validated might want to run their own certificate authority (CA), which will sign each employee's certificate with the business's certificate before putting the certificate in a company-wide keystore. When employees need to send email within the company, it acquires the needed certificate, checks the CA has signed it, and presto. This is probably the most common way the Web of Trust is used in the real world. Other good examples of the Web of Trust include things like software supply chains, where each individual release might have its own certificate signed by the project's master certificate. > Also, how can the web of trust remain intact when there will > inevitably come a time when key structures/algorithms will change > again and people will need to generate new keys? The trust spider needs to do constant upkeep on its web, that's for sure. But a lot of this can be mitigated via trusted introducer chaining, or dual signatures, or both. E.g.: certificate 23806BE5D6B98E10 was revoked in January of 2017. Before it did, though, it signed certificate 1DCBDC01B44427C7. If you trusted rjh at sixdemonbag.org as identified by certificate 23806BE5D6B98E10, you would probably also be fairly safe trusting rjh at sixdemonbag.org as identified by certificate 1DCBDC01B44427C7. That's how introducer chaining works. Dual signatures exploit the fact that messages can bear more than one signature. If I want to create public trust in a new certificate (say, 1E7A94D4E87F91D5), one can publicly sign messages with both the old certificate (1DCBDC01B44427C7) and the new certificate (1E7A94D4E87F91D5). Get a few messages out there in the wild with both signatures, and people begin to get the idea maybe the same person is behind both certificates. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From ratbag at gmx.com Tue Jan 13 09:44:00 2026 From: ratbag at gmx.com (Rat Bag) Date: Tue, 13 Jan 2026 01:44:00 -0700 Subject: gpg 1.4 In-Reply-To: <87ikd7ktlz.fsf@jacob.g10code.de> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: > Note that gpg 1.4 is still available to decrypt old encrypted data. Is using gpg 1.4 on an "air-gaped" computer to generate RSA 4096 keys and encrypting files/messages to owners of such keys still considered safe? TIA, R.B. From rjh at sixdemonbag.org Tue Jan 13 12:06:25 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 Jan 2026 06:06:25 -0500 Subject: gpg 1.4 In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: > Is using gpg 1.4 on an "air-gaped" computer to generate RSA 4096 keys > and encrypting files/messages to owners of such keys still considered > safe? No idea. We're not you. We don't know your threat model, what actors you're facing, what environment you're in. GnuPG just provides tools. Knowing what to do with it, how, and why, is on you. Please don't mistake this for a sarcastic answer. It's an honest one. There is no way Werner, or anyone, can answer your question without first asking a lot of questions. That kind of individualized consultation usually costs money. I will say this: I'm unaware of any reason it would be considered unsafe. Whether it would be considered safe is an open question. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Tue Jan 13 12:37:38 2026 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 13 Jan 2026 12:37:38 +0100 Subject: gpg 1.4 In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: <20260113123738.147fc276@dorfdsl.de> On 13.01.2026 01:44 Rat Bag via Gnupg-users wrote: > Is using gpg 1.4 on an "air-gaped" computer to generate RSA 4096 keys > and encrypting files/messages to owners of such keys still considered > safe? I am not aware of any issues with that. The gnupg.org website mentions that 1.4 is legacy and will only receive important security updates. Be ware that other outdated software on your system might pose a risk. Is there a special reason not to upgrade to the current version? From ratbag at gmx.com Wed Jan 14 18:44:50 2026 From: ratbag at gmx.com (Rat Bag) Date: Wed, 14 Jan 2026 10:44:50 -0700 Subject: gpg 1.4 In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: <5e0262d5-73d8-4c7e-9a0b-f246cedd4608@gmx.com> > I will say this: I'm unaware of any reason it would be considered > unsafe. Whether it would be considered safe is an open question. My question was badly worded, it is missing some form of ceteris paribus. With that said, your answer is helpful and I thank you for it. R.B. From listorama at gmx.com Wed Jan 14 19:05:00 2026 From: listorama at gmx.com (List O'Rama) Date: Wed, 14 Jan 2026 11:05:00 -0700 Subject: gpg 1.4 In-Reply-To: <20260113123738.147fc276@dorfdsl.de> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> Message-ID: <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> > Is there a special reason not to upgrade to the current version? Using gpg 2.x on an air-gaped computer would put an unsustainable burden on my user population. Perhaps architects of software such as gnupg should pay more attention to the postulate expressed by Ben Laurie and Abe Singer in their "...Red Pill and the Blue Pill" paper: *Our position is that the general-purpose operating system is fundamentally inadequate for trusted operations. One can have a general-purpose system or a trusted system, but one cannot get both in a single package.* R.B. From rjh at sixdemonbag.org Thu Jan 15 00:22:29 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 Jan 2026 18:22:29 -0500 Subject: gpg 1.4 In-Reply-To: <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> Message-ID: <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> > Perhaps architects of software such as gnupg should pay more > attention to the postulate expressed by Ben Laurie and > Abe Singer in their "...Red Pill and the Blue Pill" paper: There are a few different responses here: * If a Google cryptographer says "hey, let's solve this hard problem by getting into the hardware business!", that's great: Google has the fab lines to do this if they want. GnuPG lacks a fab plant. You're literally trying to put the devs on a guilt trip for being a small FOSS project that doesn't have billions of dollars to throw at R&D prototypes like the Nebuchadnezzar device. This is not a good look. * For users who need trusted devices, GnuPG offers smartcard support. Buy a Yubikey or an OpenPGP card and have fun. * Google themselves are not jumping on the idea of a Nebuchadnezzar device. Why should GnuPG? * If anyone was to deploy something like this it would be Western intelligence agencies. I'm unaware of any RFPs for such a product. Maybe there is one and I don't know about it, but ... if Fort Meade isn't jumping on this and Google's not jumping on this, I'm going to ask the important question of "why aren't they?" -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Thu Jan 15 06:54:50 2026 From: mm at dorfdsl.de (Marco Moock) Date: Thu, 15 Jan 2026 06:54:50 +0100 Subject: gpg 1.4 In-Reply-To: <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> Message-ID: <20260115065450.4283a60b@dorfdsl.de> On 14.01.2026 11:05 "List O'Rama via Gnupg-users" wrote: > *Our position is that the general-purpose operating system is > fundamentally inadequate for trusted operations. One can have > a general-purpose system or a trusted system, but one cannot > get both in a single package.* Please let us know why gpg2 is a problem on an air-gaped system and why gpg1 isn't. Trust comes by verifying what code runs on the machines, not by setting it up and not updating it. -- kind regards Marco Send spam to abfall1768385100 at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 870 bytes Desc: Digitale Signatur von OpenPGP URL: From jb-gnumlists at wisemo.com Thu Jan 15 07:10:27 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Thu, 15 Jan 2026 07:10:27 +0100 Subject: gpg 1.4 In-Reply-To: <20260115065450.4283a60b@dorfdsl.de> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <20260115065450.4283a60b@dorfdsl.de> Message-ID: On 15/01/2026 06:54, Marco Moock via Gnupg-users wrote: > On 14.01.2026 11:05 "List O'Rama via Gnupg-users" > wrote: > >> *Our position is that the general-purpose operating system is >> fundamentally inadequate for trusted operations. One can have >> a general-purpose system or a trusted system, but one cannot >> get both in a single package.* > Please let us know why gpg2 is a problem on an air-gaped system and why > gpg1 isn't. > > Trust comes by verifying what code runs on the machines, not by setting > it up and not updating it. > I don't know what List O'Rama is thinking of, but gnupg 2.x is clearly and obviously bloated, with even the most basic operation invoking multiple extra executables, some of which want to continue running in the background. Similarly the output is neither suited for humans nor machines to reliably parse, often outputting phrases that don't apply to the action taken or its result, leading to such abomitations as the status-fd socket. In contrast, gnupg 1.x was a single executable that did the requested operation within the confines of a single run of a single process except where needed for potentially dangerous tasks such as JPEG decompression of untrusted data and/or talking to graphical display systems. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From xwindows at xwindows.in.th Thu Jan 15 12:19:37 2026 From: xwindows at xwindows.in.th (Nutchanon Wetchasit) Date: Thu, 15 Jan 2026 18:19:37 +0700 Subject: gpg 1.4; yes if you configured it correctly In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: On Tue, 13 Jan 2026 15:44, Rat Bag via Gnupg-users wrote: > Is using gpg 1.4 on an "air-gaped" computer to generate RSA 4096 keys > and encrypting files/messages to owners of such keys still considered > safe? I'm specifically using GPG 1.4 [1] and I have recently instructed someone with vintage system (Windows XP) to install GPG 1.4 because software he uses doesn't work with newer GPG series; so I have some pointers to give. > encrypting files/messages to owners of such keys still considered safe? Bar secret zero-day exploits we didn't know of, using that setup to sign/verify/encrypt/decrypt stuff are generally okay. Software do not rot like milk and meat do; old software means it's time-tested, and timeless software that work through ages are good software. In my eyes, ideal version of software is the version that is good enough for me to continue using it for the rest of my life. Also, old software means it was authored based on system requirements of the past (not just CPU, RAM, and storage requirement; but also compatibility with data format/ABI/API of older software/OS from that era too). If you have vintage systems, air-gapped or not, using old era-appropriate software is going to matter in a lot of cases-- as long as such software and version could still do what you need it to do. And when GPG got ported to "ancient" systems like, say, DOS/DJGPP; GPG 1.x is going to be the one that could get ported, not 2.x. [2] > to generate RSA 4096 keys This specific part is where few pitfalls exists and you have to watch out for. (For the record: these don't affect migrated keys generated from GPG 2.x setups that were imported to GPG 1.4) These could easily be worked around of course, but you need to know that these pitfalls exist first, in order to apply such workarounds... 8<----- First pitfall is the issue of keypair/user-ID binding certificate signature's hash algorithm. When you make GPG generate a keypair, it doesn't just calculate private and public key for you; it also do one self-signature on the key content, and another one which binds your user ID (name+email) declaration to the keypair... The problem being: GPG 1.4 was released in the days and age when SHA-1 hash algorithm was still considered cryptographically-secure (marginally secure, but nonetheless still secure back then), so it will sign on SHA-1 hash to certify your newly-generated key and its attached user ID _by default_. And as you already know, you really don't want it to do that in 2026. [4] Mr. Koch had also kindly hinted to me (in [3]) that current GPG 2.x also rejects SHA-1 hash-based binding signature it sees in any key created after 19-Jan-2019. Note: This issue is not readily-apparent to users because this binding signature information is not shown in `gpg --list-keys` nor `gpg --edit-key` interface; and could only be seen when you do `gpg --list-packets` on the exported key file. [5] Indeed, GPG 1.4 *can* generate key with self-signature + user ID certified via other hash algorithms that are still considered secure today, including SHA-256 and above; but you will have to explicitly configure it to do so. (And since you're going to use 4096-bit RSA already, you might want to go use SHA-512 hash for this; just in case) ^ But the important part that you have to keep in mind is: you *MUST* configure it so *BEFORE* generating a key with such setup. Else, you would end up in quite a predicament indeed. [6] You can configure GPG 1.4 to use SHA-512 hash in key/user-ID binding signatures, by adding the following line to your `~/.gnupg/gpg.conf` file: cert-digest-algo SHA512 But don't generate your key right after you added this yet, because... 8<----- The second pitfall is default personal cryptographic algorithm priority list that GPG 1.4 assigns by default to your newly-generated keypair. Again, the list back in the days was not ideal in 2026 for obvious reasons. ^ This pitfall is not so severe as the first one, because you can always correct it after the fact via regular `gpg --edit-key`. You can configure GPG 1.4 to use a priority list that is as close as possible to the one that current GPG 2.x gives to a new RSA-4096 key, by adding the following line to your `~/.gnupg/gpg.conf` file: default-preference-list AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP Uncompressed MDC no-ks-modify ^ Side note that when you used `showpref` in `gpg --edit-key` interface on a keypair generated _after_ this configuration change, you would still see "3DES" appearing in Cipher line as well as "SHA1" in Digest line; but as the *last* item. They are there because the relevant standard (thus interoperability consideration) require these two to be _implicitly_ included (thus on-display); [8] but they will not actually be used because: A. Virtually every implementations out there implement better algorithms which will be picked first in face of a good in-key priority list like this. B. The actual preferences list published in the public key generated under this configuration would actually *not* include the SHA-1 hash algorithm. (See the explanation of second dump output of [5]) Now that you know how, go configure it, make keys (maybe also verify by exporting and dumping too [5]), then cipher away; and cheers for old computers everyday. Regards, Nutchanon Wetchasit GnuPG: 1.4.12 (Debian) System: Debian GNU/Linux 7.0 "Wheezy" i386 ----- [1] Because A. I use vintage system (I couldn't get current GPG 2.x to compile on my system; will get on to report/ask about that later) and B. I have some use for GPG (symmetric mode) in low-trust environment where it _must_ run *without* using agent or `~/.gnupg` directory whatsoever (not even a temporary one)-- which GPG 2.x will definitely not do. [2] GPG 2.x would not work on DOS anyhow, because it needs a second agent process (and a third... keystore daemon?) to be running simultaneously; which is simply not possible under DOS. As you already know, DOS is a single-tasking system. And regarding GPG 1.x on DOS: yes, DOS/DJGPP port of GPG 1.4.23 exists. https://archive.org/details/gnupg-1.4.23-for-dos https://sourceforge.net/p/freedos/news/2024/05/gnupg-1423-for-dos/ As one of the people who have DOS in boot menu in 2026, this is not of a mere novelty value. [3] https://lists.gnupg.org/pipermail/gnupg-users/2024-November/067404.html as a follow-up of: https://lists.gnupg.org/pipermail/gnupg-users/2024-November/067403.html [4] https://sha-mbles.github.io/ [5] For example, this is an output of `gpg --list-packet` of a dummy public key *affected* by this SHA-1 binding signature issue: > $ gpg --list-packets joe.asc > :public key packet: > version 4, algo 1, created 1768466208, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > :user ID packet: "Joe Sixpack " > :signature packet: algo 1, keyid 41D386A2806A8257 > version 4, created 1768466208, md5len 0, sigclass 0x13 > digest algo 2, begin of digest 94 68 > hashed subpkt 2 len 4 (sig created 2026-01-15) > hashed subpkt 27 len 1 (key flags: 03) > hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) > hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) > hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) > hashed subpkt 30 len 1 (features: 01) > hashed subpkt 23 len 1 (key server preferences: 80) > subpkt 16 len 8 (issuer key ID 41D386A2806A8257) > data: [4095 bits] > :public sub key packet: > version 4, algo 1, created 1768466208, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > :signature packet: algo 1, keyid 41D386A2806A8257 > version 4, created 1768466208, md5len 0, sigclass 0x18 > digest algo 2, begin of digest 9b 63 > hashed subpkt 2 len 4 (sig created 2026-01-15) > hashed subpkt 27 len 1 (key flags: 0C) > subpkt 16 len 8 (issuer key ID 41D386A2806A8257) > data: [4096 bits] You would see that there are 2 signature packets (first for signing user ID right above it, second for self-signing the public key right above it). At the right of each ":signature packet:", you'd see "algo 1" which is fine (1=RSA signature); but the second under such section, you would also see "digest algo 2"-- which is *NOT* okay (2=signed on SHA-1 hash value). A 4096-bit RSA key which is generated by GPG 1.4 _after_ applying configuration changes I suggested, would look like the following instead... > $ gpg --list-packets rod.asc > :public key packet: > version 4, algo 1, created 1768468694, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > :user ID packet: "Rodney Retro " > :signature packet: algo 1, keyid 27B25A464AF65994 > version 4, created 1768468694, md5len 0, sigclass 0x13 > digest algo 10, begin of digest 2c 0b > hashed subpkt 2 len 4 (sig created 2026-01-15) > hashed subpkt 27 len 1 (key flags: 03) > hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) > hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) > hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0) > hashed subpkt 30 len 1 (features: 01) > hashed subpkt 23 len 1 (key server preferences: 80) > subpkt 16 len 8 (issuer key ID 27B25A464AF65994) > data: [4095 bits] > :public sub key packet: > version 4, algo 1, created 1768468694, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > :signature packet: algo 1, keyid 27B25A464AF65994 > version 4, created 1768468694, md5len 0, sigclass 0x18 > digest algo 10, begin of digest 43 5b > hashed subpkt 2 len 4 (sig created 2026-01-15) > hashed subpkt 27 len 1 (key flags: 0C) > subpkt 16 len 8 (issuer key ID 27B25A464AF65994) > data: [4095 bits] You would now see that in this case, second line inside each ":signature packet:" section have "digest algo 10" (10=signed on SHA-512 hash value) which are now good for 2026+ uses. Sharp-eyed readers would also notice that on the "pref-hash-algos" line, number "2" (2=SHA-1 hash algorithm) is also now gone; though on the "pref-sym-algos" line, number "2" (3=Triple-DES cipher) still remains as the _least_-preferred cipher. See second link on footnote [8] if you're curious about which number represented which algorithm under each category. [6] If you _already_ created the key without aforementioned configuration entry, you cannot fix such affected keypair under GPG 1.4 unfortunately. The GPG 2.x's trick of changing key expiration date which I heard from out there (and Mr. Koch also re-mentioned to me in [3]) doesn't work under GPG 1.4: I've tested, it will simply re-sign with the same algorithm already used in that part. Adding new user ID followed by deleting old user ID there would only fix the signature binding the user ID, but not the self-signature on the key content. The recourses you have in that scenario for now are either generating a new keypair under correct GPG 1.4 configuration; or exporting that (still-encrypted) private+public keypair using `gpg --export-secret-key` and bring it to GPG 2.x setup, apply 2.x's expiry date change workaround, export the fixed keypair out (using `gpg --export-secret-key` again), remove original private+public keypair from GPG 1.4 setup [7], then import the fixed private+public keypair back onto it. I aim to post a patch (or at least, a formal report) on this mailing list once I could pinpoint where in GPG 1.4 source code I could change in order to make such solution work under this version. [7] If you didn't remove the original keypair, GPG 1.4 will just skip importing your fixed one and issue "gpg: key SHORTKEYID: already in secret keyring" warning instead. [8] https://dev.gnupg.org/T5020 ( https://web.archive.org/web/20251008192708/https://dev.gnupg.org/T5020 ) https://www.rfc-editor.org/rfc/rfc4880.html#section-9 From andrewg at andrewg.com Thu Jan 15 15:19:40 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Jan 2026 14:19:40 +0000 Subject: gpg 1.4; yes if you configured it correctly In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: On 15/01/2026 11:19, Nutchanon Wetchasit via Gnupg-users wrote: > > I'm specifically using GPG 1.4 [1] and I have recently instructed someone > with vintage system (Windows XP) to install GPG 1.4 because software > he uses doesn't work with newer GPG series; so I have some pointers to give. If that Windows XP machine is connected to the internet, running gnupg on it is pure security theatre. You should assume that it is pwned already, that any secret keys are leaked, and that it's part of at least one botnet. > Software do not rot like milk and meat do; old software means it's > time-tested, and timeless software that work through ages are good software. Software does not need to rot, because it is already broken. All code of any nontrivial complexity is broken in some way - the only variables are a) how exactly it is broken and b) who finds out first, you or the bad guys. If you don't upgrade your software regularly, the likelihood that an attacker knows a security vulnerability that you have not fixed approaches 1 *very fast*, and anything connected to the internet will be subject to multiple hacking attempts *per minute* by multiple attackers in parallel. Even an airgapped system can't fully protect you if you're copying untrusted files across the gap and using outdated security software to check them. > In my eyes, ideal version of software is the version that is good enough > for me to continue using it for the rest of my life. I understand your frustration, because many software vendors don't offer bugfix support for older versions and force you through painful UX changes and compatibility breaks just to get security fixes. But it is also unreasonable to ask software vendors to support every old version of their code in perpetuity. You *must* upgrade your software, no matter how painful it is. > GnuPG: 1.4.12 (Debian) > System: Debian GNU/Linux 7.0 "Wheezy" i386 You connected a Wheezy machine to the internet as well? Please, *please* upgrade your OS right now. Ten years out-of-date operating systems are *not secure*. Until you're running a fully-patched system, any discussion of cryptography is a waste of your time. A From rjh at sixdemonbag.org Thu Jan 15 15:43:41 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 Jan 2026 09:43:41 -0500 Subject: gpg 1.4; yes if you configured it correctly In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: <671cdac2-758d-4f65-b6ef-d2c9e8142a55@sixdemonbag.org> > I'm specifically using GPG 1.4 [1] and I have recently instructed someone > with vintage system (Windows XP) to install GPG 1.4 because software > he uses doesn't work with newer GPG series; so I have some pointers to give. I would be hard pressed to find any legitimate purpose for WinXP today. I wouldn't even want to use it in an airgapped environment. > Software do not rot like milk and meat do; old software means it's > time-tested, and timeless software that work through ages are good software. Yes... and no. Mostly 'no'. Look, I'm a big fan of ancient COBOL code that's thunking along on Big Iron that three people in the world still understand, and they're paid well to sit around in case someone reports the first bug in thirty years. That stuff makes me happy. But you need to look at the environment in which that software exists: it has almost nothing in common with the every day consumer software experience. In the consumer software world, software *absolutely* rots. Today's "I want to punch someone in the face really hard" moment came courtesy of discovering some ancient Java code relied on an internal API that the latest JVM long-term release has now closed off. It isn't that software rots, per se: it's that the environment in which software operates undergoes constant Lamarckian evolution. William Gibson once described it as being like an evolutionary experiment where the researcher kept a thumb mashed down on the fast forward button -- a very good metaphor. Also, no, old software doesn't mean it's time-tested. If you think that's true I have some code I wrote when I was an undergrad that you should see. Old software is time-tested *only if there is intense ongoing use and an accompanying investment in software lifecycle maintenance*, and those two conditions amount to a really big if. GnuPG 1.4 is not seeing intense ongoing use, and there's almost no investment in ongoing maintenance. > The problem being: GPG 1.4 was released in the days and age when SHA-1 > hash algorithm was still considered cryptographically-secure > (marginally secure, but nonetheless still secure back then), SHA-1 was the Rock of Gibraltar for twenty years. It was never "marginally secure". -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jan 15 16:35:37 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Jan 2026 16:35:37 +0100 Subject: gpg 1.4 In-Reply-To: (Jakob Bohm via Gnupg-users's message of "Thu, 15 Jan 2026 07:10:27 +0100") References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <20260115065450.4283a60b@dorfdsl.de> Message-ID: <87v7h27ut2.fsf@jacob.g10code.de> On Thu, 15 Jan 2026 07:10, Jakob Bohm said: > I don't know what List O'Rama is thinking of, but gnupg 2.x is clearly and > obviously bloated, with even the most basic operation invoking multiple extra In case you consider support for CMS/X.509 (aka S/MIME), ssh-agent, and several more smartcard types, bloat that this is correct. For everyone else these are new features beyond PGP support. Nobody needs to use them and the architecture does not increase the attack surface. In fact, the modularization improves the security and allows to share matured code for other purposes. Using a separate and crypto library (Libgcrypt) actually decreases the code size and improves code and audit sharing. Libgcrypt is more widely used and audited than gpg1 ever was. > Similarly the output is neither suited for humans nor machines to reliably > parse, often outputting phrases that don't apply to the action taken or its Well, gpg-1 uses exactly the same output (machine and human interface). We might have lost a few translations; that's right. > In contrast, gnupg 1.x was a single executable that did the requested > operation within the confines of a single run of a single process except And does not utilize the process barrier to avoid potential leaking of private key material due to minor coding errors. > where needed for potentially dangerous tasks such as JPEG decompression of > untrusted data and/or talking to graphical display systems. And gpg-2 delegates sensible task like private key operations to a dedicated process. 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: 284 bytes Desc: not available URL: From wk at gnupg.org Fri Jan 16 11:10:40 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Jan 2026 11:10:40 +0100 Subject: Inquiry regarding official GnuPG recommendation for Android In-Reply-To: <8a4c714f-922b-4a40-9bbb-04482ef0bdf0@gmail.com> (=?utf-8?B?IumZs+W9peS9kA==?= via Gnupg-users"'s message of "Wed, 7 Jan 2026 02:43:48 +0800") References: <8a4c714f-922b-4a40-9bbb-04482ef0bdf0@gmail.com> Message-ID: <87ikd17tr3.fsf@jacob.g10code.de> On Wed, 7 Jan 2026 02:43, ??? said: > I noticed that gnupg.org currently references the Guardian Project for > Android support. However, the Guardian Project's official page states We list all kind of GnuPG related projects but we can' checkwhether one is still maintained. If one of the former maintainers wants us to remove a link we will of course do that. > officially supported or recommended GnuPG application for Android? I > am specifically looking for a maintained solution that is available on > F-Droid. I am using OpenKeychain with Conversations 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: 284 bytes Desc: not available URL: From wk at gnupg.org Fri Jan 16 11:19:05 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Jan 2026 11:19:05 +0100 Subject: Securing multiple keys with one smart card In-Reply-To: (Bow via Gnupg-users's message of "Tue, 6 Jan 2026 13:40:50 -0800") References: <87pl7nnpro.fsf@jacob.g10code.de> Message-ID: <87ecnp7td2.fsf@jacob.g10code.de> On Tue, 6 Jan 2026 13:40, Bow said: > My goal is have my private key material protected by more than just > a usable (that is, a long but not very long) password. Ideally with Well you can use g13 to mount your ~/.gnupg from a small encrypted partition and that allows the use of a smartcard. I am using this for a decade to encrypt parts of my disk. It is a bit tricky because you need some symlinking for the non-encrypted ~/.gnupg. > It is my understanding that GnuPG only supports OpenPGP Card smart > cards. Is there another card type that would work? Sure. We support all kinds of cards. But for creating keys on a card you petter use either the OpenPGP-card or the PIV application (e.g. with a Yubikey). PIV is not that easy to setup as the OpenPGP card but it works. Another option is to use card which already come with keys - there is a multitude of them, CardOS, TCOS, PKCS#15 cards, and so on. For some of them you can also use Open Source software to create keys. 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: 284 bytes Desc: not available URL: From soyeomul at doraji.xyz Fri Jan 16 12:03:56 2026 From: soyeomul at doraji.xyz (Byunghee HWANG (Gmailify)) Date: Fri, 16 Jan 2026 20:03:56 +0900 Subject: verifying gpg signature under opendkim-lua script In-Reply-To: (Robert J. Hansen via Gnupg-users's message of "Thu, 8 Jan 2026 02:01:56 -0500") References: <87ms2qkqh6.fsf@thinkpad-e495.home.arpa> <2039212a-074a-44b6-826e-69423386132e@sixdemonbag.org> <87bjj4pqql.fsf@thinkpad-e495.home.arpa> Message-ID: <874iollsyr.fsf@thinkpad-e495.home.arpa> "Robert J. Hansen via Gnupg-users" writes: >> My ultimate goal is to route emails using gpg's fingerprinting. This is >> the first step toward that goal. That is all. > > Lua doesn't have GPGME bindings, so you'll likely have to do this the > error-prone way: fire up GnuPG and verify the signature, after hooking > up --status-fd to a file descriptor of your choice. _Do not_ parse the > normal console output: only the status-fd output should be used. > > When verifying a message with gpg --verify, you'll see a message > stanza like: > > [GNUPG:] KEY_CONSIDERED CC11BE7CBBED77B120F37B011DCBDC01B44427C7 0 > [GNUPG:] SIG_ID qtBYYa4lfH60IDd2oOz06S6QBjc 2026-01-08 1767855159 > [GNUPG:] GOODSIG 1DCBDC01B44427C7 Robert J. Hansen > > The first, KEY_CONSIDERED, gives you the full fingerprint. If you then > see GOODSIG the message has passed its signature verification and then > you can have Lua do what you want with the message. Hellow Robert, Sorry for the late reply. After trying for a while to implement GPG-fingerprint in Postfix, i finally succeeded [1]. My next challenge is to build a DKIM signing strategy using OpenDKIM based on these results. Please give my regards to Werner instead. I've been reading his additional letters in depth and working on them. Stay healthy always. Thank you so much! INDEED... Sincerely, Byunghee [1] https://gitlab.com/soyeomul/Gnus/-/raw/8c24b7fa93c608203b86c6069a7fd18051b72cf3/TSG/filter/result.txt -- ^????? _????_ ?????_^))// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jb-gnumlists at wisemo.com Fri Jan 16 12:43:59 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Fri, 16 Jan 2026 12:43:59 +0100 Subject: Securing multiple keys with one smart card In-Reply-To: <87pl7nnpro.fsf@jacob.g10code.de> References: <87pl7nnpro.fsf@jacob.g10code.de> Message-ID: <29e58e5e-8b54-106c-6ade-7c5bcbed69f6@wisemo.com> On 06/01/2026 08:50, Werner Koch via Gnupg-users wrote: > Hi! > >> Is there a known way to encrypt multiple/all private keys in the >> keyring with a single smart card? > Do you mean to replace the passphrase by some kind of encryption using a > smartcard? This is not possible but it may be worth to discuss such an > option. > >> Using one card per identity is cost and convenience prohibitive. > In theory you can create several *PGP keys with the same physical key > on the smartcard. But there are some problems. It is better to use > smartcard which allows to store/create several keys and not just the 3 > keys we specified for the OpenPGP card. An updated specification of the > OpenPGP card will support more keys. > > The drawback of this all is that smartcards may build up a defect and you > would loose access to all your private keys.q > > > Shalom-Salam, > > Werner > > One portable solution that might be put into a future gpg 2.x version would be to allow encrypting the locally stored private keys using a private mail encryption (not signing) key on any otherwise supported card. For example, if some OpenPGP cards support storing the private mail decryption key on the card, then this (future) feature could use that key to decrypt further keys stored locally in the .gnupg directory. A special consideration for such a new encryption format would be to allow multiple ways to decrypt one private key file portion, such as OpenPGP card 1, OpenPGP card 2(spare), extra secret backup password (stored in a never opened envelope in an armoured safe). Each of those methods would decrypt a separately encrypted file-portion encryption key, changing that key would encrypt the new key to the public keys of each authorized card AND the backup password (or an intermediary private key encrypted with the password to keep the envelope sealed). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From ratbag at gmx.com Fri Jan 16 21:58:37 2026 From: ratbag at gmx.com (Rat Bag) Date: Fri, 16 Jan 2026 13:58:37 -0700 Subject: gpg 1.4 In-Reply-To: <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> Message-ID: <51597c57-2b83-4008-8677-097983b9c327@gmx.com> > Google cryptographer says "hey, let's solve this hard problem by > getting into the hardware business!", that's great: Google has the fab > lines to do this if they want. The important (in current context) part of Laurie-Singer paper was quoted in my message; and I propose their diagnosis is 100% correct. Their proposed cure is besides the point; the population of users we are considering can pick up devices that will run 1.4 air-gaped and do everything they need to do from any consumer electronics recycling bin. R.B. From rjh at sixdemonbag.org Fri Jan 16 23:47:43 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 Jan 2026 17:47:43 -0500 Subject: gpg 1.4 In-Reply-To: <51597c57-2b83-4008-8677-097983b9c327@gmx.com> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> Message-ID: <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> > Their proposed cure is besides the point; the > population of users we are considering can pick up devices > that will run 1.4 air-gaped and do everything they need > to do from any consumer electronics recycling bin. Which segment of users are these? That's not a sarcastic question. It's a sincere one. I spent almost twenty years working on Enigmail, in order to persuade Mozilla to incorporate OpenPGP support into Thunderbird. (We ultimately succeeded, which is why we're no more.) During those twenty years, the hardest and most surprising lesson we learned was that we had absolutely no idea who our users were. We had message boards, forums, an email help team, you could even report bugs right from the GUI. By keeping track of the forums and mailing lists and everything else we thought we had a good view on what our users wanted. Then I attended Circumvention (aka Internet Freedom Fest #0; they renamed it to IFF the next year) and actually met the people who were using Enigmail in the field. They weren't on our forums, didn't get involved in our mailing lists. They just wanted things to work and didn't want to waste time tweaking configuration files. These people had a much different vision of what Enigmail should be and could be. We ultimately decided to pivot a bit to (a) go out into the field to find our users, and (b) weigh what our real users wanted more than what the forum-posting users wanted. It made a huge difference in our priorities, and I'm convinced it's a large part of the reason why just a few years after making this pivot Mozilla decided we were right and OpenPGP should be supported natively. I understand you represent a certain fraction of the userbase. There's nothing wrong with being in that fraction. However, I think you are probably massively overestimating how big your fraction is, or the degree to which your fraction's desires should be guiding GnuPG development. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Jan 17 01:46:36 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 Jan 2026 19:46:36 -0500 Subject: gpg 1.4 In-Reply-To: <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: <1a037240-47e8-4694-a34c-64596f072444@sixdemonbag.org> > Which segment of users are these? > > That's not a sarcastic question. It's a sincere one. Ironically, I ran across a commentator today who had a paragraph almost precisely on point here. (Anyone trying to infer my own politics from the fact I'm citing Jonah Goldberg is, of course, living in sin. I read from across the political spectrum.) "One of the foundational insights of Mancur Olson, the legendary economist, is the problem of concentrated benefits and diffuse costs. Take sugar subsidies. They make sugar slightly more expensive for everybody, costing the country writ large billions, but the subsidies reap huge profits for a handful of domestic sugar producers. So every time someone suggests getting rid of them, the tiny number of Big Sugar barons starts writing checks to politicians and starts screaming about the dangers of not having a domestic supply of sugar in wartime. This dynamic is a feature of all politics. The people who care, for whatever reason, have more influence than those who don?t." Likewise, FOSS needs to be careful not to let the people who speak the loudest on mailing lists drive feature development. We really need to go out to where the users are, meet them in their own places and environments, and find out what's most useful to them. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From ratbag at gmx.com Sat Jan 17 09:30:52 2026 From: ratbag at gmx.com (Rat Bag) Date: Sat, 17 Jan 2026 01:30:52 -0700 Subject: Gpg 1.4 Renato In-Reply-To: <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: > Which segment of users are these? ... > ... surprising lesson we learned was that we had absolutely > no idea who our users were. When it comes to communication security software, there is a built-in shortcut: start not by thinking who the users are, but instead who their adversaries are. That point of departure in Laurie-Singer paper is valid on two counts: the client can be subverted accidentally - by malware or bug in a hundreds of OS components and/or applications that populate what they call "general-purpose system", or it can be actively subverted by the adversary that can buy, convince or coerce the cooperation of the operating system vendor that continuously manipulates the platform under user's posterior in completely non-transparent manner. Both authors of that paper - and the users facing such adversaries (let's call them "Southern intelligence agencies" to avoid bringing our possible geographical biases into applied cryptography discussion) - see the solution in clear-text *and* crypto-operations resident only on an air-gaped device. > ...nothing wrong with being in that fraction. However, I think you are > probably massively overestimating how big your fraction is, or the more: > degree to which your fraction's desires should be guiding GnuPG development. I believe that fraction to be greater than you do, and, more importantly, I believe it is growing. But regardless of their numbers, your criticism would be valid if they were asking for *more*: i.e., features and code additional to what the product currently provides. But quite the opposite is the case: they are asking for *less*; the most important quality of that "less" would be the ability to accommodate the MO Laurie and Singer suggested decades ago. And not using their elaborate Nabucodonosor, but a perfectly adequate (for their purpose) substitute: an Asus Eee PC pulled out of the electronic recycle bin. R.B. From rjh at sixdemonbag.org Sat Jan 17 18:42:02 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 17 Jan 2026 12:42:02 -0500 Subject: Gpg 1.4 Renato In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: > When it comes to communication security software, there > is a built-in shortcut: start not by thinking who the > users are, but instead who their adversaries are. Absolutely not. There exists no set of adversaries common to all users. > Both authors of that paper - and the users facing such > adversaries (let's call them "Southern intelligence agencies" > to avoid bringing our possible geographical biases into > applied cryptography discussion) I'm trying to figure out whether you're making a very subtle joke, or trying to be enlightened. I'm going to assume it's a subtle joke, because it's actually given me a brief smile, so. Thank you. The week my country has been having, I needed that. (For Europeans: historically, the "American South" has included the State of Maryland, the Commonwealth of Virginia, and the District of Columbia. NSA is headquartered at Fort Meade in Maryland; CIA is headquartered in McLean, Virginia; and FBI is headquartered at the Hoover building in DC. All the major U.S. intelligence agencies are located in the American South, hence my scratching my head and wondering if RB was making a joke there.) > I believe that fraction to be greater than you do, and, more > importantly, I believe it is growing. But regardless of their > numbers, your criticism would be valid if they were asking for > *more*: i.e., features and code additional to what the product > currently provides. But quite the opposite is the case: they > are asking for *less* That's not how software development works. This would be a major change to GnuPG. Someone has to do the work. Hence, 'more'. GnuPG 1.4 is on life support, *at best*. That is not going to change. > suggested decades ago. And not using their elaborate Nabucodonosor, > but a perfectly adequate (for their purpose) substitute: an > Asus Eee PC pulled out of the electronic recycle bin. Get a YubiKey. Congratulations, your crypto operations are now done in specialized hardware and isolated from the network at large _and_ you get to continue using GnuPG 2.6. What's not to love? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From ratbag at gmx.com Sat Jan 17 22:01:20 2026 From: ratbag at gmx.com (Rat Bag) Date: Sat, 17 Jan 2026 14:01:20 -0700 Subject: Gpg 1.4 Renato In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: > There exists no set of adversaries common to all users. Of course not. But there is a sub-sets of users that do share *a "class" of adversaries*, one that was - for whatever reason - historically not considered possible or practical or proper to protect the users of GnuPG from. The way I read Laurie-Singer paper, protection from such adversaries was impossible on a "general purpose system". Nobody (and I suspect authors themselves) seriously considered building the device that they proposed as a solution. But for a *subset of users*, needing only a *subset of functionality*, such devices are available, in quantity and at (practically) no cost. All that is missing is "1.4 Renato". The work required to exorcise the 2.x gumbo of (to them) useless features and cut down WOT flotsam to size is not at all extraordinary. And no, I am not (as was suggested above) "literally trying to put the devs on a guilt trip..."; (if this is how I came across, I apologize unreservedly). I am just politely asking, and suggesting a *growing* set of users would benefit. It would be entirely possible to take 1.4 codebase, clean up a few things, backport some (very few) fundamentals and Gpg 1.4 would leave the life-support and be, indeed, "re-born". When a mailing list sub-thread dwindles down to two participants, it is high time to consider the patience of the wider list membership... R.B. From roam at ringlet.net Sun Jan 18 13:50:51 2026 From: roam at ringlet.net (Peter Pentchev) Date: Sun, 18 Jan 2026 14:50:51 +0200 Subject: Gpg 1.4 Renato In-Reply-To: References: <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: On Sat, Jan 17, 2026 at 02:01:20PM -0700, Rat Bag via Gnupg-users wrote: [snip] > All that is missing is "1.4 Renato". The work required to > exorcise the 2.x gumbo of (to them) useless features and > cut down WOT flotsam to size is not at all extraordinary. > And no, I am not (as was suggested above) "literally trying > to put the devs on a guilt trip..."; (if this is how I came > across, I apologize unreservedly). I am just politely asking, > and suggesting a *growing* set of users would benefit. It > would be entirely possible to take 1.4 codebase, clean up a > few things, backport some (very few) fundamentals and Gpg 1.4 > would leave the life-support and be, indeed, "re-born". You do realize that after a complete redesign of the way the program works (and, yeah, also splitting out parts of its functionality into different processes), and a complete redesign of the way the program keeps its data structures in memory, and a complete redesign of the way the program stores its data structures on disk... ...so after all of that, there is no "backporting a feature", but there is "writing new code in the old codebase that is, to some extent, inspired by the way the same feature was implemented in the new codebase", so pretty much "implementing a new feature in the old codebase"? G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rjh at sixdemonbag.org Sun Jan 18 16:31:18 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 18 Jan 2026 10:31:18 -0500 Subject: Gpg 1.4 Renato In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: <8de0fa39-f015-4355-82a6-98e5507506be@sixdemonbag.org> > Of course not. But there is a sub-sets of users that do > share *a "class" of adversaries*, one that was - for > whatever reason - historically not considered possible > or practical or proper to protect the users of GnuPG from. If your defense of this notion is to make a sweeping generality, then retreat to a special case, then retreat further to a more-special case, then I'm going to just stop here. > solution. But for a *subset of users*, needing only a > *subset of functionality*, such devices are available, > in quantity and at (practically) no cost. And they are called Yubikeys. Get one. > All that is missing is "1.4 Renato". "All that's missing is..." is the software engineering equivalent of loudly screaming profanities in church during the middle of Mass. It's just not done. > The work required to > exorcise the 2.x gumbo of (to them) useless features and > cut down WOT flotsam to size is not at all extraordinary. That's an extraordinary claim and requires extraordinary evidence. > across, I apologize unreservedly). I am just politely asking, > and suggesting a *growing* set of users would benefit. Until such time as you go out into the field and *find these users*, they don't exist and their niche need will not influence development. And that's as it should be. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Mon Jan 19 02:01:30 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 18 Jan 2026 19:01:30 -0600 Subject: Gpg 1.4 Renato In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> Message-ID: <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> On 1/17/26 15:01, Rat Bag via Gnupg-users wrote: > [...] > > The way I read Laurie-Singer paper, protection from such > adversaries was impossible on a "general purpose system". > Nobody (and I suspect authors themselves) seriously > considered building the device that they proposed as a > solution. But for a *subset of users*, needing only a > *subset of functionality*, such devices are available, > in quantity and at (practically) no cost. > > [...] What prevents simply running GPG 2.x on an Eee PC or other recycled low-spec hardware? Yes, 2.x has higher system complexity, but why is that system complexity unsuitable, especially on a machine running GNU/Linux, where (for example) the entire $GNUPGHOME tree could be stored in a RAM filesystem (and thus erased upon shutdown) or in a LUKS volume (and thus encrypted at rest)? -- Jacob From rjh at sixdemonbag.org Mon Jan 19 02:07:09 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 18 Jan 2026 20:07:09 -0500 Subject: Gpg 1.4 Renato In-Reply-To: <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> Message-ID: <21df143d-5747-4c5e-aa5e-4ec69e174a5e@sixdemonbag.org> > What prevents simply running GPG 2.x on an Eee PC or other recycled low- > spec hardware? IIRC, he's supporting a WinXP user whose workflow has pieces that only work with GnuPG 1.4. I'm speculating that something like GPGtray might be in use. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Jan 19 02:10:47 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 18 Jan 2026 20:10:47 -0500 Subject: Gpg 1.4 Renato In-Reply-To: <21df143d-5747-4c5e-aa5e-4ec69e174a5e@sixdemonbag.org> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> <21df143d-5747-4c5e-aa5e-4ec69e174a5e@sixdemonbag.org> Message-ID: <29d2aa0e-7140-4221-928f-3418939bc36e@sixdemonbag.org> > work with GnuPG 1.4. I'm speculating that something like GPGtray might s/GPGtray/WinPT/ Sorry, my braino. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Mon Jan 19 03:27:14 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 18 Jan 2026 20:27:14 -0600 Subject: Gpg 1.4 Renato In-Reply-To: <21df143d-5747-4c5e-aa5e-4ec69e174a5e@sixdemonbag.org> References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> <21df143d-5747-4c5e-aa5e-4ec69e174a5e@sixdemonbag.org> Message-ID: <1c6b9289-39d7-4424-a8a6-6620b381f1f2@gmail.com> On 1/18/26 19:07, Robert J. Hansen via Gnupg-users wrote: >> What prevents simply running GPG 2.x on an Eee PC or other recycled >> low- spec hardware? > > IIRC, he's supporting a WinXP user whose workflow has pieces that only > work with GnuPG 1.4. I'm speculating that something like > [GPGtray/WinPT] might be in use. If that is the case, said user needs to migrate operating systems post haste. Windows has *never* really been secure; even an air-gapped Windows box is questionable without extensive procedures to validate/sanitize the data in/out.? (Remember Stuxnet, anyone?? It actually targeted XP, if I recall correctly.) A user able to manage the precautions needed to make (even an air-gapped) Windows box vaguely secure is certainly able to dispense with that complexity and use GNU/Linux. There is a subset of GPG 1.4 functionality (RSA-4096, for one example) that is still secure today, but GPG 2.x also has that functionality.? There is no good reason to use GPG 1.4 for current traffic. -- Jacob From dl at pbstu.com Mon Jan 19 05:46:57 2026 From: dl at pbstu.com (Sakuya) Date: Mon, 19 Jan 2026 04:46:57 +0000 Subject: Request for account on dev.gnupg.org Message-ID: Dear GnuPG admins, Due to the disabled registration on dev.gnupg.org, I am writing to request a new account to report a bug. Here are my details: Handle: GeekDuanLian Shown Name: Sakuya Mail Address: dl at pbstu.com Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jan 19 17:12:59 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Jan 2026 17:12:59 +0100 Subject: Gpg 1.4 Renato In-Reply-To: <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> (Jacob Bachmeyer via Gnupg-users's message of "Sun, 18 Jan 2026 19:01:30 -0600") References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> <20260113123738.147fc276@dorfdsl.de> <4a21f2bb-e1d1-40d5-a9a3-22cfbaf03260@gmx.com> <534f44c2-67eb-4936-a0b1-e771640807a9@sixdemonbag.org> <51597c57-2b83-4008-8677-097983b9c327@gmx.com> <321f7224-0762-4450-9fc3-2df1fbaf6f41@sixdemonbag.org> <38f773da-4bd8-476b-becd-e0764652b97c@gmail.com> Message-ID: <87pl7560ok.fsf@jacob.g10code.de> On Sun, 18 Jan 2026 19:01, Jacob Bachmeyer said: > What prevents simply running GPG 2.x on an Eee PC or other recycled > low-spec hardware? FWIW, we once (in 2010) made GnuPG 2 available for WindowsCE 5 - That is a beast of OS which allows only for 31 processes at all. And it worked well --- except for the stripped down KMail which was a bit slow. 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: 284 bytes Desc: not available URL: From ratbag at gmx.com Sun Jan 18 21:25:39 2026 From: ratbag at gmx.com (Rat Bag) Date: Sun, 18 Jan 2026 13:25:39 -0700 Subject: gpg 1.4; yes if you configured it correctly In-Reply-To: References: <5AF166B8-44DA-4142-9C28-7AD02F4CF1C7@sawczyn.com> <87ikd7ktlz.fsf@jacob.g10code.de> Message-ID: > I'm specifically using GPG 1.4 [1] and I have recently instructed someone > with vintage system... A quick thank you note for a comprehensive and very useful post. R.B. From wk at gnupg.org Tue Jan 27 17:49:42 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Jan 2026 17:49:42 +0100 Subject: [Announce] GnuPG and Gpg4win Security Advisory (T8044) Message-ID: <877bt30zmh.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.17. This version fixes a *critical security bug* in versions 2.5.13 to 2.5.16. We also released a new Gpg4win version and updated Debian packages. Impact ====== These versions are affected: - GnuPG 2.5.16 (released 2025-12-30) - GnuPG 2.5.15 (released 2025-12-29) - GnuPG 2.5.14 (released 2025-11-19) - GnuPG 2.5.13 (released 2025-10-22) - Gpg4win 5.0.0 (released 2026-01-14) - Gpg4win 5.0.0-beta479 (released 2026-01-02) - Gpg4win 5.0.0-beta476 (released 2025-12-22) - Gpg4win 5.0.0-beta395 (released 2025-10-22) All other versions are not affected. A crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack buffer overflow in gpg-agent during the PKDECRYPT--kem=CMS handling. This can easily be used for a DoS but, worse, the memory corruption can very likley also be used to mount a remote code execution attack. The bug was introduced while changing an internal API to the FIPS required KEM API. A CVE-id has not been assigned. We track this bug as T8044 under https://dev.gnupg.org/T8044. This vulnerability was discovered by: OpenAI Security Research. Their report was received on 2026-01-18; fixed versions released 2026-01-27. Solution ======== If an affected GnuPG version is used please update ASAP to the new version 2.5.17. If an affected version of Gpg4win is used please update ASAP to the new version 5.0.1. If an immediate update is not possible please remove the gpgsm or gpgsm.exe binary; this way the bug can't be remotely triggered. Noteworthy changes in version 2.5.17 (2026-01-27) ================================================= [compared to version 2.5.16] * agent: Fix stack buffer overflow when using gpgsm and KEM. This was introduced with 2.5.13; see above. [T8044] * tpm: Fix possible buffer overflow in PKDECRYPT. [T8045] * gpg: Fix possible NULL-deref with overlong signature packets. [T8049] * gpg: New export-option "keep-expired-subkeys". [T7990] * gpgsm: Make multiple search patterns work with keyboxd. [T8026] * agent: Add accelerator keys for "Wrong" and "Correct". [T8055] * dirmngr: Help detection of bad keyserver configurations. [T7730] Release-info: https://dev.gnupg.org/T7996 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.17.tar.bz2 (8113k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.17.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.17_20260127.exe (5573k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.17_20260127.exe.sig The source used to build this installer for 64-bit Windows is available as https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260127.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260127.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. Debian Packages =============== We also provide new Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch to other distros/releases. It may take a view hours before the new packages show up. If you encounter other packaging problems please report them to the gnupg-devel mailing list. Windows Installer ================= A new version of Gpg4win (5.0.1), our full featured Windows installer, including this version of GnuPG, the Kleopatra GUI, and a PDF reader has also been released. Head over to https://gpg4win.org/ 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.17.tar.bz2 you would use this command: gpg --verify gnupg-2.5.17.tar.bz2.sig gnupg-2.5.17.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.17.tar.bz2, you run the command like this: sha1sum gnupg-2.5.17.tar.bz2 and check that the output matches the next line: ee0bc59eadf258b6d92131911b5dca6cabc89419 gnupg-2.5.17.tar.bz2 8826ff58e245c9700391fefff34afe775300e7cd gnupg-w32-2.5.17_20260127.tar.xz 31ac31fe8f5b4f3e3ae8e5e6a70c967a59f66e63 gnupg-w32-2.5.17_20260127.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Swedish, 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. If you are using cleartext signatures in your application please read https://gnupg.org/blog/20251226-cleartext-signatures.html . In case of build problems specific to this release please first check https://dev.gnupg.org/T7996 for updated information. We are sorry that due to ongoing DoS on this service, you may end up at a "is under maintenance page". 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 related software like Libgcrypt, GPGME, Kleopatra, Okular, 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 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [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. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the 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: 284 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 john.soo+gnupg-users at arista.com Tue Jan 27 23:33:54 2026 From: john.soo+gnupg-users at arista.com (John Soo) Date: Tue, 27 Jan 2026 15:33:54 -0700 Subject: Bad signatures issued on macOS Message-ID: Hi all, I have observed gnupg issuing bad signatures issued by gnupg (homebrew formula) for quite a while over several versions. The following report is using version 2.4.9 Running the following script will often issue a bad signature after only a few rounds: #!/usr/bin/env bash echo "" > git-trace.txt for i in {1..100}; do echo "loop ${i}" rm data.txt.asc echo "data was" > result-bad.txt cat data.txt >> result-bad.txt gpg --debug-level guru -bsau data.txt &> result-bad.txt echo "" >> result-bad.txt echo "signature was" >> result-bad.txt cat data.txt.asc >> result-bad.txt echo "" >> result-bad.txt echo "verification was" >> result-bad.txt if ! gpg --verify --debug-level guru data.txt.asc data.txt &>> result-bad.txt; then echo "result: failed" >> result-bad.txt echo "gpg verify failed for ${i}" break; else echo "result: succeeded" >> result-bad.txt cat result-bad.txt > result-good.txt echo "gpg verify passed for ${i}" fi done This results in the following failure, with names redacted: gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: enabled compatibility flags: gpg: DBG: [no clock] start gpg: DBG: [no clock] keydb_new gpg: DBG: chan_3 <- # Home: gpg: DBG: chan_3 <- # Config: [none] gpg: DBG: chan_3 <- OK Keyboxd 2.4.9 at your service, process 4788 gpg: DBG: connection to the keyboxd established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.4.9 gpg: DBG: chan_3 <- OK gpg: DBG: [no clock] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: LONG_KID: '6E628CC4145FD2ED' gpg: DBG: chan_3 -> SEARCH --openpgp -- 0x6E628CC4145FD2ED gpg: DBG: chan_3 <- S PUBKEY_INFO 1 1510C86404E2F6ECA02871DB6E628CC4145FD2ED -- 0 1 gpg: DBG: chan_3 <- [ 44 20 99 01 25 30 44 04 61 d3 e9 b8 01 08 00 c0 ...(982 byte(s) skipped) ] gpg: DBG: chan_3 <- [ 44 20 3f dc 08 00 51 26 7b ea a0 b4 cf 58 ab 02 ...(526 byte(s) skipped) ] gpg: DBG: chan_3 <- OK gpg: DBG: found UBID (0,1): 1510c86404e2f6eca02871db6e628cc4145fd2ed gpg: DBG: [no clock] keydb_search leave (found) gpg: DBG: [no clock] keydb_get_keyblock enter gpg: DBG: parse_packet(iob=1): type=6 length=269 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=12 length=12 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=13 length=44 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=12 length=12 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=2 length=290 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=12 length=6 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=14 length=269 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=2 length=574 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=1): type=12 length=6 (parse.../../g10/keydb.c.1184) gpg: DBG: iobuf-1.0: underflow: buffer size: 1504; still buffered: 0 => space for 1504 bytes gpg: DBG: iobuf-1.0: close '?' gpg: DBG: [no clock] keydb_get_keyblock leave gpg: DBG: chan_4 <- OK Pleased to meet you, process 4790 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_4 -> RESET gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION ttyname=/dev/ttys003 gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION ttytype=xterm-256color gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8 gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8 gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> GETINFO version gpg: DBG: chan_4 <- D 2.4.9 gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION allow-pinentry-notify gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> HAVEKEY --list=1000 gpg: DBG: chan_4 <- [ 44 20 35 61 9e c9 aa cd db 5c a7 85 f0 ce e9 36 ...(28 byte(s) skipped) ] gpg: DBG: chan_4 <- OK gpg: DBG: get_keygrip for public key gpg: DBG: keygrip= 35619ec9aacddb5ca785f0cee93610f5a479120b gpg: DBG: iobuf-2.0: close '?' gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004203f \ gpg: DBG: dc335fe186b13e6b54b5759a7b0e120e0ff8a6dbdb505651157561e3d97db3 gpg: DBG: rsa_verify sig:+51267beaa0b4cf58ab02e294035c1e43d1f448a006374d67f44b50dded44194d \ gpg: DBG: b6aa46d0c274d9c62c0b3d2aca3323a0d899be30613be6fab68c9e9e9810ff66 \ gpg: DBG: e18e044706bfe4cad515c22b439d96129312f5885f2fa28e4c14001d878958dc \ gpg: DBG: 9733b9534cebd07107364fa5974640e69e27f6ff65f3df05efd2ef1e453ea279 \ gpg: DBG: db8f39139743407dd4949a098bc0d5113ed8dc82ca4bdd8ffb0a83012bad2b6d \ gpg: DBG: ca16646b139a470bb22301e0bee567063d9da45b2575cd61986618007ade48a3 \ gpg: DBG: 9ae0798834c66f7a08d5e4ae25b873b8b245f7b972f0e0e82494b0d13685d5d8 \ gpg: DBG: 2f946b8cf6f5cb764694ea921c6ca8a46d82fe733d3572ebe1d91943b7091ef8 gpg: DBG: rsa_verify n:+c744addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380 \ gpg: DBG: 31cb1dbe382c323ce7bb478277a1bc6d6221629e6d7efe09fd8054dda00a7448 \ gpg: DBG: bc1825c6e6ee5142cb73078d47d2d949b548a8b2b34a26a711b8135938aaa7e3 \ gpg: DBG: a0cc1486eeeea39c35f6025f08246c0c74b0a426e552603aff4876cfa8f1ebb5 \ gpg: DBG: cd21c62b50df523ee1d3bc22e954d04f8c9ada6de1e13a7e8c35698a3ef4dfa2 \ gpg: DBG: 15cc93e386f7e83c25a29bdfab14ffe328b12f14a630427f1f362ba75c710846 \ gpg: DBG: 44343f5b8be84389fe5d11096aafb1456b832aa284d11e3bd0ed66669ed53a6c \ gpg: DBG: 1ea5bc8ad87ae0a10f5fcc4d4baaf11c79a7b79e1f57b58daeec4f0729468383 gpg: DBG: rsa_verify e:+010001 gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004203f \ gpg: DBG: dc335fe186b13e6b54b5759a7b0e120e0ff8a6dbdb505651157561e3d97db3 gpg: DBG: rsa_verify => Good gpg: DBG: finish_lookup: checking key 145FD2ED (all)(req_usage=1) gpg: DBG: checking subkey 7374A315 gpg: DBG: get_keygrip for public key gpg: DBG: keygrip= da5bd99e936bb5a99e36ccef77975b45a4fac50d gpg: DBG: chan_4 -> KEYINFO DA5BD99E936BB5A99E36CCEF77975B45A4FAC50D gpg: DBG: chan_4 <- S KEYINFO DA5BD99E936BB5A99E36CCEF77975B45A4FAC50D D - - - C - - - gpg: DBG: chan_4 <- OK gpg: DBG: subkey might be fine gpg: DBG: using key 7374A315 gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED gpg: DBG: free_packet() type=6 gpg: DBG: free_packet() type=13 gpg: DBG: free_packet() type=2 gpg: DBG: free_packet() type=14 gpg: DBG: free_packet() type=2 gpg: DBG: fd_cache_open (data.txt) not cached gpg: DBG: iobuf-3.0: open 'data.txt' desc=file_filter(fd) fd=5 gpg: DBG: fd_cache_invalidate (data.txt.asc) gpg: DBG: iobuf-4.0: open 'data.txt.asc' desc=file_filter(fd) fd=6 gpg: writing to 'data.txt.asc' gpg: DBG: iobuf-4.0: ioctl 'file_filter(fd)' no_cache=1 gpg: DBG: get_keygrip for public key gpg: DBG: keygrip= da5bd99e936bb5a99e36ccef77975b45a4fac50d gpg: DBG: chan_4 -> KEYINFO DA5BD99E936BB5A99E36CCEF77975B45A4FAC50D gpg: DBG: chan_4 <- S KEYINFO DA5BD99E936BB5A99E36CCEF77975B45A4FAC50D D - - - C - - - gpg: DBG: chan_4 <- OK gpg: DBG: iobuf-3.1: push 'md_filter' gpg: DBG: iobuf chain: 3.1 'md_filter' filter_eof=0 start=0 len=0 gpg: DBG: iobuf chain: 3.0 'file_filter(fd)' filter_eof=0 start=0 len=0 gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf-4.1: push 'armor_filter' gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf chain: 4.1 'armor_filter' filter_eof=0 start=0 len=0 gpg: DBG: iobuf chain: 4.0 'file_filter(fd)' filter_eof=0 start=0 len=0 gpg: DBG: armor-filter: control: 1 gpg: DBG: iobuf-3.1: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-3.1: underflow: A->FILTER (65536 bytes) gpg: DBG: iobuf-3.0: reading to external buffer, 65536 bytes gpg: DBG: iobuf-3.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-3.0: limit buffering as external drain is preferred gpg: DBG: iobuf-3.0: underflow: A->FILTER (65536 bytes, to external drain) gpg: DBG: iobuf-3.0: A->FILTER() returned rc=0 (ok), read 3 bytes (to external buffer) gpg: DBG: iobuf-3.0: reading to external buffer, 64512 bytes gpg: DBG: iobuf-3.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-3.0: limit buffering as external drain is preferred gpg: DBG: iobuf-3.0: underflow: A->FILTER (64512 bytes, to external drain) gpg: DBG: iobuf-3.0: A->FILTER() returned rc=-1 (EOF), read 0 bytes gpg: DBG: data.txt: close fd/handle 5 gpg: DBG: fd_cache_close (data.txt) new slot created gpg: DBG: iobuf-3.1: A->FILTER() returned rc=0 (ok), read 3 bytes gpg: DBG: iobuf-3.1: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-3.1: underflow: A->FILTER (65536 bytes) gpg: DBG: iobuf-3.0: reading to external buffer, 65536 bytes gpg: DBG: iobuf-3.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-3.0: underflow: eof (pending eof) gpg: DBG: iobuf-3.1: A->FILTER() returned rc=-1 (EOF), read 0 bytes gpg: DBG: iobuf-3.1: pop in underflow (nothing buffered, got EOF) gpg: DBG: iobuf chain: 3.0 '?' filter_eof=0 start=0 len=0 gpg: DBG: iobuf-3.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: get_keygrip for public key gpg: DBG: keygrip= da5bd99e936bb5a99e36ccef77975b45a4fac50d gpg: DBG: chan_4 -> RESET gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> SIGKEY DA5BD99E936BB5A99E36CCEF77975B45A4FAC50D gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22%22%0A2048-bit+RSA+key,+ID+B67EB1E57374A315,%0Acreated+2022-01-04+(main+key+ID+6E628CC4145FD2ED).%0A gpg: DBG: chan_4 <- OK gpg: DBG: chan_4 -> SETHASH 8 0D8C9D7F68427ADF273ABC5DE19566D8DB10D76A0F1D114A2F42C670003E7E27 gpg: DBG: chan_4 <- OK gpg: DBG: [no clock] enter signing gpg: DBG: chan_4 -> PKSIGN gpg: DBG: chan_4 <- [ 44 20 28 37 3a 73 69 67 2d 76 61 6c 28 33 3a 72 ...(271 byte(s) skipped) ] gpg: DBG: chan_4 <- OK gpg: DBG: [no clock] leave signing gpg: RSA/SHA256 signature from: "B67EB1E57374A315 " gpg: DBG: build_packet() type=2 gpg: DBG: iobuf-5.0: close '?' gpg: DBG: free_packet() type=2 gpg: DBG: armor-filter: control: 4 gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf-4.1: close 'armor_filter' gpg: DBG: armor-filter: control: 2 gpg: DBG: iobuf-4.0: close 'file_filter(fd)' gpg: DBG: data.txt.asc: close fd/handle 6 gpg: DBG: fd_cache_close (6) real gpg: DBG: iobuf-3.0: close '?' gpg: DBG: [no clock] keydb_release gpg: DBG: [no clock] close_context (found) gpg: DBG: chan_3 -> BYE gpg: DBG: [no clock] stop gpg: keydb: handles=0 locks=0 parse=1 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=2 cached=2 good=2 bad=0 gpg: objcache: keys=2/2/0 chains=381,1..1 buckets=383/20 attic=254 gpg: objcache: uids=1/1/0 chains=106,1..1 buckets=107/20 gpg: random usage: poolsize=600 mixed=0 polls=0/3 added=15/516 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 1344/32768 bytes in 2 blocks signature was -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEG34w4o9D0vlGnPYqtn6x5XN0oxUFAml5NCYACgkQtn6x5XN0 oxUNjAgAxk6Xx6qOomoXKhWJz8j2AYmuYbiV4H01Yum/EdYOX0Tpzz2cXLEypkXK lpC8DM16PF1r/INO6zroq3TZAQ5T3Us3x6xQ3f10zwjB7FfjzHAnTTdAKIGF7a/A 7vMBrSffvoW5FNh6F6eURvOcQDsejitxlNuL3R+g7IYQO2g3abFrYS602RgrNCHf heDzMt8FunqTj2sHEf1dOIedwkfkuA9XRKnl1wikiGelxWr1/EN715+N91lMnS2b 9U3uRccmcNRDenWSG7d6EcfJyMueKg0FeViUAZVPt4rYyWpVm4UGzsY/9Nrq4Ig9 6754M7KEtepp9+XYSnytREjqdmgQpA== =GEfp -----END PGP SIGNATURE----- verification was gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: enabled compatibility flags: gpg: DBG: [no clock] start gpg: DBG: fd_cache_open (data.txt.asc) not cached gpg: DBG: iobuf-1.0: open 'data.txt.asc' desc=file_filter(fd) fd=3 gpg: DBG: iobuf-1.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-1.0: underflow: A->FILTER (65536 bytes) gpg: DBG: iobuf-1.0: A->FILTER() returned rc=0 (ok), read 488 bytes gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf-1.1: push 'armor_filter' gpg: DBG: armor-filter: control: 5 gpg: DBG: iobuf chain: 1.1 'armor_filter' filter_eof=0 start=0 len=0 gpg: DBG: iobuf chain: 1.0 'file_filter(fd)' filter_eof=0 start=0 len=488 gpg: DBG: armor-filter: control: 1 gpg: DBG: iobuf-1.1: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-1.1: underflow: A->FILTER (65536 bytes) gpg: DBG: armor-filter: control: 3 gpg: DBG: iobuf-1.1: A->FILTER() returned rc=0 (ok), read 310 bytes gpg: DBG: parse_packet(iob=1): type=2 length=307 (parse.../../g10/mainproc.c.1647) gpg: DBG: iobuf-1.1: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-1.1: underflow: A->FILTER (65536 bytes) gpg: DBG: armor-filter: control: 3 gpg: DBG: iobuf-1.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-1.0: underflow: A->FILTER (65536 bytes) gpg: DBG: iobuf-1.0: A->FILTER() returned rc=-1 (EOF), read 0 bytes gpg: DBG: data.txt.asc: close fd/handle 3 gpg: DBG: fd_cache_close (data.txt.asc) new slot created gpg: DBG: iobuf-1.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-1.0: underflow: eof (pending eof) gpg: DBG: iobuf-1.1: A->FILTER() returned rc=-1 (EOF), read 0 bytes gpg: DBG: armor-filter: control: 2 gpg: DBG: iobuf-1.1: pop in underflow (nothing buffered, got EOF) gpg: DBG: iobuf chain: 1.0 '?' filter_eof=0 start=0 len=0 gpg: DBG: fd_cache_open (data.txt) not cached gpg: DBG: iobuf-2.0: open 'data.txt' desc=file_filter(fd) fd=5 gpg: DBG: iobuf-2.0: reading to external buffer, 65536 bytes gpg: DBG: iobuf-2.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-2.0: limit buffering as external drain is preferred gpg: DBG: iobuf-2.0: underflow: A->FILTER (65536 bytes, to external drain) gpg: DBG: iobuf-2.0: A->FILTER() returned rc=0 (ok), read 3 bytes (to external buffer) gpg: DBG: iobuf-2.0: reading to external buffer, 64512 bytes gpg: DBG: iobuf-2.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-2.0: limit buffering as external drain is preferred gpg: DBG: iobuf-2.0: underflow: A->FILTER (64512 bytes, to external drain) gpg: DBG: iobuf-2.0: A->FILTER() returned rc=-1 (EOF), read 0 bytes gpg: DBG: data.txt: close fd/handle 5 gpg: DBG: fd_cache_close (data.txt) new slot created gpg: DBG: iobuf-2.0: reading to external buffer, 65536 bytes gpg: DBG: iobuf-2.0: underflow: buffer size: 65536; still buffered: 0 => space for 65536 bytes gpg: DBG: iobuf-2.0: underflow: eof (pending eof) gpg: DBG: iobuf-2.0: close '?' gpg: Signature made Tue Jan 27 15:54:46 2026 CST gpg: using RSA key 1B7E30E28F43D2F9469CF62AB67EB1E57374A315 gpg: DBG: [no clock] keydb_new gpg: DBG: chan_7 <- # Home: gpg: DBG: chan_7 <- # Config: [none] gpg: DBG: chan_7 <- OK Keyboxd 2.4.9 at your service, process 4788 gpg: DBG: connection to the keyboxd established gpg: DBG: chan_7 -> GETINFO version gpg: DBG: chan_7 <- D 2.4.9 gpg: DBG: chan_7 <- OK gpg: DBG: [no clock] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FPR20: '1B7E 30E2 8F43 D2F9 469C F62A B67E B1E5 7374 A315' gpg: DBG: chan_7 -> SEARCH --openpgp -- 0x1B7E30E28F43D2F9469CF62AB67EB1E57374A315 gpg: DBG: chan_7 <- S PUBKEY_INFO 1 1510C86404E2F6ECA02871DB6E628CC4145FD2ED -- 0 2 gpg: DBG: chan_7 <- [ 44 20 99 01 25 30 44 04 61 d3 e9 b8 01 08 00 c0 ...(982 byte(s) skipped) ] gpg: DBG: chan_7 <- [ 44 20 3f dc 08 00 51 26 7b ea a0 b4 cf 58 ab 02 ...(526 byte(s) skipped) ] gpg: DBG: chan_7 <- OK gpg: DBG: found UBID (0,2): 1510c86404e2f6eca02871db6e628cc4145fd2ed gpg: DBG: [no clock] keydb_search leave (found) gpg: DBG: [no clock] keydb_get_keyblock enter gpg: DBG: parse_packet(iob=3): type=6 length=269 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=12 length=12 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=13 length=44 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=12 length=12 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=2 length=290 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=12 length=6 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=14 length=269 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=2 length=574 (parse.../../g10/keydb.c.1184) gpg: DBG: parse_packet(iob=3): type=12 length=6 (parse.../../g10/keydb.c.1184) gpg: DBG: iobuf-3.0: underflow: buffer size: 1504; still buffered: 0 => space for 1504 bytes gpg: DBG: iobuf-3.0: close '?' gpg: DBG: [no clock] keydb_get_keyblock leave gpg: DBG: iobuf-4.0: close '?' gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004203f \ gpg: DBG: dc335fe186b13e6b54b5759a7b0e120e0ff8a6dbdb505651157561e3d97db3 gpg: DBG: rsa_verify sig:+51267beaa0b4cf58ab02e294035c1e43d1f448a006374d67f44b50dded44194d \ gpg: DBG: b6aa46d0c274d9c62c0b3d2aca3323a0d899be30613be6fab68c9e9e9810ff66 \ gpg: DBG: e18e044706bfe4cad515c22b439d96129312f5885f2fa28e4c14001d878958dc \ gpg: DBG: 9733b9534cebd07107364fa5974640e69e27f6ff65f3df05efd2ef1e453ea279 \ gpg: DBG: db8f39139743407dd4949a098bc0d5113ed8dc82ca4bdd8ffb0a83012bad2b6d \ gpg: DBG: ca16646b139a470bb22301e0bee567063d9da45b2575cd61986618007ade48a3 \ gpg: DBG: 9ae0798834c66f7a08d5e4ae25b873b8b245f7b972f0e0e82494b0d13685d5d8 \ gpg: DBG: 2f946b8cf6f5cb764694ea921c6ca8a46d82fe733d3572ebe1d91943b7091ef8 gpg: DBG: rsa_verify n:+c744addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380 \ gpg: DBG: 31cb1dbe382c323ce7bb478277a1bc6d6221629e6d7efe09fd8054dda00a7448 \ gpg: DBG: bc1825c6e6ee5142cb73078d47d2d949b548a8b2b34a26a711b8135938aaa7e3 \ gpg: DBG: a0cc1486eeeea39c35f6025f08246c0c74b0a426e552603aff4876cfa8f1ebb5 \ gpg: DBG: cd21c62b50df523ee1d3bc22e954d04f8c9ada6de1e13a7e8c35698a3ef4dfa2 \ gpg: DBG: 15cc93e386f7e83c25a29bdfab14ffe328b12f14a630427f1f362ba75c710846 \ gpg: DBG: 44343f5b8be84389fe5d11096aafb1456b832aa284d11e3bd0ed66669ed53a6c \ gpg: DBG: 1ea5bc8ad87ae0a10f5fcc4d4baaf11c79a7b79e1f57b58daeec4f0729468383 gpg: DBG: rsa_verify e:+010001 gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004203f \ gpg: DBG: dc335fe186b13e6b54b5759a7b0e120e0ff8a6dbdb505651157561e3d97db3 gpg: DBG: rsa_verify => Good gpg: DBG: finish_lookup: checking key 145FD2ED (one)(req_usage=1,verify) gpg: DBG: exact search requested and found gpg: DBG: checking subkey 7374A315 gpg: DBG: subkey might be fine for verification gpg: DBG: using key 7374A315 gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED gpg: DBG: [no clock] enter pk_verify gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004200d \ gpg: DBG: 8c9d7f68427adf273abc5de19566d8db10d76a0f1d114a2f42c670003e7e27 gpg: DBG: rsa_verify sig:+c64e97c7aa8ea26a172a1589cfc8f60189ae61b895e07d3562e9bf11d60e5f44 \ gpg: DBG: e9cf3d9c5cb132a645ca9690bc0ccd7a3c5d6bfc834eeb3ae8ab74d9010e53dd \ gpg: DBG: 4b37c7ac50ddfd74cf08c1ec57e3cc70274d3740288185edafc0eef301ad27df \ gpg: DBG: be85b914d87a17a79446f39c403b1e8e2b7194db8bdd1fa0ec86103b683769b1 \ gpg: DBG: 6b612eb4d9182b3421df85e0f332df05ba7a938f6b0711fd5d38879dc247e4b8 \ gpg: DBG: 0f5744a9e5d708a48867a5c56af5fc437bd79f8df7594c9d2d9bf54dee45c726 \ gpg: DBG: 70d4437a75921bb77a11c7c9c8cb9e2a0d0579589401954fb78ad8c96a559b85 \ gpg: DBG: 06cec63ff4daeae0883debbe7833b284b5ea69f7e5d84a7cad4448ea766810a4 gpg: DBG: rsa_verify n:+c744addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380 \ gpg: DBG: 31cb1dbe382c323ce7bb478277a1bc6d6221629e6d7efe09fd8054dda00a7448 \ gpg: DBG: bc1825c6e6ee5142cb73078d47d2d949b548a8b2b34a26a711b8135938aaa7e3 \ gpg: DBG: a0cc1486eeeea39c35f6025f08246c0c74b0a426e552603aff4876cfa8f1ebb5 \ gpg: DBG: cd21c62b50df523ee1d3bc22e954d04f8c9ada6de1e13a7e8c35698a3ef4dfa2 \ gpg: DBG: 15cc93e386f7e83c25a29bdfab14ffe328b12f14a630427f1f362ba75c710846 \ gpg: DBG: 44343f5b8be84389fe5d11096aafb1456b832aa284d11e3bd0ed66669ed53a6c \ gpg: DBG: 1ea5bc8ad87ae0a10f5fcc4d4baaf11c79a7b79e1f57b58daeec4f0729468383 gpg: DBG: rsa_verify e:+010001 gpg: DBG: rsa_verify cmp:+c742addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380 \ gpg: DBG: 31cb1dbe382c323ce7bb478277a1bc6d6221629e6d7efe09fd8054dda00a7448 \ gpg: DBG: bc1825c6e6ee5142cb73078d47d2d949b548a8b2b34a26a711b8135938aaa7e3 \ gpg: DBG: a0cc1486eeeea39c35f6025f08246c0c74b0a426e552603aff4876cfa8f1ebb5 \ gpg: DBG: cd21c62b50df523ee1d3bc22e954d04f8c9ada6de1e13a7e8c35698a3ef4dfa2 \ gpg: DBG: 15cc93e386f7e83c25a29bdfab14ffe328b12f14a630427f1f362ba75c710846 \ gpg: DBG: 44343f5b8be84389fe5d110a6a7f80155e7d2141fe891cd6cde9646599d5364c \ gpg: DBG: 11191f0b703865c1e8250fef6a158a439e96e034103aa4437fa988972908055c gpg: DBG: rsa_verify => Bad signature gpg: DBG: [no clock] leave pk_verify gpg: using pgp trust model gpg: BAD signature from "" [unknown] gpg: binary signature, digest algorithm SHA256, key algorithm rsa2048 gpg: DBG: free_packet() type=6 gpg: DBG: free_packet() type=13 gpg: DBG: free_packet() type=2 gpg: DBG: free_packet() type=14 gpg: DBG: free_packet() type=2 gpg: DBG: free_packet() type=2 gpg: DBG: iobuf-1.0: close '?' gpg: DBG: [no clock] keydb_release gpg: DBG: [no clock] close_context (found) gpg: DBG: chan_7 -> BYE gpg: DBG: [no clock] stop gpg: keydb: handles=0 locks=0 parse=1 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=2 cached=2 good=2 bad=0 gpg: objcache: keys=2/2/0 chains=381,1..1 buckets=383/20 attic=254 gpg: objcache: uids=1/1/0 chains=106,1..1 buckets=107/20 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks result: failed Thank you! John From wk at gnupg.org Wed Jan 28 15:22:34 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Jan 2026 15:22:34 +0100 Subject: Bad signatures issued on macOS In-Reply-To: (John Soo via Gnupg-users's message of "Tue, 27 Jan 2026 15:33:54 -0700") References: Message-ID: <87h5s5zuj9.fsf@jacob.g10code.de> Hi! On Tue, 27 Jan 2026 15:33, John Soo said: > Running the following script will often issue a bad signature after > only a few rounds: You may run into problems when mixing stdout and stderr (&>FILE). Also please do not use --debug-level guto or any other of those debug levels; they are too noisy or don't print what you want. Always use -v or --verbose and then selected debug flags. In your case I would suggest --debug hashing which writes files with what was actually hashed for signature creation and verification. Compare them. 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: 284 bytes Desc: not available URL: From john.soo+gnupg-users at arista.com Wed Jan 28 18:38:37 2026 From: john.soo+gnupg-users at arista.com (John Soo) Date: Wed, 28 Jan 2026 10:38:37 -0700 Subject: Bad signatures issued on macOS In-Reply-To: <87h5s5zuj9.fsf@jacob.g10code.de> References: <87h5s5zuj9.fsf@jacob.g10code.de> Message-ID: Thanks Werner! I tried with -v --debug hashing and the content for hashing was not printed, is there another flag I need to use? For reference, this was a good sig: gpg: reading options from '[cmdline]' gpg: reading options from '/Users//.gnupg/common.conf' gpg: enabled debug flags: hashing gpg: enabled compatibility flags: gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED gpg: writing to 'data.txt.asc' gpg: RSA/SHA256 signature from: "B67EB1E57374A315 " gpg: secmem usage: 1344/32768 bytes in 2 blocks signature was -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEG34w4o9D0vlGnPYqtn6x5XN0oxUFAml6SJwACgkQtn6x5XN0 oxXMrgf9HQbhUZZUp+pPHSpT5Rw3GvnJLH5Sq5KUtmEYs0PArjwNN86OeHN+EENd f5F2PXHCTtNgY4OKibm5iJWO1qsCVKJeg/nhdqdx6xLuskAzBi5ogKJOfORSYKpY vLvRWbK55ag4iZqxeLJHrt6Chu9qsdlPyWMptzSQGlX2+9fVybmghdthFiUUOoBk FZDXuH1s30pUha7h4mNAn52A3P8pIpqX4f46vRTCYqjTtRuc1bXotQFvcmv8WmP+ URcluMyQc4G5eSBGAeTODtgOBTLntvWMbFxLopO9o7HSIiKUNqgJxl6ZtUzbUxQu hziwl6C2gT+1/OUn16hz1m8cIEkAJA== =m0Gd -----END PGP SIGNATURE----- verification was gpg: reading options from '[cmdline]' gpg: reading options from '/Users//.gnupg/common.conf' gpg: enabled debug flags: hashing gpg: enabled compatibility flags: gpg: Signature made Wed Jan 28 11:34:20 2026 CST gpg: using RSA key 1B7E30E28F43D2F9469CF62AB67EB1E57374A315 gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED gpg: using pgp trust model gpg: Good signature from "" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 1510 C864 04E2 F6EC A028 71DB 6E62 8CC4 145F D2ED Subkey fingerprint: 1B7E 30E2 8F43 D2F9 469C F62A B67E B1E5 7374 A315 gpg: binary signature, digest algorithm SHA256, key algorithm rsa2048 gpg: secmem usage: 0/32768 bytes in 0 blocks result: succeeded --- John On Wed, Jan 28, 2026 at 7:19?AM Werner Koch wrote: > > Hi! > > On Tue, 27 Jan 2026 15:33, John Soo said: > > > Running the following script will often issue a bad signature after > > only a few rounds: > > You may run into problems when mixing stdout and stderr (&>FILE). Also > please do not use --debug-level guto or any other of those debug > levels; they are too noisy or don't print what you want. > > Always use -v or --verbose and then selected debug flags. In your case > I would suggest > > --debug hashing > > which writes files with what was actually hashed for signature creation > and verification. Compare them. > > > > Shalom-Salam, > > Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein From wk at gnupg.org Thu Jan 29 10:53:23 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Jan 2026 10:53:23 +0100 Subject: Bad signatures issued on macOS In-Reply-To: (John Soo via Gnupg-users's message of "Wed, 28 Jan 2026 10:38:37 -0700") References: <87h5s5zuj9.fsf@jacob.g10code.de> Message-ID: <87ms1wycbw.fsf@jacob.g10code.de> On Wed, 28 Jan 2026 10:38, John Soo said: > Thanks Werner! > > I tried with -v --debug hashing and the content for hashing was not > printed, is there another flag I need to use? Let's see using some arbitrary signature $ gpg --verify --debug hashing swdb.lst.sig swdb.lst gpg: reading options from '/home/wk/.gnupg/gpg.conf' gpg: reading options from '[cmdline]' gpg: reading options from '/home/wk/.gnupg/common.conf' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: enabled debug flags: hashing gpg: enabled compatibility flags: gpg: Signature made Fri 23 Feb 2024 02:34:37 PM CET gpg: using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA gpg: using pgp trust model gpg: please do a --check-trustdb gpg: Good signature from "Werner Koch (dist signing 2020)" [ultimate] gpg: binary signature, digest algorithm SHA256, key algorithm ed25519 gpg: secmem usage: 0/32768 bytes in 0 blocks $ ls -lt | head -3 total 29839972 -rw-r--r-- 1 wk wk 4725 Jan 29 10:44 dbgmd-00001.verify -rw-r--r-- 1 wk wk 41 Jan 29 10:44 dbgmd-00002.unknown dbgmd-00001.verify is the same as swdb.lst dbgmd-00002.unknown is the trailer hashed after swdb.lst. When creating the signature you should have seen dbgmd-00001.sign with the to be signed data dbgmd-00001.unknown with the trailer. dbgmd-00001.unknown gets overwritten so you need to store it away for later comparing. 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: 284 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 29 14:09:43 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Jan 2026 14:09:43 +0100 Subject: [Announce] Libgcrypt 1.12.0 released Message-ID: <87ecn8y38o.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt version 1.12.0. This release starts a new stable branch of Libgcrypt with full API and ABI compatibility to the 1.11 series. Since the last major release Jussi Kivilinna put again a lot of work into speeding up the algorithms for modern CPUs. Niibe-san implemented new APIs and algorithms and adjusted the interface for new FIPS requirements. See below for a list of improvements and new features in 1.12. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide implementations of protocols like *PGP. Thorough understanding of applied cryptography is required for safe use of Libgcrypt. Noteworthy changes in version 1.12.0 (2026-01-29) ------------------------------------------------- * New and extended interfaces: - Allow access to the FIPS service indicator via the new GCRYCTL_FIPS_SERVICE_INDICATOR control code. [T7338,rCd0db6a5abf,rCf51f4e9893] - Add GCRYCTL_FIPS_REJECT_NON_FIPS control code. [T7338,rCe52adf0948] - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS constant. [T7338,rC0414e126b9] - Make SHA-1 non-FIPS internally for the 1.12 API. This introduces the GCRY_FIPS_FLAG_REJECT_MD_SHA1 constant. [rC4ee91a94bc] - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS. [rC0414e126b9] - Provide macros for each KEM enum constant. [rCe9b1c3ec91] - Add Dilithium (ML-DSA) support. [T7640] - Support optional random-override and support byte string data. [rCcbefff5fca,rC3bb4a54f43] * Performance: - Add VAES/AVX512 accelerated implementation for AES which boosts OCB performance by about 2 times on AMD Zen5. [rC9e3af928ee] - Avoid AVX512/AVX2/SSSE3 for single block processing with Zen5 for ChaCha20. [rCc1d9fff3b2] - Avoid AVX/AVX2/AVX512 when CPU has high vector inst latency like Zen5 for Blake2. [rCe5bc3b2826] - Various optimizations for Camellia. [rCf5848080d4,rCb9bafd6c6c,rC8b538a8c76] - Add POLYVAL acceleration for RISC-V and GCM-SIV. [rC00815c4207] - Add RISC-V Zbb+Zbc implementation of CRC. [rCab4fa2a19c] - Add RISC-V vector cryptography implementation of GHASH. [rCcc2a4b6388] - Add RISC-V vector cryptography implementation of AES. [rCb000ab6025] - Add RISC-V vector cryptography implementations of SHA256 and SHA512. [rCcc1d5b0b5e] - Add AVX2 and AVX512 code paths to improve CRC. [rCc30788969d] * Bug fixes: - Use secure MPI in _gcry_mpi_assign_limb_space. [rC6e77b09cff] - Use CSIDL_COMMON_APPDATA instead of /etc on Windows. [rCd5e3cbfd88] - Apply a Kyber patch from upstream. [rCbdc3724d72] - Fix an edge case in Jent initialization. [rC0ceca9993f] - mceliece6688128f: Fix stack overflow crash on win64/wine [rC5bd9320171] * Other: - Add support for IBM z/OS, fixing -lpthread check with glibc. [rC5af59d8454] - Introduce mpi_tfr and use it for point_tfr to decrease EM signal and increase EM noise. [rC4e65996bb8] - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN. [T7889] - Harden mask generation against branch optimization for several algorithms. [e.g. rC4012e9a037,rCbf7546c502,rC052b03fb0c] - Improve constant-time operation for ECDSA. [T7519,rC0bd4c77be6] Changes also found in 1.11.2: * Bug fixes: - Fix link errors in regression test t-thread-local on some platforms (e.g. NetBSD). [T7634] - Add missing file to allow building for RISC-V. [T7647] - Support secp256k1 by KEM API. GnuPG has recently switched to use the KEM interface and a few folks are using this curve. [T7698] - Fix a missing initialization in RSA's generate_fips. [rG292cb75a72] * Other: - Silence GCC 15 warnings [rCd5fb7cd9b3,T7617] - Provide a prototype for __udiv_qrnnd for PowerPC and Alpha which is required due to GCC-15 changes. [T7721] - Add missing abi versions and machine tags for PowerPC assembly with GCC-15. [T7721] - Use '.rodata' section for read-only data of poly1305-p10le. [T7721] Changes also found in 1.11.1: * Bug fixes: - Fix build regression on 32 bit Windows using Clang. [T7175] - Fix build regression on macOS due to symbol naming. [T7170] - Fix Kyber secret-dependent branch introduced by recent versions of Clang. [rCf765778e82] - Fix build regression due to the use of AVX512 in Blake. [T7184] - Do not build i386 asm on amd64 and vice versa. [T7220] - Fix build regression on armhf with gcc-14. [T7226] - Return the proper error code on malloc failure in hex2buffer. [rCc51151f5b0] - Fix long standing bug for PRIME % 2 == 0. [rC639b0fca15] * Performance: - Add AES Vector Permute intrinsics implementation for AArch64. [rC94a63aedbb] - Add GHASH AArch64/SIMD intrinsics implementation. [rCfec871fd18] - Add RISC-V vector permute AES. [rCb24ebd6163] - Add GHASH RISC-V Zbb+Zbc implementation. [rC0f1fec12b0] - Add ChaCha20 RISC-V vector intrinsics implementation. [rC8dbee93ac2] - Add SHA3 acceleration for RISC-V Zbb extension. [rC1a660068ba] * Other: - Add CET support for i386 and amd64 assembly. [T7220] - Add PAC/BTI support for AArch64 asm. [T7220] - Apply changes to Kyber from upstream for final FIPS 203. [rCcc95c36e7f] - Introduce an internal API for a revampled FIPS service indicator. [T7340] - Several improvements for constant time operation by the introduction of Least Leak Intended (LLI) variants of internal functions. [T7519,T7490] - Remove WindowsCE support. [T7486] * Interface changes relative to the 1.11.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_KEM_RAW_P256R1 NEW enum and const. GCRYCTL_FIPS_SERVICE_INDICATOR NEW enum. GCRYCTL_FIPS_REJECT_NON_FIPS NEW enum. GCRY_FIPS_FLAG_REJECT_PK_FLAGS NEW const. GCRY_FIPS_FLAG_REJECT_MD_SHA1 NEW const. For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T7643 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.12.0.tar.bz2 you would use this command: gpg --verify libgcrypt-1.12.0.tar.bz2.sig libgcrypt-1.12.0.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.12.0.tar.bz2, you run the command like this: sha1sum libgcrypt-1.12.0.tar.bz2 and check that the output matches the first line from the this list: 02f80e9bc9967609b7041ef874eae4e542f240a5 libgcrypt-1.12.0.tar.bz2 1327dd6ca3ec2309ac750ef1c01cbd96432f11a8 libgcrypt-1.12.0.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T7643 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . Please see https://gnupg.org/documentation/security.html for information on how to report security issues and for our threat model. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have now 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 helping with donations. *Thank you all* Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel'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 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [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. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- 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: 284 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce