From wk at gnupg.org Tue Mar 4 10:12:31 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Mar 2025 10:12:31 +0100 Subject: Environment variable GNUPGHOME with Windows + MSYS2 In-Reply-To: (Thomas Schweikle via Gnupg-users's message of "Thu, 27 Feb 2025 16:32:29 +0100") References: Message-ID: <87h64988hs.fsf@jacob.g10code.de> On Thu, 27 Feb 2025 16:32, Thomas Schweikle said: > MSYS2 gpg uses "/c/msys/home/%USERNAME%/.gnupg". Now I had the idea to set > GNUPGHOME so both could work with the same directory: Please do not use an MSYS build (or a Cygwin build). This is not supported because GnuPG has full support for Windows and trying to build a mix of a Unix and Window version will eventually run into problems. Further, and more important: We have never done an analysis of such a build regarding the random number generator. Take care not to run into something like the OpenSSL RNG problem Debian once had. You should be able to build GnuPG for Windows on Windows using WSL2 with Ubuntu or (if available Debian Bookworm). Not tested though. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From ThSchweikle at bfs.de Tue Mar 4 15:59:00 2025 From: ThSchweikle at bfs.de (Thomas Schweikle) Date: Tue, 4 Mar 2025 14:59:00 +0000 Subject: Environment variable GNUPGHOME with Windows + MSYS2 In-Reply-To: <87h64988hs.fsf@jacob.g10code.de> References: <87h64988hs.fsf@jacob.g10code.de> Message-ID: <085d9e9d-4aa9-49f4-9f14-81bb6c1dd438@bfs.de> Am 04.03.2025 um 10:12 schrieb Werner Koch via Gnupg-users: > On Thu, 27 Feb 2025 16:32, Thomas Schweikle said: > >> MSYS2 gpg uses "/c/msys/home/%USERNAME%/.gnupg". Now I had the idea to set >> GNUPGHOME so both could work with the same directory: > > Please do not use an MSYS build (or a Cygwin build). You cant. You are forced to do. It is the main problem with Windows: most tools are installed more than once: gpg.exe comes with - git - msys (pacman) - cygwin (cygwin-installer) - RustUp - JuliaUp - Haskel Compiler Platform (GHCup) - FreePascal Development Kit - Arduino IDE - Visual Studio (for some, but not all) - Visual Studio Code - gnupg - GnuPG-VS-Desktop - Gpg4Win All of them compile gpg.exe by them self, most with sources from "https://gnupg.org". Sometimes using older builds (2.2), most use stable (2.4) and a minority use development versions (2.5). > This is not supported because GnuPG has full support for Windows and > trying to build a mix of a Unix and Window version will eventually > run into problems. This was the main problem: Keyrings can be copied between these versions, but all the other files generated might be incompatible and are points you've to look out for -- just do not copy them around. > Further, and more important: We have never done an analysis of such a > build regarding the random number generator. This shouldn't be a point here, since in all cases gpg is used to sign binaries build before packaging for Windows. Or: gpg is used to verify signatures for packaged files loaded and installed from internet servers (GHCup, RustUp, JuliaUp, msys, ArduinoIDE, etc -- btw: most of them rely on msys -- at least for tools) > Take care not to run into something like the OpenSSL RNG problem > Debian once had. As long as you generate your keys only with one of them, this should not matter. > You should be able to build GnuPG for Windows on Windows using WSL2 with > Ubuntu or (if available Debian Bookworm). Not tested though. I've tried and failed to build gpg for Windows on Debian. The same problem arose vice versa: building for Linux on Windows. It is supposed to work, but it seems not something working "out of the box". It wasn't even possible to build on Debian for FreeBSD! But it was ok building for Debian on FreeBSD. -- Thomas From jcb62281 at gmail.com Wed Mar 5 05:49:42 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Tue, 4 Mar 2025 22:49:42 -0600 Subject: RNG requirements (was: Environment variable GNUPGHOME with Windows + MSYS2) In-Reply-To: <085d9e9d-4aa9-49f4-9f14-81bb6c1dd438@bfs.de> References: <87h64988hs.fsf@jacob.g10code.de> <085d9e9d-4aa9-49f4-9f14-81bb6c1dd438@bfs.de> Message-ID: <00f75cd1-1f69-4226-8035-e68ced4621d8@gmail.com> On 3/4/25 08:59, Thomas Schweikle via Gnupg-users wrote: > Am 04.03.2025 um 10:12 schrieb Werner Koch via Gnupg-users: > [...] >> Further, and more important: We have never done an analysis of such a >> build regarding the random number generator. > This shouldn't be a point here, since in all cases gpg is used to sign > binaries build before packaging for Windows. [...] Some signature schemes require random numbers and, if I remember correctly, can *leak* *the* *private* *key* if the RNG has insufficient entropy.? This is one of the more severe weaknesses in Schnorr-type signatures, which include DSA. Newer implementations avoid the problem by using deterministic nonces, computed using a hash of the message and private key or similar.? EdDSA specifies this approach and some ECDSA implementations also use it.? (DSA was thoroughly obsolete due to its fixed 1024-bit key size before deterministic nonces were introduced.) >> Take care not to run into something like the OpenSSL RNG problem >> Debian once had. > As long as you generate your keys only with one of them, this should not > matter. It would matter very much if the one you happened to pick for key generation happened to be the one with the bad RNG!? (And see above for the possibility of leaking private keys by using a bad RNG while making a signature.) The only operation that is definitely safe is signature verification.? Decryption is safe against a bad RNG, but PGP message encryption needs a good RNG for the session key---a weak RNG could make the session key guessable and completely bypass the public key algorithm for an attacker. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-gnumlists at wisemo.com Fri Mar 7 02:36:33 2025 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Fri, 7 Mar 2025 02:36:33 +0100 Subject: RNG requirements In-Reply-To: <00f75cd1-1f69-4226-8035-e68ced4621d8@gmail.com> References: <87h64988hs.fsf@jacob.g10code.de> <085d9e9d-4aa9-49f4-9f14-81bb6c1dd438@bfs.de> <00f75cd1-1f69-4226-8035-e68ced4621d8@gmail.com> Message-ID: Dear Mr. Backmeyer, First, notice that Mr. Schweikle explained that their issue is being forced to use 3rd party builds of GnuPG because 3rd party software suites use those builds to /verify/ signatures, not make them. Secondly, at least one of those suites (GIT) happens to also use their private build for signing stuff, so (only) for those things are still relevant. Thirdly your rant would be much more helpful if you bothered to check (and report) if the relevant ECDSA countermeasures.? This is for you to check as you are the one claiming to know about GnuPG internals. On 3/5/2025 05:49:42, Jacob Bachmeyer via Gnupg-users wrote: > On 3/4/25 08:59, Thomas Schweikle via Gnupg-users wrote: >> Am 04.03.2025 um 10:12 schrieb Werner Koch via Gnupg-users: >> [...] >>> Further, and more important: We have never done an analysis of such a >>> build regarding the random number generator. >> This shouldn't be a point here, since in all cases gpg is used to sign >> binaries build before packaging for Windows. [...] > > Some signature schemes require random numbers and, if I remember > correctly, can *leak* *the* *private* *key* if the RNG has > insufficient entropy.? This is one of the more severe weaknesses in > Schnorr-type signatures, which include DSA. > > Newer implementations avoid the problem by using deterministic nonces, > computed using a hash of the message and private key or similar.? > EdDSA specifies this approach and some ECDSA implementations also use > it.? (DSA was thoroughly obsolete due to its fixed 1024-bit key size > before deterministic nonces were introduced.) > >>> Take care not to run into something like the OpenSSL RNG problem >>> Debian once had. >> As long as you generate your keys only with one of them, this should not >> matter. > > It would matter very much if the one you happened to pick for key > generation happened to be the one with the bad RNG!? (And see above > for the possibility of leaking private keys by using a bad RNG while > making a signature.) > > The only operation that is definitely safe is signature verification.? > Decryption is safe against a bad RNG, but PGP message encryption needs > a good RNG for the session key---a weak RNG could make the session key > guessable and completely bypass the public key algorithm for an attacker. > > 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 wk at gnupg.org Fri Mar 7 15:21:21 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Mar 2025 15:21:21 +0100 Subject: [Announce] GnuPG 2.5.5 released Message-ID: <878qpg6hwe.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.5. This release is another one in a series of public testing releases eventually leading to a new stable version 2.6. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of Kyber (FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.5 (2025-03-07) ================================================ [compared to version 2.5.4] * gpg: Fix a verification DoS due to a malicious subkey in the keyring. [T7527] * dirmngr: Fix possible hangs due to blocking connection requests. [T6606, T7434] * w32: On socket nonce mismatch close the socket. [T7434] * w32: Print more detailed diagnostics for IPC errors. * GPGME is not any more distributed with the Windows installer. Please install gpg4win to get gpgme version. Release-info: https://dev.gnupg.org/T7530 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.5.tar.bz2 (7989k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.5.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.5_20250307.exe (5486k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.5_20250307.exe.sig The source used to build this installer for 64-bit Windows is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.5_20250307.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.5_20250307.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. A new Beta version of Gpg4win, our full featured installer for Windows including this version of GnuPG as well as Kleopatra GUI and a PDF editor will soon be available at https://www.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.5.tar.bz2 you would use this command: gpg --verify gnupg-2.5.5.tar.bz2.sig gnupg-2.5.5.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.5.tar.bz2, you run the command like this: sha1sum gnupg-2.5.5.tar.bz2 and check that the output matches the next line: b14ca751786112b3bb6686a462415c2896ceb73d gnupg-2.5.5.tar.bz2 552744d7f930c8905ad052c36b7ab06ce0d9ad25 gnupg-w32-2.5.5_20250307.tar.xz 0bfe05298d4f7953f4bb0361785003e859c39242 gnupg-w32-2.5.5_20250307.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/T7530 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jcb62281 at gmail.com Sat Mar 8 04:10:42 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 7 Mar 2025 21:10:42 -0600 Subject: RNG requirements In-Reply-To: References: <87h64988hs.fsf@jacob.g10code.de> <085d9e9d-4aa9-49f4-9f14-81bb6c1dd438@bfs.de> <00f75cd1-1f69-4226-8035-e68ced4621d8@gmail.com> Message-ID: <607916d8-16b1-4f80-8c24-2a37e1893c85@gmail.com> On 3/6/25 19:36, Jakob Bohm via Gnupg-users wrote: > Dear Mr. Backmeyer, > > First, notice that Mr. Schweikle explained that their issue is being > forced > to use 3rd party builds of GnuPG because 3rd party software suites use > those > builds to /verify/ signatures, not make them. I specifically said that verifying signatures is safe, at least with respect to RNG issues. > Secondly, at least one of those suites (GIT) happens to also use their > private build for signing stuff, so (only) for those things are still > relevant. Mr. Schweikle's statements suggested to me that he did not believe Werner Koch's warning to be relevant to his use. Mr. Koch stated that he cannot be certain that the RNG in those builds is sound; Mr. Schweikle appeared to be dismissing the concern on the grounds that he was not using them to generate keys. > Thirdly your rant would be much more helpful if you bothered to check > (and report) if the relevant ECDSA countermeasures.? This is for you > to check as you are the one claiming to know about GnuPG internals. I do not claim (much) knowledge of GnuPG internals.? I specifically quoted Werner Koch, who is probably *the* expert on GnuPG internals, warning that he had never examined the RNG on those builds and of the possibility of a bad RNG. Further, checking those countermeasures would require tracking down all of the Windows builds at issue and determining if they are "clean" builds of upstream sources or if they have any patches that could affect their security, and I do not use Windows. It is *not* on me to check, because I do not use those builds of GnuPG. -- Jacob From bernhard at intevation.de Tue Mar 11 09:09:08 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 11 Mar 2025 09:09:08 +0100 Subject: how many qubits are needed - BSI report 2022 (Re: deflating heffalumps) In-Reply-To: <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> Message-ID: <202503110909.14724.bernhard@intevation.de> Jacob, Am Freitag 03 Januar 2025 02:31:43 schrieb Jacob Bachmeyer via Gnupg-users: > I have been looking for hard numbers for the applicability of Shor's > algorithm to RSA for a long time.? take a look at Quantum-safe cryptography ? fundamentals, current developments and recommendations, BSI from 18.05.2022 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626 and the referenced study, it is a few years old now, but it explains the principles as far as I understand it. Regards, Bernhard -------------- 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 bwalzer at 59.ca Tue Mar 11 11:59:36 2025 From: bwalzer at 59.ca (Bruce Walzer) Date: Tue, 11 Mar 2025 05:59:36 -0500 Subject: how many qubits are needed - BSI report 2022 (Re: deflating heffalumps) In-Reply-To: <202503110909.14724.bernhard@intevation.de> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <202503110909.14724.bernhard@intevation.de> Message-ID: On Tue, Mar 11, 2025 at 09:09:08AM +0100, Bernhard Reiter via Gnupg-users wrote: [...] > Quantum-safe cryptography ? fundamentals, current developments and > recommendations, BSI > from 18.05.2022 > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626 > > and the referenced study, it is a few years old now, but it explains the > principles as far as I understand it. Three years old in particular. That was a time when whe quantum threat to crytpography seemed a lot more real. Now it is understood that error correction will not be possibly useful until the noise performance of physical qubits can be improved by a factor of 1-2 orders of magnitude. Since no one knows how to do that, we are back in the position where some sort of fundamental breakthrough will be required to progress further. So the predictions in the linked file are invalid. Progress could come tomorrow or never. Bruce From fg.gnupg at shimps.de Mon Mar 17 12:33:06 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Mon, 17 Mar 2025 12:33:06 +0100 Subject: WKD new online-checker and suggestion for the WKD spec In-Reply-To: <202502191659.40247.bernhard@intevation.de> References: <202502191659.40247.bernhard@intevation.de> Message-ID: <20250317123306.389d8e58@incubator.example.net> On Wed, 19 Feb 2025 16:59:33 +0100 Bernhard Reiter via Gnupg-users wrote: > > https://webkeydirectory.com > > [...] > the SHOULD content-type is indicated in red, but I've also learned > that my policy file had a defect. So it is useful. :) > > [...] > > the checker also recommends to set > The Access-Control-Allow-Origin: * header is needed to allow > OpenPGP clients to fetch the policy from a different domain, > bypassing CORS restrictions. This is indeed a nice tool which helps fine tuning the configuration and debugging errors. Three resolved issues (and one open but understood) in less than four weeks make the admin smile at least a little while and are a reasonably good count. For user only (non-root) permission environments, e.g. webspace but not server contracts, I figured out the following htaccess lines to be helpful for apache web server: ----> Header add Access-Control-Allow-Origin "*" ForceType application/octet-stream <---- In server environments with root permission to edit the main configuration of a vhost it might be good advice to restrict those to a path (and ifmodule mod_mime.c) dependent substructure. I improved both kinds of situation to a full green output and learned a few things. -- 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 kmp.lists+gpgusers at gmail.com Sat Mar 22 22:16:38 2025 From: kmp.lists+gpgusers at gmail.com (K. M. Peterson) Date: Sat, 22 Mar 2025 17:16:38 -0400 Subject: What is Werner's key? (Or - who signs gnupg-announce mails?) Message-ID: Hi all, I apologize in advance is this is somehow naive or ignorant. I've been using PGP/GPG for nearly 30 years, but haven't had a need to build expertise past the point of casual use. I'm primarily a macOS user, and I'm running the GPGTools variant of GnuPG. I am still somewhat unclear about and sadly unaware of the current state of the world of keyservers; though I know that GPGTools has standardized on keys.openpgp.org and that there's been some discussion around that. While the gnupg-announce emails cover where/how to verify the artifacts from the project, the emails themselves I receive seem to be signed by a key that I'm unable to either verify nor add to my keyring to trust. In particular, my client informs me that the mail is signed by a key with fingerprint 0x8777461F2A074EBC480D359419CC1C9E085B107A - but I can't find that on any of the keyservers that I can access. I'd be very happy to read up if there's an answer to this involving some element of the structure of GPG keys that I haven't gotten to understand (e.g., subkeys and their relationships to the "primary" key?) but effectively I'm just looking for the shortest path to get rid of the verification error in my client - though I wouldn't necessarily plan to fully trust that identity. I think I'm clearly missing something, but I don't know what. (I'm not signing this message as I use Gmail for subscribing to most mailing lists, though my keys should be available via WKS as well as at least some subset of the keyserver web as kmp-gpgkey at kmp.name.) Thanks, and again I'm sorry if this should have been an RTFM moment. _KMP -------------- next part -------------- An HTML attachment was scrubbed... URL: From fg.gnupg at shimps.de Sun Mar 23 18:07:31 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Sun, 23 Mar 2025 18:07:31 +0100 Subject: What is Werner's key? (Or - who signs gnupg-announce mails?) In-Reply-To: References: Message-ID: <20250323180731.5102e093@incubator.example.net> On Sat, 22 Mar 2025 17:16:38 -0400 "K. M. Peterson via Gnupg-users" wrote: > > I am still somewhat unclear about and sadly unaware of the current > state of the world of keyservers; The keyserver concept is broken since there were some attacks in the past, and there are GDPR issues, too. A modified setup is still available, but WKD is an alternative and some users' keys are here and some there. > While the gnupg-announce emails cover where/how to verify the > artifacts from the project, the emails themselves I receive seem to > be signed by a key that I'm unable to either verify nor add to my > keyring to trust. In particular, my client informs me that the mail > is signed by a key with fingerprint > 0x8777461F2A074EBC480D359419CC1C9E085B107A - but I can't find that on > any of the keyservers that I can access. This seems to be Werner's key, but it is the fingerprint of a subkey. The key is AFAIK not on a keyserver but it should be available via WKD: $ gpg -v --auto-key-locate clear,wkd,nodefault --locate-external-keys wk at gnupg.org Once Werner's key is imported or updated, it should show up: $ gpg --list-keys --with-fingerprint --with-fingerprint | grep -B2 "8777 461F 2A07 4EBC 480D 3594 19CC 1C9E 085B 107A" The option for the fingerprint is invoked twice. -- 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 Mon Mar 24 13:47:28 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Mar 2025 13:47:28 +0100 Subject: What is Werner's key? (Or - who signs gnupg-announce mails?) In-Reply-To: <20250323180731.5102e093@incubator.example.net> References: <20250323180731.5102e093@incubator.example.net> Message-ID: <202503241347.36638.bernhard@intevation.de> Am Sonntag 23 M?rz 2025 18:07:31 schrieb Frank Guthausen: > The keyserver concept is broken since there were some > attacks in the past, and there are GDPR issues, too. I consider the concept still valid. For key discovery and a fall back for revoking keys. Only the web of trust part has become under pressure as no-one has put in the work to make keyservers carry third party signatures again. (It is possible and there are not GDPR issues.) > A modified setup is still available, but WKD is an alternative > and some users' keys are here and some there. WKD is very cool (I guess I am considered biased, as I was the project lead when WKD was developed as part of a BSI contract.) But WKD only works for email bound pubkeys. There are other use cases without email where the discovery of pubkeys work well with pub key erver. The new keyserver network is https://spider.pgpkeys.eu/sks-peers 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 konstantin at linuxfoundation.org Mon Mar 24 21:21:31 2025 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Mon, 24 Mar 2025 16:21:31 -0400 Subject: How to fix keys with sha1 subkey/uid signatures? Message-ID: <20250324-flashy-mysterious-sambar-a57bc9@meerkat> Hello: What's the recommended way to update your key so there are no subkeys/uids remaining with weak digests? I've managed to get it accomplished by running a series of "--quick-set-primary-uid" to update digests on the UIDs and by using "--quick-set-expire 1y" followed by "--quick-set-expire 0" on the subkeys, but seems like there should probably be a less clunky method of accomplishing the same, like a subcommand to use with "--edit-key"? -K From wk at gnupg.org Tue Mar 25 09:30:50 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Mar 2025 09:30:50 +0100 Subject: What is Werner's key? In-Reply-To: <20250323180731.5102e093@incubator.example.net> (Frank Guthausen's message of "Sun, 23 Mar 2025 18:07:31 +0100") References: <20250323180731.5102e093@incubator.example.net> Message-ID: <87bjtpa4w5.fsf_-_@jacob.g10code.de> On Sun, 23 Mar 2025 18:07, Frank Guthausen said: > $ gpg --list-keys --with-fingerprint --with-fingerprint | grep -B2 > "8777 461F 2A07 4EBC 480D 3594 19CC 1C9E 085B 107A" gpg --fingerprint is much easier to remember and is actually one of the oldest gpg commands. However, the old human readable format for fingerprints is not easy to c+p and thus the default for "gpg -k" has been changed to: pub ed25519 2018-09-28 [SC] [expires: 2027-01-31] AEA84EDCF01AD86C4701C85C63113AE866587D0A uid [ultimate] wk at gnupg.org [...] Which makes it easy to c+p the fingerprint. Shalom-Salam, Werner p.s. FWIW, thre is yet another option to help read aloud the fingerprint: $ gpg -k --with-icao-spelling 085b107A pub ed25519 2018-09-28 [SC] [expires: 2027-01-31] AEA84EDCF01AD86C4701C85C63113AE866587D0A "Alfa Echo Alfa Eight Four Echo Delta Charlie Foxtrot Zero One Alfa Delta Eight Six Charlie Four Seven Zero One Charlie Eight Five Charlie Six Three One One Three Alfa Echo Eight Six Six Five Eight Seven Delta Zero Alfa" -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: key_wk at gnupg.org.asc Type: application/pgp-keys Size: 5140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From bernhard at intevation.de Tue Mar 25 15:11:07 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Mar 2025 15:11:07 +0100 Subject: CVE-2025-30258 (was: [Announce] GnuPG 2.5.5 released) In-Reply-To: <878qpg6hwe.fsf@jacob.g10code.de> References: <878qpg6hwe.fsf@jacob.g10code.de> Message-ID: <202503251511.15023.bernhard@intevation.de> Am Freitag 07 M?rz 2025 15:21:21 schrieb Werner Koch via Gnupg-users: > ? * gpg: Fix a verification DoS due to a malicious subkey in the > ? ? keyring. ?[T7527] Someone assigned a low/medium CVE number for this vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2025-30258 As 2.4 stable has gotten the fix, I assume 2.4.7 is vulnerable as well. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/STABLE-BRANCH-2-4 What is the timeline for releasing 2.4.8? 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 Tue Mar 25 16:23:46 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Mar 2025 16:23:46 +0100 Subject: on "vulnerabilities" (Re: CVE-2025-30258 (was: [Announce] GnuPG 2.5.5 released)) In-Reply-To: <202503251511.15023.bernhard@intevation.de> References: <878qpg6hwe.fsf@jacob.g10code.de> <202503251511.15023.bernhard@intevation.de> Message-ID: <202503251623.52576.bernhard@intevation.de> Am Dienstag 25 M?rz 2025 15:11:07 schrieb Bernhard Reiter via Gnupg-users: > omeone assigned a low/medium CVE number for this vulnerability: To clarify, I wrote While by common definitions, this defect is a software vulnerability, the low CVSSv3 (2.7 by Redhat) shows that it is not something which needs a quick fix. Even a CVE number is not really helpful. The reasons are: * if defects like this get CVE numbers, then many regular improvements in software development would need to get one. Which is too many to be useful. The significant vulnerabilities that must be fixed quickly would be drowned within regular _fixes_. * the term _vulnerability_ sometimes triggers the need for a patch or a fast fix - out of the regular schedule. Those fixes come with their own risks because of the accelerated development. As we have a low severity thing here, a quick fix is potentially less secure than a regular maintenance release. In that sense we do not have a _vulnerability_ - as we do not need a quick fix and it is more like a regular defect for which there are many. to https://forum.gnupg.org/t/any-new-gpg4win-update-beyond-version-4-4-0-planned/6402/7?u=bernhard Bernhard -------------- 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 fg.gnupg at shimps.de Tue Mar 25 18:05:17 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Tue, 25 Mar 2025 18:05:17 +0100 Subject: What is Werner's key? In-Reply-To: <87bjtpa4w5.fsf_-_@jacob.g10code.de> References: <20250323180731.5102e093@incubator.example.net> <87bjtpa4w5.fsf_-_@jacob.g10code.de> Message-ID: <20250325180517.55498fe4@incubator.example.net> On Tue, 25 Mar 2025 09:30:50 +0100 Werner Koch via Gnupg-users wrote: > On Sun, 23 Mar 2025 18:07, Frank Guthausen said: > > > $ gpg --list-keys --with-fingerprint --with-fingerprint | grep -B2 > > "8777 461F 2A07 4EBC 480D 3594 19CC 1C9E 085B 107A" > > gpg --fingerprint > > is much easier to remember and is actually one of the oldest gpg > commands. However, the old human readable format for fingerprints is > not easy to c+p and thus the default for "gpg -k" has been changed to: > > pub ed25519 2018-09-28 [SC] [expires: 2027-01-31] > AEA84EDCF01AD86C4701C85C63113AE866587D0A > uid [ultimate] wk at gnupg.org > [...] > > Which makes it easy to c+p the fingerprint. The confusion was about the shown fingerprint of the subkey, starting with 8777 rather than AEA8. -- 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 kevinotech at proton.me Wed Mar 26 12:47:44 2025 From: kevinotech at proton.me (kevinotech at proton.me) Date: Wed, 26 Mar 2025 11:47:44 +0000 Subject: kleopatra flatpak issue Message-ID: hello everyone , this i my first question on the mailing list :) . Hopefully this is the right place to ask questions?related?to?kleopatra.? i am using kleopatra (flatpak version) on my Linux mint 22.1 (base noble) machine and? when i am doing any function like encryption or decryption on kleopatra, the actual operation is a success but on inspecting the audit log i am seeing the following warning messages. > gpg: WARNING: server 'keyboxd' is older than us (2.4.4 < 2.5.1)gpg: WARNING: server 'gpg-agent' is older than us (2.4.4 < 2.5.1) > gpg: Note: Outdated servers may lack important security fixes. > gpg: Note: Use the command "gpgconf --kill all" to restart them kelopatra?about section shows ?gpg version?2.5.1 and libgcrypt version? 1.11.0? but my linux system?has??gpg version 2.4.4. and libgcrypt v 1.10.3. So the?warning may indicate that kleopatra might still be using my host systems gpg-agent and keyboxd. I? tried the suggested fix for it by killing gpg-agent but even after many tries the warning still persist. While most people would just ignore such warning as the operation still works but i decided to dig in to find a solution for this.(hopefully? also push ubuntu to upgrade their gpg packaged version). I suspect this could be related to some systemd service of the gpg-agent or keyboxd of the host which is set to restart automatically , thus causing conflicts. Though i am not entirely sure of this.?A? solution for this would to manually install the updated version of gpg on my system and set it as default path but that won't solve the issue permanently and may not be desirable step in every case. Usually flatpaks bring their own binary version so it must be able to leverage the updated versions of gpg.?Also to note that i had earlier manually changed the keydatabse method from keyring.kbx to keyboxd as per instuctions in docs , but the behaviour should remain the same.? Here is my complete build info for kleopatra and system info. > Kleopatra: 4.0.0.241203 (24.12.3) , KDE Frameworks: 6.12.0, Qt: Using 6.8.2 and built against 6.8.2, KDE Flatpak runtime (Xcb), Build ABI: x86_64-little_endian-lp64, Kernel: linux 6.8.0-56-generic > System info -?Distro: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble,??Kernel: 6.8.0-56-generic arch: x86_64 Any suggestions for tackling this problem is greatly appreciated.?Also thanks to developers for their work on gnupg Its a? wonderful free software and i have been reading into a lot details lately :) Best regards kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - kevinotech at proton.me - 0xF9F43E49.asc Type: application/pgp-keys Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From kevinotech at proton.me Wed Mar 26 16:43:38 2025 From: kevinotech at proton.me (kevinotech at proton.me) Date: Wed, 26 Mar 2025 15:43:38 +0000 Subject: kleopatra flatpak issue In-Reply-To: References: Message-ID: Okay so an update on this issue , if i am correct this may not really be an issue with kleopatra flatpak itself and things might be running as expected. After posting here I went to the bug kde bug tracking system to see similar issues reported? and i saw? an informational bug ticket which said "Kleopatra?`needs a running gpg-agent from the host to work"`.Bug report link?https://bugs.kde.org/show_bug.cgi?id=459041 So? from this i conclude that flatpak indeed needs to rely on the host gpg-agent to conduct the crypto operations. Possibly reasons could be because gpg-agent daemon needs system integration to perform the secret operations in secure manner which flatpaks can't probably do with its sandbox approach. I am no expert in Linux packaging but this is what i assume something related to this . Though i feel the warning messages are incorrect , as killing gpg-agent won't use newer versions of gpg-agent automatically. In a related issue to this issue , can someone tell the proper steps to follow for changing all the gpg-agent.service , scdaemon.service and keyboxd.service files when manually compiling gpg to updated versions .?For example i had compiled and installed the latest package and dependencies in the directory `/usr/local/bin'? and added this to path . But still the older gpg-agent and scdaemon were running despite killing and restarting multiple times. Also on most linux systems removing the default gnupg installation is not possible as core DE components and applications rely on it.?I checked the docs but it seems this information is not properly documented. So a list of files i need to check including config changes would be helpful. Thanking you kevin On Wednesday, 26 March 2025 at 17:17, kevinotech at proton.me wrote: > hello everyone , this i my first question on the mailing list :) . Hopefully this is the right place to ask questions?related?to?kleopatra.? > i am using kleopatra (flatpak version) on my Linux mint 22.1 (base noble) machine and? when i am doing any function like encryption or decryption on kleopatra, the actual operation is a success but on inspecting the audit log i am seeing the following warning messages. > > > gpg: WARNING: server 'keyboxd' is older than us (2.4.4 < 2.5.1)gpg: WARNING: server 'gpg-agent' is older than us (2.4.4 < 2.5.1) > > gpg: Note: Outdated servers may lack important security fixes. > > gpg: Note: Use the command "gpgconf --kill all" to restart them > > > > kelopatra?about section shows ?gpg version?2.5.1 and libgcrypt version? 1.11.0? but my linux system?has??gpg version 2.4.4. and libgcrypt v 1.10.3. So the?warning may indicate that kleopatra might still be using my host systems gpg-agent and keyboxd. I? tried the suggested fix for it by killing gpg-agent but even after many tries the warning still persist. While most people would just ignore such warning as the operation still works but i decided to dig in to find a solution for this.(hopefully? also push ubuntu to upgrade their gpg packaged version). I suspect this could be related to some systemd service of the gpg-agent or keyboxd of the host which is set to restart automatically , thus causing conflicts. Though i am not entirely sure of this.?A? solution for this would to manually install the updated version of gpg on my system and set it as default path but that won't solve the issue permanently and may not be desirable step in every case. Usually flatpaks bring their own binary version so it must be able to leverage the updated versions of gpg.?Also to note that i had earlier manually changed the keydatabse method from keyring.kbx to keyboxd as per instuctions in docs , but the behaviour should remain the same.? > Here is my complete build info for kleopatra and system info. > > > Kleopatra: 4.0.0.241203 (24.12.3) , KDE Frameworks: 6.12.0, Qt: Using 6.8.2 and built against 6.8.2, KDE Flatpak runtime (Xcb), Build ABI: x86_64-little_endian-lp64, Kernel: linux 6.8.0-56-generic > > System info -?Distro: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble,??Kernel: 6.8.0-56-generic arch: x86_64 > > Any suggestions for tackling this problem is greatly appreciated.?Also thanks to developers for their work on gnupg Its a? wonderful free software and i have been reading into a lot details lately :) > > Best regards > kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - kevinotech at proton.me - 0xF9F43E49.asc Type: application/pgp-keys Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Wed Mar 26 18:10:52 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Wed, 26 Mar 2025 18:10:52 +0100 Subject: kleopatra flatpak issue In-Reply-To: References: Message-ID: <3770714.dWV9SEqChM@daneel> Hi, usually we reply with inline comments instead of with a full quote of everything. On Mittwoch, 26. M?rz 2025 16:43:38 Mitteleurop?ische Normalzeit kevin via Gnupg-users wrote: > Okay so an update on this issue , if i am correct this may not really be an > issue with kleopatra flatpak itself and things might be running as > expected. After posting here I went to the bug kde bug tracking system to > see similar issues reported and i saw an informational bug ticket which > said "Kleopatra `needs a running gpg-agent from the host to work"`.Bug > report link https://bugs.kde.org/show_bug.cgi?id=459041 So from this i > conclude that flatpak indeed needs to rely on the host gpg-agent to conduct > the crypto operations. I have no idea if this is a limitation of flatpaks in general or just of this specific flatpak. The warning issued by gpg is a warning that things might go wrong if the daemon running outside of the flatpak are too old. > Possibly reasons could be because gpg-agent daemon > needs system integration to perform the secret operations in secure manner > which flatpaks can't probably do with its sandbox approach. I am no expert > in Linux packaging but this is what i assume something related to this . > Though i feel the warning messages are incorrect , as killing gpg-agent > won't use newer versions of gpg-agent automatically. If your system uses gpg-agent with systemd socket activation then it's almost impossible to start a different gpg-agent. I'm not sure whether keeping the gpg-agent outside of the flatpak isn't just a workaround for this behavior. In any case, it's a good idea to keep the gpg-agent which is the one that handles the secret key material outside of the flatpak. > In a related issue to this issue , can someone tell the proper steps to > follow for changing all the gpg-agent.service , scdaemon.service and > keyboxd.service files when manually compiling gpg to updated versions . For > example i had compiled and installed the latest package and dependencies in > the directory `/usr/local/bin' and added this to path . But still the > older gpg-agent and scdaemon were running despite killing and restarting > multiple times. The problem is systemd. You have to disable socket activation for GnuPG's sockets. Search the internet for advice. The developers of GnuPG consider this socket activation "feature" an abomination. All tools of the GnuPG suite start the correct gpg-agent (i.e. the one you have built yourself) on demand. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From kevinotech at proton.me Wed Mar 26 21:44:32 2025 From: kevinotech at proton.me (kevinotech at proton.me) Date: Wed, 26 Mar 2025 20:44:32 +0000 Subject: kleopatra flatpak issue In-Reply-To: <3770714.dWV9SEqChM@daneel> References: <3770714.dWV9SEqChM@daneel> Message-ID: hello , thanks for your reply, It helped me a lot! On Wednesday, 26 March 2025 at 22:40, Ingo Kl?cker wrote: > usually we reply with inline comments instead of with a full quote of > everything. Ohh sorry i didn't know. Will follow this format now ! > The problem is systemd. You have to disable socket activation for GnuPG's > sockets. Search the internet for advice. The developers of GnuPG consider this > socket activation "feature" an abomination. All tools of the GnuPG suite start > the correct gpg-agent (i.e. the one you have built yourself) on demand. Thanks for the advice ,i have disabled all systemd socket activation for gpg services and it works perfectly. i see that all tools are automatically started by themselves when needed by a application without needing a systemd service to start them. :) I wonder why ubuntu still uses this. > I have no idea if this is a limitation of flatpaks in general or just of this > specific flatpak. The warning issued by gpg is a warning that things might go > wrong if the daemon running outside of the flatpak are too old. So yeah about kleopatra flatpak, i see that after removing the socket services and killing all running gpg services by `gpgconf --kill all` i tried opening keloptra (flatpak) to see if it invokes the system gpg-agent and does all the functions but i noticed that it failed any signing , encryption or decryption functions. It could not even list the keys from keyboxd that were imported earlier. So it seems maybe the flatpak version doesn't have its own gpg-agent or maybe this is an actual bug or a limitation with flatpak that it couldn't invoke system gpg services or use its own. I even confirmed this behaviour on a fedora VM which doesn't have any systemd sockets configured by default and kleopatra fails to work on it by itself. I even confirmed with the gpa app and it was able to start gpg services by itself , so its not an issue with my system. > In any case, it's a good idea to keep the gpg-agent which is the one that handles > the secret key material outside of the flatpak. Thanks for the pointer , i will keep this in mind, though currently it seems kleopatra won't work without the host gpg-agent running already. Regards, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - kevinotech at proton.me - 0xF9F43E49.asc Type: application/pgp-keys Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Thu Mar 27 03:12:26 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 26 Mar 2025 21:12:26 -0500 Subject: kleopatra flatpak issue In-Reply-To: References: <3770714.dWV9SEqChM@daneel> Message-ID: <73b741ff-7b39-42bd-8a77-5802975434df@gmail.com> On 3/26/25 15:44, kevin via Gnupg-users wrote: > [...] > So yeah about kleopatra flatpak, i see that after removing the socket services and killing all running gpg services by `gpgconf --kill all` i tried opening keloptra (flatpak) to see if it invokes the system gpg-agent and does all the functions but i noticed that it failed any signing , encryption or decryption functions. It could not even list the keys from keyboxd that were imported earlier. So it seems maybe the flatpak version doesn't have its own gpg-agent or maybe this is an actual bug or a limitation with flatpak that it couldn't invoke system gpg services or use its own. [...] I will speculate that the flatpak sandbox allows access to the "system" keyboxd and gpg-agent sockets but *not* to the actual keyring files. I am unsure how much of a security boundary that actually is:? is access to keyboxd equivalent to access to the underlying keyrings? -- Jacob From wk at gnupg.org Fri Mar 28 19:10:35 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 28 Mar 2025 19:10:35 +0100 Subject: What is Werner's key? In-Reply-To: <20250325180517.55498fe4@incubator.example.net> (Frank Guthausen's message of "Tue, 25 Mar 2025 18:05:17 +0100") References: <20250323180731.5102e093@incubator.example.net> <87bjtpa4w5.fsf_-_@jacob.g10code.de> <20250325180517.55498fe4@incubator.example.net> Message-ID: <878qop81r8.fsf@jacob.g10code.de> On Tue, 25 Mar 2025 18:05, Frank Guthausen said: > The confusion was about the shown fingerprint of > the subkey, starting with 8777 rather than AEA8. That is one of the subkeys. If you like to always see the finperints of all subkeys you may put with-subkey-fingerprint into your gpg.conf. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: