From m at gnupg.org Tue Sep 2 09:34:56 2025 From: m at gnupg.org (Meik Michalke) Date: Tue, 02 Sep 2025 09:34:56 +0200 Subject: new GnuPG merchandise available Message-ID: <2182566.YXv2LNvnCZ@kasidy> hi, we're happy to announce that we have launched a new web shop where you can find merchandise to show your support for GnuPG: https://gnupg.myspreadshop.de our main goal here is to enhance the visibility of GnuPG. we will donate our profits to other free software projects which lack financial support. we have been planning to offer merchandise again for a long time, and this print-on-demand service enables us to offer a wide range of products, so we hope there is something for everyone. please contact us if you can't find what you're looking for. you can get a 25% discount for orders within the next 9 days. 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 rjh at sixdemonbag.org Tue Sep 2 09:54:45 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Sep 2025 03:54:45 -0400 Subject: new GnuPG merchandise available In-Reply-To: <2182566.YXv2LNvnCZ@kasidy> References: <2182566.YXv2LNvnCZ@kasidy> Message-ID: <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> > we're happy to announce that we have launched a new web shop where you can > find merchandise to show your support for GnuPG: > > https://gnupg.myspreadshop.de Is there any possibility of GnuPG laptop stickers, or GnuPG-branded OpenPGP cards, or a GnuPG laptop bag? I'd be interested in any and all of them, but branded T-shirts just aren't my thing. -------------- 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 Tue Sep 2 10:39:50 2025 From: m at gnupg.org (Meik Michalke) Date: Tue, 02 Sep 2025 10:39:50 +0200 Subject: new GnuPG merchandise available In-Reply-To: <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> References: <2182566.YXv2LNvnCZ@kasidy> <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> Message-ID: <2323467.n5hnW3eMMA@kasidy> Am Dienstag, 2. September 2025, 09:54:45 CEST schrieb Robert J. Hansen via Gnupg-users: > Is there any possibility of GnuPG laptop stickers, or GnuPG-branded > OpenPGP cards, or a GnuPG laptop bag? I'd be interested in any and all > of them, but branded T-shirts just aren't my thing. FWIW, there's a lot more than just t-shirts, including stickers, mousepads, and various bags and backpacks: https://gnupg.myspreadshop.de/accessoires 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 Tue Sep 2 15:09:48 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:09:48 +0200 Subject: Egon In-Reply-To: <172f9047-ab9b-f8ad-a958-9d4cb77699c0@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Fri, 29 Aug 2025 18:18:57 +0200") References: <46f0c4e6-f3f4-4779-97ad-6408c0526e87@sixdemonbag.org> <87bjo1dfd2.fsf@nyarlathotep> <2e30631d-3c10-d3c0-8965-a88791697543@wisemo.com> <172f9047-ab9b-f8ad-a958-9d4cb77699c0@wisemo.com> Message-ID: <873495dmqr.fsf@jacob.g10code.de> On Fri, 29 Aug 2025 18:18, Jakob Bohm said: > Cool, maybe put that information in the man page near the affected > options (I looked up the options in the Debian Bookworm packaged > man page from package version 2.2.40-1.1) Maybe I should write an update to https://gnupg.org/blog/20160830-web-key-service.html to explain the options we introduced a bit later. 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 Tue Sep 2 15:23:39 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:23:39 +0200 Subject: Get pinentry to work in a container In-Reply-To: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> (zyxhere's message of "Sun, 31 Aug 2025 01:41:19 +0500") References: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> Message-ID: <87y0qxc7j8.fsf@jacob.g10code.de> Hi! This is somewhat off topic but I find it really hard to parse all that Python style quoting. Please remember that many folks are reading this and example and thus is should be easy to read. Saving 10 seconds in writing takes up 1000*2 secoonds to read. Or lets say 500*2 seconds because many won't read it at all due to crude formatting. Compare this snippted from your mail Permissions on /dev/console (that bubblwrap creates): ``` localhost # ll /dev/console crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console ``` Permissions of bind mounted /dev/console: ``` localhost # ll /dev/console crw--w---- 1 nobody nobody 5, 1 Aug 29 21:45 /dev/console ``` to this style: Permissions on /dev/console (that bubblwrap creates): localhost # ll /dev/console crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console Permissions of bind mounted /dev/console: localhost # ll /dev/console crw--w---- 1 nobody nobody 5, 1 Aug 29 21:45 /dev/console tia, 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 Tue Sep 2 15:39:17 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:39:17 +0200 Subject: [Announce] GnuPG 2.5.12 released Message-ID: <87plc9c6t6.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.12. This release adds new features and fixes two regressions. Note that this 2.5 series is fully supported and thus ready for production use. This means we won't break anything but may add some more features before 2.6. The main features in the 2.5. and 2.6 series are improvements for 64 bit Windows and the introduction of Kyber (ML-KEM, FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. Please be aware that the 2.4 series will reach end of life in June next of year. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.12 (2025-09-02) ================================================= [compared to version 2.5.11] * gpg: New options --[no-]auto-key-upload. [T7333] * gpg: Keys send to an LDAP server are now first updated from that server. New keyserver option "no-update-before-send" to disable this feature. [T7730] * gpg: Disable default compression for 7z compressed input. [rG53252628de] * gpg: Fix a regression with composite PQC and ECC algos. [T7649] * gpg: Fix the list of possible algos for --edit-key:addkey. [T7788] * gpg: Allow to select the Kyber variants with --edit-key:addkey. [T7792] * gpg: Avoid a second Pinentry pop-up for a configured ADSK during key generation. [T7491] * gpg: Change the ADSK key binding time to use the current time. [T6882] * gpgsm: Add option --no-qes-note and new trustlist flag "noconsent". [T7713] * agent: Enable "relax" in the trustlist by default and add flag "norelax". [rG7b133027ae] * agent: Fix a crash on Windows in the Putty support. [T7799] * dirmgr: Support LDAP servers using a schema like the Windows LDS servers. [T7742] * scd:openpgp: Support Yubikey attestation generation. [rG5ddfedf24a] * gpgtar: Fix regression in end-of-archive detection. [T7757] Release-info: https://dev.gnupg.org/T7756 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.12.tar.bz2 (8032k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.12.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.12_20250902.exe (5527k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.12_20250902.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.12_20250902.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.12_20250902.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 =============== For the first time we now provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/bookworm-devel/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Windows Installer ================= A new *Beta* version of Gpg4win, our full featured Windows installer including this version of GnuPG as well as the Kleopatra GUI and a PDF will soon be released. Stay tuned to https://gpg4win.org/version5.html 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.12.tar.bz2 you would use this command: gpg --verify gnupg-2.5.12.tar.bz2.sig gnupg-2.5.12.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.12.tar.bz2, you run the command like this: sha1sum gnupg-2.5.12.tar.bz2 and check that the output matches the next line: 027af3b8cc614683cad267ecb99ba24e4ce7709a gnupg-2.5.12.tar.bz2 d4a2e3e2d54bb37b643d36c2e566e5372f194b24 gnupg-w32-2.5.12_20250902.tar.xz a2a02f1aca6f7894840f534e65de08a6dbc84ba5 gnupg-w32-2.5.12_20250902.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7756 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. A team of full-time employed developers and contractors are working exclusively on GnuPG and 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 bernhard at intevation.de Wed Sep 3 09:16:12 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:16:12 +0200 Subject: How to format code in emails to this list In-Reply-To: <87y0qxc7j8.fsf@jacob.g10code.de> References: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> <87y0qxc7j8.fsf@jacob.g10code.de> Message-ID: <202509030916.22888.bernhard@intevation.de> Werner, Am Dienstag 02 September 2025 15:23:39 schrieb Werner Koch via Gnupg-users: > This is somewhat off topic but I find it really hard to parse all that > Python style quoting. to be fair, the trend as I have observed it, comes with Markdown style, especially github-flavoured-markdown. > Permissions on /dev/console (that bubblwrap creates): > ``` > localhost # ll /dev/console > crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console > ``` something like ```c int main() { } ``` will give syntax highlighting on platforms like Heptapod (based on the Free Software gitlab core) and others. In that case it helps to mark what kind of output is described. While Python allows for full line strings, it does not have the syntax marking. Overall I think it is okay, though the reStructured text style that you have mentioned, which is more like the original Python documentation, is better to read in a simple email. Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 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: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 3 09:21:09 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:21:09 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <87plc9c6t6.fsf@jacob.g10code.de> References: <87plc9c6t6.fsf@jacob.g10code.de> Message-ID: <202509030921.10162.bernhard@intevation.de> Am Dienstag 02 September 2025 15:39:17 schrieb Werner Koch via Gnupg-users: > Note that this 2.5 series is fully supported and thus ready for > production use. ?This means we won't break anything but may add some > more features before 2.6. Congratulations to 2.5.12 and that it is now ready for production usage! As there have not been announcements of 2.5.10 and .11 and the last announcement still had Version 2.5.9 which will soon lead us to the new stable 2.6 series. when did this happen? From 2.5.11 -> .12? Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 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: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 3 09:26:53 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:26:53 +0200 Subject: WKD <- some sites using it (Re: Egon) In-Reply-To: <87qzwxf3yc.fsf@jacob.g10code.de> References: <46f0c4e6-f3f4-4779-97ad-6408c0526e87@sixdemonbag.org> <87qzwxf3yc.fsf@jacob.g10code.de> Message-ID: <202509030926.53579.bernhard@intevation.de> Am Mittwoch 27 August 2025 12:34:35 schrieb Werner Koch via Gnupg-users: > gpg --locate-external-key foo at exmaple.org > > which does the lookup even if the key already exists in your local > keyring. > > WKD is used at more sites than Proton; > for example kernel.org. ?I think we have some list at wiki.gnupg.org. https://wiki.gnupg.org/WKD#Mail_Service_Providers_offering_WKD -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 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: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Sep 3 11:49:32 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Sep 2025 11:49:32 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <202509030921.10162.bernhard@intevation.de> (Bernhard Reiter via Gnupg-users's message of "Wed, 3 Sep 2025 09:21:09 +0200") References: <87plc9c6t6.fsf@jacob.g10code.de> <202509030921.10162.bernhard@intevation.de> Message-ID: <87bjnrdfwz.fsf@jacob.g10code.de> On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > Congratulations to 2.5.12 and that it is now ready for production usage! It has been for quite some time: Note that this 2.5 series [...] I just added a note to make this more clear. FWIW, we have customers using this on their systems since December. 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 andrewg at andrewg.com Wed Sep 3 18:32:25 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Sep 2025 18:32:25 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <87bjnrdfwz.fsf@jacob.g10code.de> References: <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: On 3 Sep 2025, at 11:47, Werner Koch via Gnupg-users wrote: > > On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > >> Congratulations to 2.5.12 and that it is now ready for production usage! > > It has been for quite some time: > > Note that this 2.5 series [...] > > I just added a note to make this more clear. FWIW, we have customers > using this on their systems since December. It used to be that the marker of whether a gnupg release was ?production ready? or not was the odd vs even minor release number. Will this no longer be the case in the future? Thanks, A From fg.gnupg at shimps.de Wed Sep 3 19:19:39 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Wed, 3 Sep 2025 19:19:39 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: References: <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: <20250903191939.419b2794@incubator.example.com> Hello. On Wed, 3 Sep 2025 18:32:25 +0200 Andrew Gallagher via Gnupg-users wrote: > > It used to be that the marker of whether a gnupg release was > ?production ready? or not was the odd vs even minor release number. > Will this no longer be the case in the future? As I read the announce mail | This means we won't break anything but may add some | more features before 2.6. the minor release number change will happen in the future, but the quality of the development branch is high thus it can be recommended for production even before this number change. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Sep 4 10:11:37 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 4 Sep 2025 10:11:37 +0200 Subject: 2.5.12 production ready (Re: [Announce] GnuPG 2.5.12 released) In-Reply-To: <87bjnrdfwz.fsf@jacob.g10code.de> References: <87plc9c6t6.fsf@jacob.g10code.de> <202509030921.10162.bernhard@intevation.de> <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: <202509041011.37387.bernhard@intevation.de> Am Mittwoch 03 September 2025 11:49:32 schrieb Werner Koch via Gnupg-users: > On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > > Congratulations to 2.5.12 and that it is now ready for production usage! > > It has been for quite some time: > > Note that this 2.5 series [...] This note first appeared in the 2.5.12 announcement, the last release announcement was 2.5.9 and did not have this note. > I just added a note to make this more clear. Very good, may I ask where: for the next annoucement or on the webpages? I think Andrew's question is good, if the even odd logic is kept. It helps to communicate to our users. Of course a mature 2.5. series can be "production ready" and still not "stable" in the sense that more features are planned. > FWIW, we have customers using this on their systems since December. Good to know! (General remark: pre-releases can be used in production if the usage is known and monitored closely. And the more usage a product revision or series sees, the better.) -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 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: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bkw.2524710 at 150mpg.com Thu Sep 4 17:40:28 2025 From: bkw.2524710 at 150mpg.com (Bryan K. Walton) Date: Thu, 04 Sep 2025 10:40:28 -0500 Subject: Formatting issue with pinentry-fltk? Message-ID: I've recently switched from X11 (with I3) to Wayland (with Sway). Therefore, I've also switched from using pinentry-gtk2 to pinentry-fltk. This is working for me. However, I've noticed that the pinentry prompt is only showing the first part of my secret key? Specifically, it shows something like this: Please enter the passphrase to unlock the OpenPGP secret key: "Firstname LastName " 4096-bit RSA key, ID xxxxxxxxxxxxx, created 2024-05-13 (main key ID yyyyyyyyyyyyy). Passphrase: I'm curious if the truncated key information shown by pinentry-fltk is intentional? Is there a way that I can configure pinentry-fltk to show all of the information that was shown by pinentry-gtk2? Thanks, Bryan From gk at leniwiec.biz Thu Sep 4 21:45:55 2025 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Thu, 4 Sep 2025 21:45:55 +0200 Subject: TPM and PCRs Message-ID: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> Hello, I know that gnupg supports TPMs (from 2.3 IIRC) via keytotpm command. But AFAIK the main "selling point" of TPMs is binding encryption of secrets to specific software versions and system state via hashes (PCRs), so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or configuration is used. Does gpg supports binding keys to PCRs' state? Are there any plans to add such feature? Is it possible to somehow work it around before it is implemented? Thank you in advance. -- Grzegorz Kulewski From lee at zoo.dev Fri Sep 5 15:29:38 2025 From: lee at zoo.dev (Lee) Date: Fri, 5 Sep 2025 09:29:38 -0400 Subject: Silent failure when keyboxd is not running, no error or warning Message-ID: <6ad3fd88-49e9-4f0a-8408-5ac2dff78cb4@zoo.dev> Hello, hope you're all doing well! Today I noticed when trying to list my private keys with `--list-secret-keys` that nothing appeared. I was very confused. After some debugging with `--list-secret-keys --debug-all`, this line stood out: gpg: DBG: chan_4 <- ERR 134217755 Not found After re-verifying all my secret keys were really there on storage, and I had a pubring.kbx, I began to look through `gpg.conf` and `common.conf`. Behold, there was a `use-keyboxd` there. Deleting this line, I could use my keys again. It would have been really nice for gpg to report the internal error I pasted above, as "Unable to communicate with keyboxd", instead of a silent failure causing me to have a minor heart palpitation :) Thank you all for your super hard work on GPG! Lee From mcr at sandelman.ca Fri Sep 5 21:36:01 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 05 Sep 2025 15:36:01 -0400 Subject: TPM and PCRs In-Reply-To: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> Message-ID: <13271.1757100961@obiwan.sandelman.ca> Grzegorz Kulewski wrote: > I know that gnupg supports TPMs (from 2.3 IIRC) via keytotpm command. I have never used keytotpm myself, as yet. (I am deep in the openssl provider interface, trying to use it with openssl-tpm2, via ruby-openssl, to sign PKIX certificates, COSE/JOSE and CMS artifacts, and eventually, yes git commits using some tbd openpgp tool) (Also editor of RFC9334 Remote?ATtestation?procedureS?(RATS)?Architecture) > But AFAIK the main "selling point" of TPMs is binding encryption of > secrets to specific software versions and system state via hashes > (PCRs), so that the enrolled key is only accessible (may be "unsealed") > if specific trusted software and/or configuration is used. It's the major selling point, but it's not really the only thing they are good for. > Does gpg supports binding keys to PCRs' state? Are there any plans to > add such feature? Is it possible to somehow work it around before it is > implemented? You are kinda asking the question wrong. GNUPG is just an application; it has no special priviledge with the TPM. The question you should ask: are there TPMs and/or priviledged TPM interactions where a GNUPG private key could be unsealed by TPM only once the system is in a known trustoworthy state? I think that the answer is sorta. The evaluation ("Verification") of whether a final state PCR (Evidence) is valid or not generally something that occurs locally: You can't trust a trojan'ed system to claim to not be trojaned. While measured boot depends upon a root of trust, and that part usually involves a secured boot, if one wants to do secure boot all the way, then it leads to profound vendor lock-in, and "treasurous computing", that's really the only way to build a system that independantly can be judged as to whether or not it's in the right state. So in *this* model, you could imagine some thing returned from the Verifier that would allow a priviledged process to ask the TPM to unseal something. I'm unaware of any existing system that does exactly this, but that's probably just my limited knowledge. My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the main (disk) decryption key is stored in the TPM. It's only protected because the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and ability to talk to the TPM is restricted. Attacks on this have involved hardware access to i2c bus; there are ways to defend against this by encrypting that bus using the EK, but in that case, the main CPU has to have a copy of the EK public key somewhere safe. I suspect that your ultimate goal might be better satisfied with a USB connected secure element, with the ability to physically remove it from the system. An ummarked USB secure element key in a locked drawer full of USB keys containing endless pictures of cats is what I'd do :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: From gk at leniwiec.biz Fri Sep 5 22:12:50 2025 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Fri, 5 Sep 2025 22:12:50 +0200 Subject: TPM and PCRs In-Reply-To: <13271.1757100961@obiwan.sandelman.ca> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> <13271.1757100961@obiwan.sandelman.ca> Message-ID: <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> W dniu 05.09.2025 o?21:36, Michael Richardson pisze: > Grzegorz Kulewski wrote: > > Does gpg supports binding keys to PCRs' state? Are there any plans to > > add such feature? Is it possible to somehow work it around before it is > > implemented? > > You are kinda asking the question wrong. > GNUPG is just an application; it has no special priviledge with the TPM. > > The question you should ask: are there TPMs and/or priviledged TPM interactions > where a GNUPG private key could be unsealed by TPM only once the system is in > a known trustoworthy state? > I think that the answer is sorta. > > The evaluation ("Verification") of whether a final state PCR > (Evidence) is valid or not generally something that occurs locally: You can't > trust a trojan'ed system to claim to not be trojaned. While measured boot > depends upon a root of trust, and that part usually involves a secured boot, > if one wants to do secure boot all the way, then it leads to profound vendor > lock-in, and "treasurous computing", that's really the only way to build a > system that independantly can be judged as to whether or not it's in the right state. > > So in *this* model, you could imagine some thing returned from the Verifier > that would allow a priviledged process to ask the TPM to unseal something. > I'm unaware of any existing system that does exactly this, but that's probably just > my limited knowledge. > > My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the > main (disk) decryption key is stored in the TPM. It's only protected because > the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and > ability to talk to the TPM is restricted. Attacks on this have involved > hardware access to i2c bus; there are ways to defend against this by > encrypting that bus using the EK, but in that case, the main CPU has to have > a copy of the EK public key somewhere safe. I am not an expert but AFAIK when sealing a secret in TPM you can bind it to some PCR state (or not). I believe any code that can open TPM /dev can do this, not something "privileged". But if gpg doesn't do it then the secret is not protected by any "verified state" bindings and nothing (except improving gpg and sealing that key again) can be done about it. But maybe I am wrong. I see no option to tell gpg to bind the key to some PCRs - that's why I am asking about plans to implement such feature. Yes, AFAIK using PCRs is only possible (and makes sense) when secure boot is enabled. Of course security of such "verified state" depends on perfect (or good enough) implementation all the way from TPM and CPU via UEFI, bootloader, kernel, initramfs to root fs verification. So it's probably not 100% perfect and can have a lot of holes. But it's the only thing (except maybe PIN, if it's used and if it's still secret) that can potentially stop attacker from just booting some LiveCD and unsealing and using the key there. AFAIK in most (all?) cases keys are not stored in TPM but only sealed (encrypted) by it and stored on disk and then unsealed (bound state is verified, if any, key is decrypted and loaded into TPM so it can be used to do further crypto). Not sure about rest of your message and it's relevance to my original question. > I suspect that your ultimate goal might be better satisfied with a USB > connected secure element, with the ability to physically remove it from the > system. An ummarked USB secure element key in a locked drawer full of USB > keys containing endless pictures of cats is what I'd do :-) Not sure how do you know my goals from my original post. :-) Basically we _are_ using USB SEs too. They are "user bound" (user is supposed to carry them all the time) and they often require physical interaction to unseal the key. But for some keys it's more convenient for them to be "machine bound" (forever bound to some computer and only usable if the computer is in a "valid secure state", not necessarily when user is physically present). That's why using TPM is convenient in those cases. For example you may want to store your company VPN key in the TPM (and only allow it to be unsealed if company approved OS is booted and wasn't tampered with) while storing your normal SSH/e-mail/whatever keys in USB SE. If some service (SSH for example) requires both VPN and such USB key you are basically getting double protection. Also note that in such cases some operations (for example backups via VPN) can happen when computer is booted and the TPM key is unsealed but the user and their USB SE can be away while some (for example SSH login via VPN) require both "secure computer" and "physical presence of the user" - it's a matter of policy planning and configuration. -- Grzegorz Kulewski From mcr at sandelman.ca Sat Sep 6 04:26:17 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 05 Sep 2025 22:26:17 -0400 Subject: TPM and PCRs In-Reply-To: <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> <13271.1757100961@obiwan.sandelman.ca> <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> Message-ID: <26263.1757125577@obiwan.sandelman.ca> Grzegorz Kulewski wrote: >> My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the >> main (disk) decryption key is stored in the TPM. It's only protected because >> the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and >> ability to talk to the TPM is restricted. Attacks on this have involved >> hardware access to i2c bus; there are ways to defend against this by >> encrypting that bus using the EK, but in that case, the main CPU has to have >> a copy of the EK public key somewhere safe. > I am not an expert but AFAIK when sealing a secret in TPM you can bind > it to some PCR state (or not). I believe any code that can open TPM I'm not intimately familiar with sealing based upon PCR state. I would hesistate to go this direction because PCR state is rather fragile. (Annoyingly so, and I suspect unnecessarily so) It depends upon the amount of ram installed, BIOS/UEFI options! I think that in some cases, having a bootable USB key inserted, even when it's not used for boot, can change things! > /dev can do this, not something "privileged". But if gpg doesn't do it > then the secret is not protected by any "verified state" bindings and > nothing (except improving gpg and sealing that key again) can be done > about it. But maybe I am wrong. I see no option to tell gpg to bind the > key to some PCRs - that's why I am asking about plans to implement such > feature. I think that one would have to use some tpm2_ or tss-* tools to configure this. I think that after that, it's just a question of having the interface, probably the PKCS11 interface can be used... The abrmd process can mitigate access to /dev/tpm*, and that's mostly how you'd want it. Otherwise, one would be relying on just group permissions on /dev/tpm*. Going via the abrmd allows for the possibility of a richer ACLs in the future too. > Yes, AFAIK using PCRs is only possible (and makes sense) when secure > boot is enabled. Of course security of such "verified state" depends on > perfect (or good enough) implementation all the way from TPM and CPU > via UEFI, bootloader, kernel, initramfs to root fs verification. To be clear: secure boot is when each stage verifies a signature on the next step of boot. The *public* root of trust key can be stored in a TPM for integrity protection. Or burnt into a ROM. Many microcontrollers have eFuses for this purpose. PCRs are generally used for *measured* boot, where each stage measures (SHA256 hash, etc.) the next stage, but does not know how to verify if it's correct or not. This is significantly more democratic. > So > it's probably not 100% perfect and can have a lot of holes. But it's > the only thing (except maybe PIN, if it's used and if it's still > secret) that can potentially stop attacker from just booting some > LiveCD and unsealing and using the key there. > AFAIK in most (all?) cases keys are not stored in TPM but only sealed > (encrypted) by it and stored on disk and then unsealed (bound state is You can do either. TPMs have historically had very limited space for keys, so, yes, one seals the private key with the TPM, and then stores the encrypted blob on disk. But, that space is growing, and fTPMs (a software TPM running in a SGX or TrustZone or other TEE) often have significant space, but obviously how much flash they have access is not infinite. And that flash has to sealed. >> I suspect that your ultimate goal might be better satisfied with a USB >> connected secure element, with the ability to physically remove it from the >> system. An ummarked USB secure element key in a locked drawer full of USB >> keys containing endless pictures of cats is what I'd do :-) > Not sure how do you know my goals from my original post. :-) It's true, I made assumptions. I mean, do you even like cats? And did those cats even consent to have their image used in that way? :-) > Basically we _are_ using USB SEs too. They are "user bound" (user is > supposed to carry them all the time) and they often require physical > interaction to unseal the key. > But for some keys it's more convenient > for them to be "machine bound" (forever bound to some computer and only > usable if the computer is in a "valid secure state", not necessarily > when user is physically present). Yes, I completely agree that this is a desired thing. > That's why using TPM is convenient in > those cases. For example you may want to store your company VPN key in > the TPM (and only allow it to be unsealed if company approved OS is > booted and wasn't tampered with) while storing your normal And just to be clear: in this case, there is often an interaction with the company's Verifier before the VPN key is unlocked. This interaction is often not easily visible. ActiveDirectory is involved. My understanding is that the user login to laptop also unlocks a kerberos ticket that contains the unseal key. (But I'm priviledged to have never really run windows) > SSH/e-mail/whatever keys in USB SE. If some service (SSH for example) > requires both VPN and such USB key you are basically getting double > protection. Also note that in such cases some operations (for example > backups via VPN) can happen when computer is booted and the TPM key is > unsealed but the user and their USB SE can be away while some (for > example SSH login via VPN) require both "secure computer" and "physical > presence of the user" - it's a matter of policy planning and > configuration. All good reasons to have many different kinds of keys. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: