From wk at gnupg.org Sun Jun 1 14:33:47 2025 From: wk at gnupg.org (Werner Koch) Date: Sun, 01 Jun 2025 14:33:47 +0200 Subject: Deterministic signatures digest prefix In-Reply-To: <7250158c71b8088a04b12a489615ec66d6601212.camel@aminagroup.com> (Richard Ulrich via Gnupg-users's message of "Thu, 29 May 2025 12:55:25 +0000") References: <7250158c71b8088a04b12a489615ec66d6601212.camel@aminagroup.com> Message-ID: <87o6v7d4k4.fsf@jacob.g10code.de> On Thu, 29 May 2025 12:55, Richard Ulrich said: > grub can verify them when the system boots. Most of the DVD ISO builds > reproducibly. At the moment I am trying to get also those signatures > reproducible. DSA style signatures created using the RFC-6979 method are at their core deterministic. However, the question is what you want to achieve with this: The party who wants to create such a signature needs access to the smartcard used to create the signature in the first place. Even if you don't use a smartcard (you do, right?), you would need to share the private key - so what's the point of the signature then? Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From kyrieuon at gmail.com Sun Jun 1 16:54:19 2025 From: kyrieuon at gmail.com (Richard Stoughton) Date: Sun, 1 Jun 2025 16:54:19 +0200 Subject: Signing a file given its hash only In-Reply-To: <87plg3ln0b.fsf@jacob.g10code.de> References:

<87plg3ln0b.fsf@jacob.g10code.de> Message-ID: On Tue, May 20, 2025 at 10:09?AM Werner Koch wrote: > > On Mon, 19 May 2025 15:40, Richard Stoughton said: > > > creates the final signatures. This could be done in a much more > > efficient way if GnuPG would be able to create signatures with hashes > > instead of the complete file content as input. > > Many years ago we pondered wit this idea. However it is complicated > because *PGP does not simpluy sign a hash but has a prefix and a suffix > to append. Thus for signing we would need to provide a tool which takes > some internal hash context, continue to has the file, and let gpg > finalize the hashing. This is a bit ugly and would raise problems with > certifications etc. OK, I see that by signing a hash it is not feasible to obtain the signature for the file hashed. So we'll try another approach to preserve the security level of M on L: H injects a secret nonce into a build run on M. M uses the nonce to create a MAC for each artifact it creates. M pushes the MACs along with the artifacts to L. To sign an artifact H fetches the artifact and the corresponding MAC to its local file system. Then H verifies the MAC using the secret nonce it has previously injected into the build on M. If the MAC is valid then H signs the artifact using gpg. Then H pushes the signature to L. > Our solution was to to implement remote signing. This allows to do the > private key operations on your machines while the actual hashing and > signing is done on the server. From a security POV this is the same as > running only the bulk hashing on the server. I don't think that I can use remote signing in our use case. If L is compromized, an attacker could possibly spoof the artifact presented to the MAC validation while letting gpg sign a compromized artifact. From kyrieuon at gmail.com Sun Jun 1 19:06:42 2025 From: kyrieuon at gmail.com (Richard Stoughton) Date: Sun, 1 Jun 2025 19:06:42 +0200 Subject: Signing a file given its hash only In-Reply-To: References: <96f0eb8c3abe8029d1093e03d9f28166a864c7b3c7839cca@smtp.hushmail.com> Message-ID: On Wed, May 14, 2025 at 11:56?PM Chris DeYoung wrote: > > > > Artifacts that must be signed are produced on M which is capable of > > calculating hashes (e.g. SHA-256 hashes). H has the ability to read > > these hashes but cannot access the artifacts. > > How does H know that the hash is valid? H could just sign the hash if it > trusts what M generates, but it isn't obvious to me how that's more > secure than just having M sign it. You're right. If M or the input of M is compromized then H will possibly sign compromized artifacts. The security of the complete process is limited by M. The purpose of H is solely to limit access to the private signature key. M signing the artifacts by itself would require the key to float around. From kyrieuon at gmail.com Sun Jun 1 19:36:34 2025 From: kyrieuon at gmail.com (Richard Stoughton) Date: Sun, 1 Jun 2025 19:36:34 +0200 Subject: Signing a file given its hash only In-Reply-To: References:

Message-ID: On Mon, May 19, 2025 at 6:08?PM Jay Acuna wrote: > > On Sun, May 18, 2025 at 6:58?AM Richard Stoughton wrote: > > To "sign" the hash on M, it would be necessary to inject a one-time > > secret (e.g. a OpenPGP private key > > This would seem to invalidate H's purpose for existing. At that point > may as well backup the keys on H > & move its signing subkey to a USB GPG Card. Install the card-based > keypairs on M, > and remove H from the process. > > The card provides M a means to sign only at the time that physical > card is inserted, > w/the correct PIN is entered, and M never gains access to read the secret. Currently M are short-lived cloud instances that run the build process without user interaction. I don't see how to use a HSM or similar hardware in this case. From jcb62281 at gmail.com Mon Jun 2 05:56:12 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 1 Jun 2025 22:56:12 -0500 Subject: Securely signing build artifacts (was: Signing a file given its hash only) In-Reply-To: References:

<87plg3ln0b.fsf@jacob.g10code.de> Message-ID: On 6/1/25 09:54, Richard Stoughton via Gnupg-users wrote: > [...] > > So we'll try another approach to preserve the security level of M on L: > > H injects a secret nonce into a build run on M. M uses the nonce to > create a MAC for each artifact it creates. M pushes the MACs along > with the artifacts to L. > > To sign an artifact H fetches the artifact and the corresponding MAC > to its local file system. Then H verifies the MAC using the secret > nonce it has previously injected into the build on M. If the MAC is > valid then H signs the artifact using gpg. Then H pushes the signature > to L. A simple variation:? the trusted build operator (someone approves the use of the keys stored on H...) generates an emphemeral keypair on a secure workstation (perhaps H itself?); the private key is injected into M and the public key is given to H as part of the process to approve signing build artifacts.? (Presumably, the ephemeral public key ends up in an audit log somewhere while the ephemeral private key is destroyed when M shuts down.) To sign an artifact, H fetches the artifact and the corresponding build signature to its local filesystem.? Then H verifies M's signature using the ephemeral public key created for that specific build.? If the signature is valid, H signs the artifact using its secure keys and pushes the signature to L, where it is again verified. This can be done without adding additional software to H aside from scripts to drive the process:? gpgv can be used to verify the build signatures.? Using symmetric MACs would require additional software, but H already needs GPG for its basic job. The only major problem with this I see is fundamental to this architecture: a compromised M can generate backdoored artifacts and sign them as if they were legitimate, with H and L none the wiser. Since you have mentioned that M is an ephemeral cloud instance, I presume that a compromise of your hosting provider is outside of your threat model. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiktor at metacode.biz Mon Jun 2 11:30:41 2025 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 2 Jun 2025 11:30:41 +0200 Subject: Signing a file given its hash only In-Reply-To: Message-ID: <1219bbe8-9480-481f-b2d2-42a101dff435@metacode.biz> Hi Richard, > On Tue, May 20, 2025 at 10:09?AM Werner Koch wrote: >> Many years ago we pondered wit this idea. However it is complicated >> because *PGP does not simpluy sign a hash but has a prefix and a suffix >> to append. Thus for signing we would need to provide a tool which takes >> some internal hash context, continue to has the file, and let gpg >> finalize the hashing. This is a bit ugly and would raise problems with >> certifications etc. > > OK, I see that by signing a hash it is not feasible to obtain the > signature for the file hashed. I had the same problem in a remote signer project that we're working on. We've analyzed technical differences between OpenPGP, SSH file signatures and X.509 [0]. SSH and X.509 have the benefit that they double-wrap the digest (that is first they compute the file digest, then embed that in a different structure and then sign that). Which makes it trivial to implement remote signing (or blind signing, where the signer only knows the digest of the data being signed). With OpenPGP v4 signatures (which are the most widely used type in circulation) the hasher first hashes a file and then appends PGP packets (as if they were appended to the end of the file). This is described in detail in section 5.2.3 of RFC 4880 [1]. Note that there is no prefix (it seems to be the same for v5 signatures [2]). Since, in Signstar, we control both the server and the client we were able to workaround the problem by sending hasher's *state* (not the digest) from the client to the server. This allows the client to compute the state up to the final bit of the hashed data and the server can both 1) recover the file digest (by finalizing the hasher state) 2) continue hashing the PGP packets (obtaining the final digest to be signed). It's not as straightforward as with SSH/X.509 but it works and may be relevant to your use-case. Happy to answer any questions you may have and if not... well... have a nice day, anyway! :) Kind regards, Wiktor [0]: https://gitlab.archlinux.org/archlinux/signstar/-/blob/main/signstar-request-signature/resources/docs/design.md?ref_type=heads [1]: https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3 [2]: https://www.ietf.org/archive/id/draft-koch-librepgp-03.html#name-version-4-and-5-signature-p From wk at gnupg.org Mon Jun 2 18:10:17 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Jun 2025 18:10:17 +0200 Subject: [Announce] GnuPG 2.5.7 released Message-ID: <877c1ucefq.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.7. This release is another one in a series of public testing releases eventually leading to a new stable version 2.7. 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.7 (2025-06-02) ================================================ [compared to version 2.5.6] * gpg: Allow updating a SHA-1 key certification w/o using the --force-sign-key option. [T7663] * gpg: The group key flag has now been fully implemented. [rG8833a34bf0] * gpg: Make combination of show-only-fpr-mbox and show-unusable-uid work. [rGd5a4a2dc89] * gpg: Do not allow compressed key packets on import. [T7014] * gpgsm: Allow an empty subject DN also during import. [T7171] * agent: Recover the old behavior with max-cache-ttl=0. [T6681] * agent: Fix ECC key on smartcard for composite KEM with PQC. [T7648] * scd: Fix a harmless read buffer over-read in a function used by PKCS#15 cards. [T7662] * gpg-mail-tube,wks: Support templates for mail content. [T7381] * Use the KEM interface of Libgcrypt for encryption/decryption. [T7649] * Fix a glitch in socket handling in Windows in case of a nonce mismatch. [rG645cf7d8fc] Release-info: https://dev.gnupg.org/T7671 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.7.tar.bz2 (8009k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.7.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.7_20250602.exe (5520k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.7_20250602.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.7_20250602.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.7_20250602.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Windows Installer ================= A 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 be released in a few days. 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.7.tar.bz2 you would use this command: gpg --verify gnupg-2.5.7.tar.bz2.sig gnupg-2.5.7.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.7.tar.bz2, you run the command like this: sha1sum gnupg-2.5.7.tar.bz2 and check that the output matches the next line: 4bc48750f6e5471a1606a82142f7742bd8414b2f gnupg-2.5.7.tar.bz2 f2d9106fdd8a6f905bc0688fdb828d583cc41bd0 gnupg-w32-2.5.7_20250602.tar.xz 49dc9af39d01ce26da2fbfba807fdc75fbb1bc19 gnupg-w32-2.5.7_20250602.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/T7671 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. -- 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 wk at gnupg.org Tue Jun 3 09:38:15 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Jun 2025 09:38:15 +0200 Subject: [Announce] GnuPG 2.5.7 released In-Reply-To: <877c1ucefq.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 02 Jun 2025 18:10:17 +0200") References: <877c1ucefq.fsf@jacob.g10code.de> Message-ID: <87y0u9b7h4.fsf@jacob.g10code.de> On Mon, 2 Jun 2025 18:10, Werner Koch said: > We are pleased to announce the availability of a new GnuPG release: > version 2.5.7. This release is another one in a series of public > testing releases eventually leading to a new stable version 2.7. Of course the above line should read ... a new stable version 2.6. 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 bernhard at intevation.de Tue Jun 3 09:52:22 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Jun 2025 09:52:22 +0200 Subject: [Announce] GnuPG 2.5.7 released In-Reply-To: <877c1ucefq.fsf@jacob.g10code.de> References: <877c1ucefq.fsf@jacob.g10code.de> Message-ID: <202506030952.32887.bernhard@intevation.de> Hi, congratulations on the new release! (Just did the Fediverse news: https://mstdn.social/@GnuPG/114618339067357870 ) Am Montag 02 Juni 2025 18:10:17 schrieb Werner Koch: > This release is another one in a series of public > testing releases eventually leading to a new stable version 2.7. .. that should have been 2.6 I guess. ;) Best 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 jb-gnumlists at wisemo.com Tue Jun 3 12:34:57 2025 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Tue, 3 Jun 2025 12:34:57 +0200 Subject: Signing a file given its hash only In-Reply-To: References:

<87plg3ln0b.fsf@jacob.g10code.de> Message-ID: <3cefaa74-b2a3-47a5-82d6-e76041192d4d@wisemo.com> On 6/1/2025 16:54:19, Richard Stoughton via Gnupg-users wrote: > On Tue, May 20, 2025 at 10:09?AM Werner Koch wrote: >> On Mon, 19 May 2025 15:40, Richard Stoughton said: >> >>> creates the final signatures. This could be done in a much more >>> efficient way if GnuPG would be able to create signatures with hashes >>> instead of the complete file content as input. >> Many years ago we pondered wit this idea. However it is complicated >> because *PGP does not simpluy sign a hash but has a prefix and a suffix >> to append. Thus for signing we would need to provide a tool which takes >> some internal hash context, continue to has the file, and let gpg >> finalize the hashing. This is a bit ugly and would raise problems with >> certifications etc. > OK, I see that by signing a hash it is not feasible to obtain the > signature for the file hashed. > > So we'll try another approach to preserve the security level of M on L: > > H injects a secret nonce into a build run on M. M uses the nonce to > create a MAC for each artifact it creates. M pushes the MACs along > with the artifacts to L. > > To sign an artifact H fetches the artifact and the corresponding MAC > to its local file system. Then H verifies the MAC using the secret > nonce it has previously injected into the build on M. If the MAC is > valid then H signs the artifact using gpg. Then H pushes the signature > to L. The closest to the OP described approach would be to generalize the code referenced in yesterday's post from Wiktor Kwapisiewicz . Otherwise, here's a simple traditional approach not needing to manage a custom MAC key? (This is based on an earlier suggestion in this thread): 1. M computes a traditional file of hashes in the same format as ? output by the GNU CoreUtils command: ?? shaXXXsum -b filename.ext filetwo2.ex2 filetre3.ex3 2. Someone trusted picks up the file of hashes while looking for ? signs of compromise of M, then submits the file of hashes to H ? with appropriate user authentication (like being someone with ? login access to H and checking the hash file on H is the same ? one just checked ) . ? Note: "Signs of compromise" is the same well known security ? concept applied by security guards to notice if a door has ? been forced open since the last round.? It is imperfect but ? good enough . 3. H runs a trusted minimalist (less trusted code!) script that ? checks that the hash file has the right number of lines, right ? filenames, and right line format (a specific number of ? lowercase hex digits, a space, a star, the expected filename, ? end-of line), then invokes gpg to sign the file of hashes . ?? Note that this does not require H to have the storage space ? for the full artifacts. 4. L checks the signature on the signed file of hashes using gpgv, ? then rechecks the hash file content format (like on H), then ? checks the file hashes like running the GNU CoreUtils command ? ? shaXXXsum -c hashfileWithoutTheSignture.shaXXXsums >> Our solution was to to implement remote signing. This allows to do the >> private key operations on your machines while the actual hashing and >> signing is done on the server. From a security POV this is the same as >> running only the bulk hashing on the server. > I don't think that I can use remote signing in our use case. > > If L is compromized, an attacker could possibly spoof the artifact > presented to the MAC validation while letting gpg sign a compromized > artifact. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipe_rm1 at hotmail.com Tue Jun 3 16:16:05 2025 From: philipe_rm1 at hotmail.com (Philipe Rabelo) Date: Tue, 3 Jun 2025 14:16:05 +0000 Subject: Request for dev.gnupg.org account Message-ID: Hello, My name is Philipe, and I would like to request an account on dev.gnupg.org. I am interested in contributing or participating in the development-related discussions and activities. My preferred username is: prm314 Email: philipe_rm1_at_hotmail.com Please let me know if you need any further information. Thank you in advance! Best regards, Philipe -------------- next part -------------- An HTML attachment was scrubbed... URL: From 4slam at mythicflow.com Wed Jun 4 04:27:58 2025 From: 4slam at mythicflow.com (aslamK) Date: Tue, 3 Jun 2025 22:27:58 -0400 Subject: "Can't connect to 'log-socket': Connection refused In-Reply-To: <202504290951.54467.bernhard@intevation.de> References:

<20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com> <202504290951.54467.bernhard@intevation.de> Message-ID: <101oave$8ho$1@ciao.gmane.io> This issue is discussed in the GnuPG forum: https://forum.gnupg.org/t/problem-with-socket-connection-refused/4669/8. It is fixed in libcrypt 1.11.0, according to this: https://bugzilla.opensuse.org/show_bug.cgi?id=1226912#c3 The Ubuntu Noble (24.04) repo currently provides libcrypt 1.10.3 (package "libcrypt20"). The "Connection refused" message can be avoided by setting the 'log-file' option to a file instead of the socket. This causes the output to be written to that file. I have not been able to have the output written to the terminal in an interactive session, which used to happen before the OS update. Therefore, I do the following: log="/path/to/gpg_$(date +'%Y%m%d-%H%M%S').log" gpg --log-file "$log" --verify file_to_verify.sig { cat "$log" && rm "$log"; } | tee -a "$HOME/.gnupg/gpg.log" -aslamK On 4/29/25 03:51, Bernhard Reiter via Gnupg-users wrote: > Am Sonntag 20 April 2025 08:51:44 schrieb aslamK: >> The issue is therefore not with `gnu --verify`, but with the connection >> to `log-socket`: >> === >> can't connect to ' >> socket:///home/user/.gnupg/log-socket >> ': Connection refused >> === > > Check your configuration, e.g. ~/.gnupg/gpg.conf > mine has an inactive > #debug-level basic > #log-file socket:///home/ber/.gnupg/log-socket > so I guess that you do have a `log-file` setting in your configuration > somewhere or > >> My config hasn't changed but I did upgrade my OS >> (Ubuntu 20.04.2) > > Ubuntu has changed the defaults. > Try setting log-file to a file to see if this changes the connection problem. > (Similiar options exist for gpg-agent.conf and dirmngr, make sure to restart > those daemons if you change their settings to see an effect.) > > Bernhard > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -- aslamK From wk at gnupg.org Thu Jun 5 08:43:28 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Jun 2025 08:43:28 +0200 Subject: "Can't connect to 'log-socket': Connection refused In-Reply-To: <101oave$8ho$1@ciao.gmane.io> (aslamK's message of "Tue, 3 Jun 2025 22:27:58 -0400") References:

<20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com> <202504290951.54467.bernhard@intevation.de> <101oave$8ho$1@ciao.gmane.io> Message-ID: <877c1qadtb.fsf@jacob.g10code.de> On Tue, 3 Jun 2025 22:27, aslamK said: > The "Connection refused" message can be avoided by setting the > 'log-file' option to a file instead of the socket. This causes the Or by not setting the log-file option at all. If for some reason it is set in some config files you may override it with --logger-fd 2 To reestabish the default of writing to stderr. 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 mcr at sandelman.ca Thu Jun 5 18:24:43 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 05 Jun 2025 12:24:43 -0400 Subject: initializing/unlocking key explicitely with gpg-agent Message-ID: <1018862.1749140683@obiwan.sandelman.ca> I recently toasted my desktop, had to re-install/restore from backup. I hadn't (re-)installed pinentry-gnome3, which was what my gpg-agent.conf specified. I hadn't realized this, and was running explicitely with --pinentry..= with a different (X-windows) option. Naturally, it displayed the request on my desktop while I was at the pub, connecting via mosh/emacsclient. I configure the ttl way high so that I don't have to enter things. I would rather not do that. I noticed gpg-agent has --allow-emacs-pinentry, but I've not figured out what/if/how that works. I remember emacs prompting me before gnupg 2.1. (I also still struggle with unlocking code signing keys that live most of their life offline on a USB key. Replacing with a yubikey is a todo. I have solutions, but I'm still frustrated with the process) I would in general, be happy to login to my desktop when remote, and then invoke some command that would unlock my keys for awhile. Using pinentry-curses or pinentry-tty if needed. I know that some people resort to running a screen just so that gpg-agent has a $GPG_TTY which it can always talk to. As far as I can tell, there is not a way to this with gpg-agent-connect. Maybe I'm just missing something. -- ] 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 [ From kloecker at kde.org Thu Jun 5 21:35:33 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Thu, 05 Jun 2025 21:35:33 +0200 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <1018862.1749140683@obiwan.sandelman.ca> References: <1018862.1749140683@obiwan.sandelman.ca> Message-ID: <2181370.9o76ZdvQCi@daneel> On Donnerstag, 5. Juni 2025 18:24:43 Mitteleurop?ische Sommerzeit Michael Richardson wrote: > I would in general, be happy to login to my desktop when remote, and then > invoke some command that would unlock my keys for awhile. Using > pinentry-curses or pinentry-tty if needed. I know that some people resort > to running a screen just so that gpg-agent has a $GPG_TTY which it can > always talk to. > > As far as I can tell, there is not a way to this with gpg-agent-connect. > Maybe I'm just missing something. Unless I'm missing something the PRESET_PASSPHRASE command is what you are looking for: $ gpg-connect-agent "help PRESET_PASSPHRASE" /bye # PRESET_PASSPHRASE [--inquire] [--restricted] \ # [] # # Set the cached passphrase/PIN for the key identified by the keygrip # to passwd for the given time, where -1 means infinite and 0 means # the default (currently only a timeout of -1 is allowed, which means # to never expire it). If passwd is not provided, ask for it via the # pinentry module unless --inquire is passed in which case the passphrase # is retrieved from the client via a server inquire. The option # --restricted can be used to put the passphrase into the cache used # by restricted connections. You may have to add "allow-preset-passphrase" to your gpg-agent.conf. 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 4slam at mythicflow.com Fri Jun 6 03:14:57 2025 From: 4slam at mythicflow.com (aslamK) Date: Thu, 5 Jun 2025 21:14:57 -0400 Subject: "Can't connect to 'log-socket': Connection refused In-Reply-To: <877c1qadtb.fsf@jacob.g10code.de> References:

<20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com> <202504290951.54467.bernhard@intevation.de> <101oave$8ho$1@ciao.gmane.io> <877c1qadtb.fsf@jacob.g10code.de> Message-ID: <101tfei$chf$1@ciao.gmane.io> On 6/5/25 02:43, Werner Koch via Gnupg-users wrote: > On Tue, 3 Jun 2025 22:27, aslamK said: > >> The "Connection refused" message can be avoided by setting the >> 'log-file' option to a file instead of the socket. This causes the > > Or by not setting the log-file option at all. If for some reason it is > set in some config files you may override it with > > --logger-fd 2 > > To reestabish the default of writing to stderr. > Thanks. Yes, after doing the following, the output does get written to stderr (to terminal in an interactive session): echo 'log-file:16:' | gpgconf --change-options gpg However, if 'log-file' is set in gpg.conf, then the following does not override it; the output is written to the log-file but not to stderr: gpg --logger-fd 2 --verify file_to_verify.sig $ gpg --version gpg (GnuPG) 2.4.4 libgcrypt 1.10.3 -- aslamK From wk at gnupg.org Fri Jun 6 14:32:41 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Jun 2025 14:32:41 +0200 Subject: "Can't connect to 'log-socket': Connection refused In-Reply-To: <101tfei$chf$1@ciao.gmane.io> (aslamK's message of "Thu, 5 Jun 2025 21:14:57 -0400") References:

<20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com> <202504290951.54467.bernhard@intevation.de> <101oave$8ho$1@ciao.gmane.io> <877c1qadtb.fsf@jacob.g10code.de> <101tfei$chf$1@ciao.gmane.io> Message-ID: <8734cd82za.fsf@jacob.g10code.de> On Thu, 5 Jun 2025 21:14, aslamK said: > However, if 'log-file' is set in gpg.conf, then the following does not > override it; the output is written to the log-file but not to stderr: > > gpg --logger-fd 2 --verify file_to_verify.sig I guess file descriptor 2 has already been redirected and is no longer stderr inside the gpg process. On Linux and someother OSes you may use --log-file /dev/stderr Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mcr at sandelman.ca Fri Jun 6 15:16:08 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 06 Jun 2025 09:16:08 -0400 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <2181370.9o76ZdvQCi@daneel> References: <1018862.1749140683@obiwan.sandelman.ca> <2181370.9o76ZdvQCi@daneel> Message-ID: <1320614.1749215768@obiwan.sandelman.ca> Ingo Kl?cker wrote: > Unless I'm missing something the PRESET_PASSPHRASE command is what you > are looking for: > $ gpg-connect-agent "help PRESET_PASSPHRASE" /bye # PRESET_PASSPHRASE > [--inquire] [--restricted] \ # > [] > # > # Set the cached passphrase/PIN for the key identified by the keygrip # > to passwd for the given time, where -1 means infinite and 0 means # the > default (currently only a timeout of -1 is allowed, which means # to > never expire it). If passwd is not provided, ask for it via the # > pinentry module unless --inquire is passed in which case the passphrase > # is retrieved from the client via a server inquire. The option # > --restricted can be used to put the passphrase into the cache used # by > restricted connections. "if passwd is not provided", but I don't see "passwd" as argument to PRESET_PASSPHRASE. Is it the hexstring? I clearly don't want to use the pinentry, since it will do the gtk2 thing, which I can't interact with remotely. I happen to already have "allow-preset-passphrase" in gpg-agent.conf, which suggests I have been down this path before, and forgot. -- ] 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 [ From jb-gnumlists at wisemo.com Fri Jun 6 17:30:45 2025 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Fri, 6 Jun 2025 17:30:45 +0200 Subject: "Can't connect to 'log-socket': Connection refused In-Reply-To: <8734cd82za.fsf@jacob.g10code.de> References:

<20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com> <202504290951.54467.bernhard@intevation.de> <101oave$8ho$1@ciao.gmane.io> <877c1qadtb.fsf@jacob.g10code.de> <101tfei$chf$1@ciao.gmane.io> <8734cd82za.fsf@jacob.g10code.de> <09b496ec-d227-4f21-a9e2-1ade0fda680b@wisemo.com> Message-ID: <87tt4r7d4e.fsf@jacob.g10code.de> On Fri, 6 Jun 2025 17:30, Jakob Bohm said: > Does this work because gpg evaluates --log-file before --logger-fd ?, I am not sure. I did some code staring and things look as they should be. So frankly, I did not instantly understand why --logger-fd does not work. This would require to step through the process or do some printf debugging. It might be related to estream which has some extra code (and es_stderr) for the standard file descriptors. See libgpg-error. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Sat Jun 7 18:17:10 2025 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Jun 2025 18:17:10 +0200 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <1320614.1749215768@obiwan.sandelman.ca> (Michael Richardson's message of "Fri, 06 Jun 2025 09:16:08 -0400") References: <1018862.1749140683@obiwan.sandelman.ca> <2181370.9o76ZdvQCi@daneel> <1320614.1749215768@obiwan.sandelman.ca> Message-ID: <87plff7chl.fsf@jacob.g10code.de> On Fri, 6 Jun 2025 09:16, Michael Richardson said: > I clearly don't want to use the pinentry, since it will do the gtk2 thing, > which I can't interact with remotely. There are two or there ways ways: --8<---------------cut here---------------start------------->8--- $ gpg-connect-agent > /let passwd abc > /definq PASSPHRASE passwd > preset_passphrase --inquire example-cache -1 S INQUIRE_MAXLEN 480 INQUIRE PASSPHRASE OK > get_passphrase example-cache X X X OK 31323334 > # Second version using a hexified passphrase > preset_passphrase example-cache -1 616263 OK > get_passphrase example-cache X X X OK 616263 > --8<---------------cut here---------------end--------------->8--- There is also a tool which implements the above: --8<---------------cut here---------------start------------->8--- $ /usr/local/libexec/gpg-preset-passphrase -c -P ABC example-cache $ gpg-connect-agent 'get_passphrase example-cache X X X' /bye OK 414243 --8<---------------cut here---------------end--------------->8--- Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From dbs at brandes.xyz Sat Jun 7 18:17:53 2025 From: dbs at brandes.xyz (Daniel Brandes) Date: Sat, 7 Jun 2025 18:17:53 +0200 Subject: [FYI] Development of GnuPG for OS X discontinued In-Reply-To: References: <7e9cc98a-cc5a-4262-8c96-237a01a6073b@intevation.de> Message-ID: <0a249d27-5383-4494-8c5b-6bd7f9799c5e@brandes.xyz> Am 28.05.25 um 09:38 schrieb Daniel Brandes: > Am 28.05.25 um 07:38 schrieb Christoph Klassen via Gnupg-users: >> maybe it's of interest for some of you that the development of GnuPG >> for OS X ended in March this year > > How does that affect third-party implementations like GPGtools and > Thunderbird on a Mac? > > Thanks a lot from a regular user Dear all, I understand this is a dev-oriented list; could someone point me to a entry-friendly community or other source? Thank you very much From mm at dorfdsl.de Sat Jun 7 19:24:59 2025 From: mm at dorfdsl.de (Marco Moock) Date: Sat, 7 Jun 2025 19:24:59 +0200 Subject: [FYI] Development of GnuPG for OS X discontinued In-Reply-To: <0a249d27-5383-4494-8c5b-6bd7f9799c5e@brandes.xyz> References: <7e9cc98a-cc5a-4262-8c96-237a01a6073b@intevation.de> <0a249d27-5383-4494-8c5b-6bd7f9799c5e@brandes.xyz> Message-ID: <20250607192459.6d7cf61e@ryz.dorfdsl.de> Am 07.06.2025 um 18:17:53 Uhr schrieb Daniel Brandes via Gnupg-users: > Am 28.05.25 um 09:38 schrieb Daniel Brandes: > > Am 28.05.25 um 07:38 schrieb Christoph Klassen via Gnupg-users: > >> maybe it's of interest for some of you that the development of > >> GnuPG for OS X ended in March this year > > > > How does that affect third-party implementations like GPGtools and > > Thunderbird on a Mac? > > > > Thanks a lot from a regular user > > Dear all, I understand this is a dev-oriented list; > could someone point me to a entry-friendly community or other source? TB has its own implementation of SMIME and PGP. Use the TB newsgroups or questions: alt.comp.software.thunderbird https://www.novabbs.com/computers/thread.php?group=alt.comp.software.thunderbird -- Gru? Marco Send unsolicited bulk mail to 1749313073muell at cartoonies.org From mcr at sandelman.ca Sun Jun 8 18:56:32 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 08 Jun 2025 12:56:32 -0400 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <87plff7chl.fsf@jacob.g10code.de> References: <1018862.1749140683@obiwan.sandelman.ca> <2181370.9o76ZdvQCi@daneel> <1320614.1749215768@obiwan.sandelman.ca> <87plff7chl.fsf@jacob.g10code.de> Message-ID: <1990678.1749401792@obiwan.sandelman.ca> <#part sign=pgpmime> Werner Koch wrote: > There are two or there ways ways: $ gpg-connect-agent >> /let passwd abc /definq PASSPHRASE passwd preset_passphrase --inquire >> example-cache -1 > S INQUIRE_MAXLEN 480 INQUIRE PASSPHRASE OK >> get_passphrase example-cache X X X > OK 31323334 >> # Second version using a hexified passphrase preset_passphrase >> example-cache -1 616263 > OK >> get_passphrase example-cache X X X > OK 616263 >> > There is also a tool which implements the above: $ > /usr/local/libexec/gpg-preset-passphrase -c -P ABC example-cache $ > gpg-connect-agent 'get_passphrase example-cache X X X' /bye OK 414243 I see, it's in /usr/lib/gnupg/gpg-preset-passphrase on debian packages. Not sure why it's not in the $PATH. Would patches that made it prompt, and turn off echo if isatty() be welcome? Thank you. From mcr at sandelman.ca Sun Jun 8 18:57:55 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 08 Jun 2025 12:57:55 -0400 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <1990678.1749401792@obiwan.sandelman.ca> References: <1018862.1749140683@obiwan.sandelman.ca> <2181370.9o76ZdvQCi@daneel> <1320614.1749215768@obiwan.sandelman.ca> <87plff7chl.fsf@jacob.g10code.de> <1990678.1749401792@obiwan.sandelman.ca> Message-ID: <1990994.1749401875@obiwan.sandelman.ca> Michael Richardson wrote: > <#part sign=pgpmime> ... > I see, it's in /usr/lib/gnupg/gpg-preset-passphrase on debian packages. > Not sure why it's not in the $PATH. Would patches that made it prompt, > and turn off echo if isatty() be welcome? Well, that didn't quite work. I had to re-install desktop last monday due to a stupid, and I have problems with multiple gpg-agents; probably gets solved if I finally do that first reboot now that everything is installed. From wk at gnupg.org Wed Jun 11 09:58:05 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jun 2025 09:58:05 +0200 Subject: initializing/unlocking key explicitely with gpg-agent In-Reply-To: <1990994.1749401875@obiwan.sandelman.ca> (Michael Richardson's message of "Sun, 08 Jun 2025 12:57:55 -0400") References: <1018862.1749140683@obiwan.sandelman.ca> <2181370.9o76ZdvQCi@daneel> <1320614.1749215768@obiwan.sandelman.ca> <87plff7chl.fsf@jacob.g10code.de> <1990678.1749401792@obiwan.sandelman.ca> <1990994.1749401875@obiwan.sandelman.ca> Message-ID: <87v7p26776.fsf@jacob.g10code.de> On Sun, 8 Jun 2025 12:57, Michael Richardson said: > Well, that didn't quite work. I had to re-install desktop last monday due to > a stupid, and I have problems with multiple gpg-agents; probably gets solved > if I finally do that first reboot now that everything is installed. That is likley a systemd thing. Snippet from the latest README: If your systems already comes with a systemd enabled GnuPG, you should thus tell it not to start its own GnuPG daemons by running the following three commands once: systemctl --user mask --now gpg-agent.service \ gpg-agent.socket gpg-agent-ssh.socket \ gpg-agent-extra.socket gpg-agent-browser.socket systemctl --user mask --now dirmngr.service dirmngr.socket systemctl --user mask --now keyboxd.service keyboxd.socket This way all GnuPG components can handle the startup of their daemons on their own and start the correct version. If you want to run gpg-preset-passphrase you can do: mylibexedir="$(gpgconf -L libexecdir)" $mylibexecdir/gpg-preset-passphrase It has been installed in libexec because you would not normaly run it directly. Changning this to bin now would be too troublesome. If you really want to use a simple getline() passed prompt, it would be better to write an external program. After all you need to do the same thing as all the pinentry versions do. There is even a pinentry-tty available. 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 bbhtt.zn0i8 at gmail.com Thu Jun 12 16:53:37 2025 From: bbhtt.zn0i8 at gmail.com (bbhtt) Date: Thu, 12 Jun 2025 20:23:37 +0530 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak In-Reply-To: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> References: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> Message-ID: Hi, I couldn't figure out how to get an account on `dev.gnupg.org` so I'm posting this to the list. Recently, we (the maintainers of the Flatpak runtime - Freedesktop SDK) patched GnuPG to skip sending `DBUS_SESSION_BUS_ADDRESS` from inside the Flatpak sandbox (inside the sandbox GnuPG comes from the Freedesktop SDK runtime) to the agent running outside on host. The commit message of the patch has the details but I was recently made aware that a previous upstream bug [1] was also filed by someone else to this affect. So I assume GnuPG upstream is aware of the problem. Please feel free to take the patch [2] upstream if wanted. [1]: https://dev.gnupg.org/T7522 [2]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/raw/1dfaba8cbf9facd0a3d5f1ac265bce09917db9ae/patches/gnupg/0001-session-env-Skip-DBUS_SESSION_BUS_ADDRESS-inside-Fla.patch - bbhtt https://bbhtt.space From bbhtt.zn0i8 at gmail.com Thu Jun 12 16:32:52 2025 From: bbhtt.zn0i8 at gmail.com (bbhtt) Date: Thu, 12 Jun 2025 20:02:52 +0530 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak Message-ID: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> Hi, I couldn't figure out how to get an account on `dev.gnupg.org` so I'm posting this to the list. Recently, we (the maintainers of the Flatpak runtime - Freedesktop SDK) patched GnuPG to skip sending `DBUS_SESSION_BUS_ADDRESS` from inside the Flatpak sandbox (inside the sandbox GnuPG comes from the Freedesktop SDK runtime) to the agent running outside on host. The commit message of the patch has the details but I was recently made aware that a previous upstream bug [1] was also filed by someone else to this affect. So I assume GnuPG upstream is aware of the problem. Please feel free to take the patch [2] upstream if wanted. [1]: https://dev.gnupg.org/T7522 [2]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/raw/1dfaba8cbf9facd0a3d5f1ac265bce09917db9ae/patches/gnupg/0001-session-env-Skip-DBUS_SESSION_BUS_ADDRESS-inside-Fla.patch - bbhtt https://bbhtt.space From damon.tu at outlook.com Thu Jun 5 11:24:22 2025 From: damon.tu at outlook.com (To Damon) Date: Thu, 5 Jun 2025 09:24:22 +0000 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks Message-ID: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> When a GPG key has a fingerprint or keyID that ends with a long sequence of zero bytes (e.g., 0000 0000 0000), GnuPG fails to assign trust to the key and reports an error when running `gpg --check-trustdb` or using the key in Git signature verification. This appears to be a bug in the `keyid_from_fingerprint` function or in trust database resolution for such edge-case keyIDs. GnuPG version: > gpg --version gpg (GnuPG) 2.4.7 libgcrypt 1.11.1 Copyright (C) 2024 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/user/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 > git verify-commit -v abcedfg ggpg: Signature made Sat 31 May 2025 10:23:03 AM CST gpg: using EDDSA key FFFFD546BAF8A3B1F7805F30100C999999999999 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: ffffe32f62fa6745c5cb09c2412a0000 gpg: Good signature from "Damon To " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FFFF E32F 62FA 6745 C5CB 09C2 412A 0000 0000 0000 Subkey fingerprint: FFFF D546 BAF8 A3B1 F780 5F30 100C 9999 9999 9999 > gpg --list-secret-keys --keyid-format=long --with-keygrip gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: ffffe32f62fa6745c5cb09c2412a0000 You can use the following secret key to reproduce this issue. 6B33500000000000.asc -----BEGIN PGP PRIVATE KEY BLOCK----- lDsEZrxltRYJKwYBBAHaRw8BAQdA5YAyQLyr+9iU0vxkNHhZGprv18KrI8tPxWep p4vH2W//AGUAR05VAbQGTk9OQU1F =oFN7 -----END PGP PRIVATE KEY BLOCK----- From andrewg at andrewg.com Fri Jun 13 15:54:47 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 13 Jun 2025 14:54:47 +0100 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> Message-ID: <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> On 5 Jun 2025, at 10:24, To Damon via Gnupg-users wrote: > >> gpg --list-secret-keys --keyid-format=long --with-keygrip > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: ffffe32f62fa6745c5cb09c2412a0000 At some point it appears to have converted a v4 fingerprint with N>=32 trailing zero bits to a v3 fingerprint with N-32 trailing zero bits. Are fingerprints stored in a zero-padded fixed-width field somewhere? A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From andrewg at andrewg.com Fri Jun 13 16:34:45 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 13 Jun 2025 15:34:45 +0100 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> Message-ID: <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> On 13 Jun 2025, at 15:29, To Damon wrote: > >> gpg --list-secret-keys --with-fingerprint > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 51f9e32f62fa6745c5cb09c2412a0000 > gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 577e8f3f61625918c9c53c226b335000 > gpg: key 0000000000000000 occurs more than once in the trustdb > gpg: checking the trustdb > gpg: Note: ultimately trusted key 0000000000000000 not found > gpg: no ultimately trusted keys found > /home/user/.gnupg/pubring.kbx This looks like there is a second issue, which is that the trustdb was updated with a null fingerprint or long keyID, twice. Not clear from the outside whether this is a related bug or independent, but it all seems to indicate a baked-in assumption that fingerprints will never have a large number of trailing zeros... A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From damon.tu at outlook.com Fri Jun 13 16:29:47 2025 From: damon.tu at outlook.com (To Damon) Date: Fri, 13 Jun 2025 14:29:47 +0000 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> Message-ID: <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> I don't know how to confirm it. This is a new secret key. > gpg --list-secret-keys --with-fingerprint gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 51f9e32f62fa6745c5cb09c2412a0000 gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 577e8f3f61625918c9c53c226b335000 gpg: key 0000000000000000 occurs more than once in the trustdb gpg: checking the trustdb gpg: Note: ultimately trusted key 0000000000000000 not found gpg: no ultimately trusted keys found /home/user/.gnupg/pubring.kbx > gpg --export-options export-minimal --export 6B33500000000000 | gpg --list-packets # off=0 ctb=98 tag=6 hlen=2 plen=51 :public key packet: version 4, algo 22, created 1723622837, expires 0 pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: [263 bits] keyid: 6B33500000000000 # off=53 ctb=b4 tag=13 hlen=2 plen=27 :user ID packet: "Test (test) " # off=82 ctb=88 tag=2 hlen=2 plen=144 :signature packet: algo 22, keyid 6B33500000000000 version 4, created 1749823426, md5len 0, sigclass 0x13 digest algo 10, begin of digest 56 1a hashed subpkt 33 len 21 (issuer fpr v4 577E8F3F61625918C9C53C226B33500000000000) hashed subpkt 2 len 4 (sig created 2025-06-13) hashed subpkt 27 len 1 (key flags: 23) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 6B33500000000000) data: [256 bits] data: [256 bits] -----BEGIN PGP PRIVATE KEY BLOCK----- lFgEZrxltRYJKwYBBAHaRw8BAQdA5YAyQLyr+9iU0vxkNHhZGprv18KrI8tPxWep p4vH2W8AAP9+1De+ho5PeUTiDJAidUNt3PS2lYt8WmAvpiNsKIf2rhC+tBtUZXN0 ICh0ZXN0KSA8dGVzdEB0ZXN0LmRldj6IkAQTFgoAOBYhBFd+jz9hYlkYycU8Imsz UAAAAAAABQJoTC/CAhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGszUAAA AAAAVhoBAMAWN3LHDK2BStO8jGyVZMTdN/VGCfVTtW0At1DSwe/dAQDlP0qpFm8V oO5Wbk9U4x+VefbnQMiJQdh7KJGa60t/BA== =qaQF -----END PGP PRIVATE KEY BLOCK----- > On 13 Jun 2025, at 21:54, Andrew Gallagher wrote: > > On 5 Jun 2025, at 10:24, To Damon via Gnupg-users wrote: >> >>> gpg --list-secret-keys --keyid-format=long --with-keygrip >> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: ffffe32f62fa6745c5cb09c2412a0000 > > At some point it appears to have converted a v4 fingerprint with N>=32 trailing zero bits to a v3 fingerprint with N-32 trailing zero bits. Are fingerprints stored in a zero-padded fixed-width field somewhere? > > A > From waltman at pobox.com Sat Jun 14 22:36:03 2025 From: waltman at pobox.com (Walt Mankowski) Date: Sat, 14 Jun 2025 16:36:03 -0400 Subject: "keyserver receive failed: Try again later" on macOS Message-ID: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> Hi, I recently got a new MacBook Air and I'm having trouble setting up gpg on it. I'm running macOS Sequoia 15.5 and the laptop has an Apple M4 chip. I installed gpg 2.4.8 using homebrew and copied my .gnupg directory from my older Intel-based MacBook Pro. It can use existing keys just fine, but it fails to import any new keys. Every time I try to import a key, it fails almost immediately with the error gpg: keyserver receive failed: Try again later I've tried a number of different keyservers and keep getting the same error. I have an Ubuntu box on the same network. I've run the same command on each box, for example: gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 This imports the key on Ubuntu but gives me the "Try again later" error on macOS. I looked online for help but didn't find very much. I've set ~/.gnupg/dirmngr.conf to log-file ~/.gnupg/dirmngr.log debug-level guru standard-resolver and restarted dirmngr, but that had very little effect. In particular nothing gets logged to dirmngr.log. Has anyone else seen this behavior before and know how to fix it? If not, I'd appreciate some advice on how to get it to log more diagnostic info, because I'm pretty much stuck now. Thanks. Walt -------------- next part -------------- An HTML attachment was scrubbed... URL: From waltman at pobox.com Sun Jun 15 13:36:47 2025 From: waltman at pobox.com (Walt Mankowski) Date: Sun, 15 Jun 2025 07:36:47 -0400 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> Message-ID: <2032ee85-7021-44c3-b5e6-976e46fad76e@app.fastmail.com> Hi C.J., Good to see you too. I didn't run any tests since I installed the binary using homebrew. I suppose trying to install from source will be my next step. I couldn't find any similar error reports on gnupg-users or gnupg-devel. It does make searching a bit tough, though, when I keep finding it referred to as "OSX" or "OS X" even though Apple changed the name to "macOS" back in 2016. Walt On Sat, Jun 14, 2025, at 9:32 PM, C.J. Collier wrote: > Hey waltman! Good seeing you here. I've been working on a Perl project lately and have been thinking of the irc channel as I do so. > > I thought I saw a similar error report recently for gpg on osx. I haven't owned one since around '10, so I can't try first hand... > > Did you try running the unit tests when you were building? Is there even a make test? I imagine a world where there is... > > Cheers, > > C.J. > > > > On Sat, Jun 14, 2025, 14:58 Walt Mankowski via Gnupg-users wrote: >> __ >> Hi, >> >> I recently got a new MacBook Air and I'm having trouble setting up gpg on it. I'm running macOS Sequoia 15.5 and the laptop has an Apple M4 chip. >> >> >> I installed gpg 2.4.8 using homebrew and copied my .gnupg directory from my older Intel-based MacBook Pro. It can use existing keys just fine, but it fails to import any new keys. >> >> >> Every time I try to import a key, it fails almost immediately with the error >> >> >> gpg: keyserver receive failed: Try again later >> >> I've tried a number of different keyservers and keep getting the same error. I have an Ubuntu box on the same network. I've run the same command on each box, for example: >> >> gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> >> This imports the key on Ubuntu but gives me the "Try again later" error on macOS. >> >> I looked online for help but didn't find very much. I've set ~/.gnupg/dirmngr.conf to >> >> log-file ~/.gnupg/dirmngr.log >> debug-level guru >> standard-resolver >> >> and restarted dirmngr, but that had very little effect. In particular nothing gets logged to dirmngr.log. >> >> Has anyone else seen this behavior before and know how to fix it? If not, I'd appreciate some advice on how to get it to log more diagnostic info, because I'm pretty much stuck now. >> >> Thanks. >> >> Walt >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> https://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Mon Jun 16 03:38:12 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 15 Jun 2025 20:38:12 -0500 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: <2032ee85-7021-44c3-b5e6-976e46fad76e@app.fastmail.com> References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> <2032ee85-7021-44c3-b5e6-976e46fad76e@app.fastmail.com> Message-ID: On 6/15/25 06:36, Walt Mankowski via Gnupg-users wrote: > [...] > > I couldn't find any similar error reports on gnupg-users or > gnupg-devel. It does make searching a bit tough, though, when I keep > finding it referred to as "OSX" or "OS X" even though Apple changed > the name to "macOS" back in 2016. That is because the community seems to have largely rejected Apple's renaming of "Mac OS X" because a previous (very different) "MacOS" product is indistinguishable from "macOS" in a case-insensitive index. Strictly, it is "Mac OS X", "OSX" and "OS X" are other, obscure systems. -- Jacob From andrewg at andrewg.com Mon Jun 16 11:53:34 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 16 Jun 2025 10:53:34 +0100 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> Message-ID: On 14 Jun 2025, at 21:36, Walt Mankowski via Gnupg-users wrote: > > Every time I try to import a key, it fails almost immediately with the error > > gpg: keyserver receive failed: Try again later > > I've tried a number of different keyservers and keep getting the same error. I have an Ubuntu box on the same network. I've run the same command on each box, for example: > > gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > > This imports the key on Ubuntu but gives me the "Try again later" error on macOS. > > I looked online for help but didn't find very much. I've set ~/.gnupg/dirmngr.conf to > > log-file ~/.gnupg/dirmngr.log > debug-level guru > standard-resolver > > and restarted dirmngr, but that had very little effect. In particular nothing gets logged to dirmngr.log. This is most likely a name resolution error. What are the contents of your /etc/resolv.conf file? A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From waltman at pobox.com Tue Jun 17 15:41:16 2025 From: waltman at pobox.com (Walt Mankowski) Date: Tue, 17 Jun 2025 09:41:16 -0400 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com> Message-ID: I figured out what the problem was this morning. It wasn't name resolution, although I suspected that as well. Instead it turned out to be the port. When I changed the command to gpg --keyserver hkp://keyserver.ubuntu.com::11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 then it retrieved the key as expected. I added the port to gpg.conf and now everything is fine. I did notice that /etc/services on macOS has two entries for hkp: hkp 11371/udp # OpenPGP HTTP Keyserver hkp 11371/tcp # OpenPGP HTTP Keyserver I tried commenting out the udp version and restarting dirmngr, but that had no effect. Walt On Mon, Jun 16, 2025, at 5:53 AM, Andrew Gallagher wrote: > On 14 Jun 2025, at 21:36, Walt Mankowski via Gnupg-users wrote: >> >> Every time I try to import a key, it fails almost immediately with the error >> >> gpg: keyserver receive failed: Try again later >> >> I've tried a number of different keyservers and keep getting the same error. I have an Ubuntu box on the same network. I've run the same command on each box, for example: >> >> gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> >> This imports the key on Ubuntu but gives me the "Try again later" error on macOS. >> >> I looked online for help but didn't find very much. I've set ~/.gnupg/dirmngr.conf to >> >> log-file ~/.gnupg/dirmngr.log >> debug-level guru >> standard-resolver >> >> and restarted dirmngr, but that had very little effect. In particular nothing gets logged to dirmngr.log. > > This is most likely a name resolution error. What are the contents of your /etc/resolv.conf file? > > A > > > *Attachments:* > ? signature.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jun 18 11:10:21 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Jun 2025 11:10:21 +0200 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak In-Reply-To: (bbhtt via Gnupg-users's message of "Thu, 12 Jun 2025 20:23:37 +0530") References: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> Message-ID: <877c192z5u.fsf@jacob.g10code.de> On Thu, 12 Jun 2025 20:23, bbhtt said: > Please feel free to take the patch [2] upstream if wanted. That was actually fixed in February with the introduction of the --change-std-env-name in 2.5.4. > [1]: https://dev.gnupg.org/T7522 As stated there. This will not be backported becuase EOL for 2.4 will be reached in one year. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jun 18 13:23:46 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Jun 2025 12:23:46 +0100 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com>

Message-ID: <44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> On 17 Jun 2025, at 14:41, Walt Mankowski wrote: > > When I changed the command to > > gpg --keyserver hkp://keyserver.ubuntu.com::11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > > then it retrieved the key as expected. I added the port to gpg.conf and now everything is fine. Aha, that?s interesting. keyserver.ubuntu.com does also serve keys on the default HTTP port, so I?m not sure why the explicit port number would help. Out of curiosity, what happens if you change it to hkps://keyserver.ubuntu.com ? (with the ?s? and without the port)? > I did notice that /etc/services on macOS has two entries for hkp: > > hkp 11371/udp # OpenPGP HTTP Keyserver > hkp 11371/tcp # OpenPGP HTTP Keyserver > > I tried commenting out the udp version and restarting dirmngr, but that had no effect. No, I wouldn?t expect it to. /etc/services is mainly informational these days, most applications hard code their port numbers. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bbhtt.zn0i8 at gmail.com Wed Jun 18 11:22:10 2025 From: bbhtt.zn0i8 at gmail.com (bbhtt) Date: Wed, 18 Jun 2025 14:52:10 +0530 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak In-Reply-To: <877c192z5u.fsf@jacob.g10code.de> References: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> <877c192z5u.fsf@jacob.g10code.de> Message-ID: On 18/06/25 14:40, Werner Koch wrote: > On Thu, 12 Jun 2025 20:23, bbhtt said: > >> Please feel free to take the patch [2] upstream if wanted. > > That was actually fixed in February with the introduction of the > --change-std-env-name in 2.5.4. Yes I did notice it, but as far as I understand someone would need to start the agent on the host with that argument passed, which is fine but it doesn't work "by default". The difference is the patch should make it work by default inside Flatpak, without needing to touch the gpg-agent options on host and maintains the status-quo for host<->host case (nothing is changed there). - bbhtt https://bbhtt.space From andrewg at andrewg.com Wed Jun 18 17:44:16 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Jun 2025 16:44:16 +0100 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: <10741ad2-9539-4200-9208-495476561423@app.fastmail.com> References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com>

<44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> <10741ad2-9539-4200-9208-495476561423@app.fastmail.com> Message-ID: <84DA0649-44B2-428B-9F79-9BE125739AE3@andrewg.com> On 18 Jun 2025, at 16:15, Walt Mankowski wrote: > > $ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > gpg: keyserver receive failed: Try again later > $ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > gpg: keyserver receive failed: Try again later > $ gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > gpg: key 5DF19E2B67A7B584: 1 duplicate signature removed > gpg: key 5DF19E2B67A7B584: "Walter C. Mankowski >" not changed > gpg: Total number processed: 1 > gpg: unchanged: 1 > $ gpg --keyserver hkps://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > gpg: keyserver receive failed: No keyserver available > $ gpg --keyserver hkps://keyserver.ubuntu.com:11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 > gpg: keyserver receive failed: No keyserver available Curiouser and curiouser. :-( I?ve tested this on my 15.5 Mac with homebrew, but can?t reproduce. I do also have GPGtools installed, which makes it difficult to replicate your environment - but I made sure to kill dirmngr and allow the homebrew gpg to start its own, and I haven?t seen any issues with keyserver connectivity. Could you try renaming your .gnupg directory temporarily and checking if the issue persists with a fresh config? A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From waltman at pobox.com Wed Jun 18 18:15:32 2025 From: waltman at pobox.com (Walt Mankowski) Date: Wed, 18 Jun 2025 12:15:32 -0400 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: <84DA0649-44B2-428B-9F79-9BE125739AE3@andrewg.com> References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com>

<44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> <10741ad2-9539-4200-9208-495476561423@app.fastmail.com> <84DA0649-44B2-428B-9F79-9BE125739AE3@andrewg.com> Message-ID: Good idea! I renamed my .gnupg directory, killed dirmngr, and then tried to receive a key: % gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 7FE79B445728C8EA0042839E45BCE75B840B1F69 gpg: directory '/Users/waltman/.gnupg' created It hung for several minutes and then I killed it. I've got a pretty large key, so I tried a few others and had the same result. The .gnupg directory it creates is very barebones: % find .gnupg .gnupg .gnupg/S.dirmngr .gnupg/common.conf .gnupg/crls.d .gnupg/crls.d/DIR.txt % cat .gnupg/common.conf use-keyboxd % cat .gnupg/crls.d/DIR.txt v:1: I'm pretty sure this was working on my old Mac. I won't have a chance to test that until tonight and see if anything's different there. I set this new one up from scratch since it's my first non-Intel Mac, so it's quite possible there are differences. Walt On Wed, Jun 18, 2025, at 11:44 AM, Andrew Gallagher wrote: > On 18 Jun 2025, at 16:15, Walt Mankowski wrote: >> >> $ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> gpg: keyserver receive failed: Try again later >> $ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> gpg: keyserver receive failed: Try again later >> $ gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> gpg: key 5DF19E2B67A7B584: 1 duplicate signature removed >> gpg: key 5DF19E2B67A7B584: "Walter C. Mankowski " not changed >> gpg: Total number processed: 1 >> gpg: unchanged: 1 >> $ gpg --keyserver hkps://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> gpg: keyserver receive failed: No keyserver available >> $ gpg --keyserver hkps://keyserver.ubuntu.com:11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> gpg: keyserver receive failed: No keyserver available > Curiouser and curiouser. :-( > > I?ve tested this on my 15.5 Mac with homebrew, but can?t reproduce. I do also have GPGtools installed, which makes it difficult to replicate your environment - but I made sure to kill dirmngr and allow the homebrew gpg to start its own, and I haven?t seen any issues with keyserver connectivity. > > Could you try renaming your .gnupg directory temporarily and checking if the issue persists with a fresh config? > > A > > > *Attachments:* > ? signature.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From waltman at pobox.com Wed Jun 18 17:15:52 2025 From: waltman at pobox.com (Walt Mankowski) Date: Wed, 18 Jun 2025 11:15:52 -0400 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: <44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com>

<44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> Message-ID: <10741ad2-9539-4200-9208-495476561423@app.fastmail.com> $ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 gpg: keyserver receive failed: Try again later $ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 gpg: keyserver receive failed: Try again later $ gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 gpg: key 5DF19E2B67A7B584: 1 duplicate signature removed gpg: key 5DF19E2B67A7B584: "Walter C. Mankowski " not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ gpg --keyserver hkps://keyserver.ubuntu.com:80 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 gpg: keyserver receive failed: No keyserver available $ gpg --keyserver hkps://keyserver.ubuntu.com:11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 gpg: keyserver receive failed: No keyserver available On Wed, Jun 18, 2025, at 7:23 AM, Andrew Gallagher wrote: > On 17 Jun 2025, at 14:41, Walt Mankowski wrote: >> >> When I changed the command to >> >> gpg --keyserver hkp://keyserver.ubuntu.com::11371 --recv-keys 77D4D81DC47D68FA9E9E6A7C5DF19E2B67A7B584 >> >> then it retrieved the key as expected. I added the port to gpg.conf and now everything is fine. > > Aha, that?s interesting. keyserver.ubuntu.com does also serve keys on the default HTTP port, so I?m not sure why the explicit port number would help. Out of curiosity, what happens if you change it to hkps://keyserver.ubuntu.com ? (with the ?s? and without the port)? > >> I did notice that /etc/services on macOS has two entries for hkp: >> >> hkp 11371/udp # OpenPGP HTTP Keyserver >> hkp 11371/tcp # OpenPGP HTTP Keyserver >> >> I tried commenting out the udp version and restarting dirmngr, but that had no effect. > No, I wouldn?t expect it to. /etc/services is mainly informational these days, most applications hard code their port numbers. > > A > > > *Attachments:* > ? signature.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Jun 18 23:28:21 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Jun 2025 22:28:21 +0100 Subject: "keyserver receive failed: Try again later" on macOS In-Reply-To: References: <90ad94b6-d90c-46a0-b24d-df0fa22c1204@app.fastmail.com>

<44B6361F-E967-4CFA-943F-349E6F7BF61F@andrewg.com> <10741ad2-9539-4200-9208-495476561423@app.fastmail.com> <84DA0649-44B2-428B-9F79-9BE125739AE3@andrewg.com> Message-ID: <1F64A24B-5331-4C9C-A100-01D242266C83@andrewg.com> On 18 Jun 2025, at 17:15, Walt Mankowski wrote: > > Good idea! I renamed my .gnupg directory, killed dirmngr, and then tried to receive a key: > > % gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 7FE79B445728C8EA0042839E45BCE75B840B1F69 > gpg: directory '/Users/waltman/.gnupg' created > > It hung for several minutes and then I killed it. I've got a pretty large key, so I tried a few others and had the same result. Your key downloads in under a second for me, so it?s not a size issue. I find the hanging behaviour very odd, I wonder if there?s still an issue in the name resolution on that machine. Does the hanging behaviour happen on every invocation now? Is it just slow for keyserver lookups or does it happen with other operations? Does adding ?standard-resolver? to dirmngr.conf make a difference? > I'm pretty sure this was working on my old Mac. I won't have a chance to test that until tonight and see if anything's different there. I set this new one up from scratch since it's my first non-Intel Mac, so it's quite possible there are differences. I have access to an apple silicon macbook but it has macports installed rather than homebrew, and I don?t want to mix and match. I?ll see if I can find another one in $WORK for testing. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From suhas.mania.com at gmail.com Thu Jun 19 17:09:44 2025 From: suhas.mania.com at gmail.com (Suhas Srivastava) Date: Thu, 19 Jun 2025 20:39:44 +0530 Subject: Request for dev.gnupg.org account Message-ID: Hi Team, I'd like to request for a dev.gnupg.org account as I am interested in: - development - inclusion in new release planning - bug tracking - bug reports My preferred name: Suhas Krishna Srivastava My preferred uname: suhas.srivastava Email: suhas.srivastava at vaastav.tech Please let me know if any further information is needed. Thanks & Regards, Suhas Srivastava -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 20 17:47:13 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jun 2025 17:47:13 +0200 Subject: [Announce] GnuPG 2.5.8 released Message-ID: <87ikkq1kla.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.8. 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. 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.8 (2025-06-20) ================================================ [compared to version 2.5.7] * gpg: Show revocation reason with a standard -k listing. [T7083] * gpg: Emit a revocation reason as comment in a "pub" record. [T7083] * agent: Fix regression in 2.5.7 decrypting with a card based cv25519 key. [T7676] * scd:openpgp: Fix a regression in exporting card based ed25519 ssh keys. [T7589] * dirmngr: Do not require a keyserver for "gpg --fetch-key". [T7693] Release-info: https://dev.gnupg.org/T7672 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.8.tar.bz2 (8012k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.8.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.8_20250620.exe (5521k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.8_20250620.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.8_20250620.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.8_20250620.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Windows Installer ================= A 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 be released in a few days. 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.8.tar.bz2 you would use this command: gpg --verify gnupg-2.5.8.tar.bz2.sig gnupg-2.5.8.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.8.tar.bz2, you run the command like this: sha1sum gnupg-2.5.8.tar.bz2 and check that the output matches the next line: 2767432e0c2a1b95e37ad4117f6cca4c49d459a7 gnupg-2.5.8.tar.bz2 3c15efec53247dd21655a9c155ca15b8a507cb9c gnupg-w32-2.5.8_20250620.tar.xz ff90e52c7707b1d3da3dbb8be48efbdbfe6abc10 gnupg-w32-2.5.8_20250620.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/T7672 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. -- 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 suhas.mania.com at gmail.com Fri Jun 20 16:13:48 2025 From: suhas.mania.com at gmail.com (Suhas Srivastava) Date: Fri, 20 Jun 2025 19:43:48 +0530 Subject: Request for dev.gnupg.org account In-Reply-To: References: Message-ID: Hi Team, I received a mail from GnuPG today stating that ebo (Eva) has created an account for me with the username: suhas.srivastava I even received a link to phabricator to set my password but opening that link brings up a 403 forbidden page. I request for a dev.gnupg.org account because I have to report a bug (possible anomaly) of GnuPG on windows 11 Home 24H2 and I'd need to view the bug-tracker to: - Examine whether this bug (possible anomaly) was reported earlier and the progress on its remediation. - Raise it if it isn't already raised. Kindly assist with my account creation. Thanks & Regards, Suhas Srivastava On Thu, Jun 19, 2025 at 8:39?PM Suhas Srivastava wrote: > Hi Team, > I'd like to request for a dev.gnupg.org account as I am interested in: > > - development > - inclusion in new release planning > - bug tracking > - bug reports > > My preferred name: Suhas Krishna Srivastava > My preferred uname: suhas.srivastava > Email: suhas.srivastava at vaastav.tech > > > Please let me know if any further information is needed. > > Thanks & Regards, > Suhas Srivastava > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sat Jun 21 15:47:29 2025 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Jun 2025 15:47:29 +0200 Subject: Request for dev.gnupg.org account In-Reply-To: (Suhas Srivastava via Gnupg-users's message of "Fri, 20 Jun 2025 19:43:48 +0530") References: Message-ID: <878qll1a1a.fsf@jacob.g10code.de> Hi! > I even received a link to phabricator to set my password but opening that > link brings up a 403 forbidden page. Please use a different browser. We are still under hefty DoS and from time to time we need to lock out some user agent string (browser). Thank you cheap AI. > - Examine whether this bug (possible anomaly) was reported earlier and > the progress on its remediation. BTW, you can do this w/o an account. It might be easier for you to report it here here to share the problem with a lot of other users. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Sat Jun 21 15:57:59 2025 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Jun 2025 15:57:59 +0200 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak In-Reply-To: (bbhtt via Gnupg-users's message of "Wed, 18 Jun 2025 14:52:10 +0530") References: <80317fd2-df3d-4b1d-8ce6-8df049e9201f@bbhtt.space> <877c192z5u.fsf@jacob.g10code.de> Message-ID: <874iw919js.fsf@jacob.g10code.de> On Wed, 18 Jun 2025 14:52, bbhtt said: > The difference is the patch should make it work by default inside > Flatpak, without needing to touch the gpg-agent options on host and Too large of a patch for a very special setting. And we have a proper solution already. Do you know that you can have a /etc/gnupg/gpg-agent.conf file which is read before the ~/.gnupg/gpg.conf file? This might already help - I don't know the details of flatpack, though. What you can also do is to examine an environment variable and set the rspecive options depending on the envvar. For example assuming you have a INSIDE_FLATPACK set to a non-zero value: [getreg flatpack INSIDE_FLATPACK] [if $flatpack] change-std-env-name -WHATEVER change-std-env-name -OTHERTHING [fi] Either in the global or in the local conf file. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From bbhtt.zn0i8 at gmail.com Sat Jun 21 16:30:36 2025 From: bbhtt.zn0i8 at gmail.com (bbhtt) Date: Sat, 21 Jun 2025 20:00:36 +0530 Subject: Patching GnuPG to skip sending DBUS_SESSION_BUS_ADDRESS in Flatpak In-Reply-To: <683e0913-6d84-4d27-a73c-8b4ca4732999@gmail.com> References: <683e0913-6d84-4d27-a73c-8b4ca4732999@gmail.com> Message-ID: On 21/06/25 19:27, Werner Koch wrote: > On Wed, 18 Jun 2025 14:52, bbhtt said: > Too large of a patch for a very special setting. And we have a proper > solution already. That's fine, we can carry it :) > What you can also do is to examine an environment variable and set the > rspecive options depending on the envvar. For example assuming you have > a INSIDE_FLATPACK set to a non-zero value: > > [getreg flatpack INSIDE_FLATPACK] > [if $flatpack] > change-std-env-name -WHATEVER > change-std-env-name -OTHERTHING > [fi] > > Either in the global or in the local conf file. > I don't think that works here. The canonical way of checking if something is running inside Flatpak is to test for the existence of the file `/.flatpak-info` inside the sandbox. But the gpg-agent is running on host, it is not running inside the sandbox. I don't think it has any idea whether the forwarded stdenvnames is coming from "GPG on host" vs. "GPG running inside the Flatpak container". - bbhtt https://bbhtt.space From suhas.mania.com at gmail.com Sun Jun 22 18:16:18 2025 From: suhas.mania.com at gmail.com (Suhas Srivastava) Date: Sun, 22 Jun 2025 21:46:18 +0530 Subject: Locked resources post execution In-Reply-To: <878qll1a1a.fsf@jacob.g10code.de> References: <878qll1a1a.fsf@jacob.g10code.de> Message-ID: Thanks Werner for your response. I am using the python-gnupg project to manage GPG related operations and I encountered an error where, after key creation, certain lock files remain in the system. Thinking that the lock files are left over by the subprocess calls this library makes to contact gpg, I raised the error as a GitHub issue in that library. After examining that issue, the author suggested that the leftover lock files may be a gpg issue and not a library issue. The whole error scenario and reproducibility steps are detailed in that issue . Request to kindly go through the issue link and check and reflect on it because the left over lock files: 1. may indicate leaked resources. 2. errs on next CLI runs. 3. A new subprocess may not behave correctly or simply not run because of the lock files. Thanks & Regards, Suhas On Sat, Jun 21, 2025 at 7:16?PM Werner Koch wrote: > Hi! > > > I even received a link to phabricator to set my password but opening that > > link brings up a 403 forbidden page. > > Please use a different browser. We are still under hefty DoS and from > time to time we need to lock out some user agent string (browser). > Thank you cheap AI. > > > - Examine whether this bug (possible anomaly) was reported earlier and > > the progress on its remediation. > > BTW, you can do this w/o an account. > > It might be easier for you to report it here here to share the problem > with a lot of other users. > > > Salam-Shalom, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorum_ipsum at nymph.paranoici.org Mon Jun 23 18:26:01 2025 From: lorum_ipsum at nymph.paranoici.org (Lorum Ipsum) Date: Mon, 23 Jun 2025 16:26:01 +0000 (UTC) Subject: Issues with 2.5.8. Message-ID: <20250623162601.EC05720357@remailer.paranoici.org> I just installed GnuPG 2.5.8., and immediately ran into issues with with it. The first issue was encrypting data: when attempting to encrypt a message, I got the following error message: gpg: pubkey_encrypt failed: Invalid data gpg: build_packet(PLAINTEXT) failed: Invalid data gpg: lorum_ipsum_setup.txt: sign+encrypt failed: Invalid data When attempting to decrypt a reply from the nymserver, I got the following: gpg: encrypted with secp256k1 key, ID 0xDEADBEEF, created 2025-06-23 "Lorum Ipsum " gpg: public key decryption failed: Bad secret key gpg: decryption failed: Bad secret key Needless to say, 2.5.6. performed flawlessly. N.B.: Because encryption failed using 2.5.8., I went back to 2.5.6. to encrypt the setup message to the nymserver. When I got an encrypted reply from the nymserver, and used 2.5.8. to decrypt it, I got the above error message. Again, 2.5.6. handled it flawlessly. Any ideas? I havae never seen anything like this before. Lorum_Ipsum From wk at gnupg.org Tue Jun 24 08:23:28 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Jun 2025 08:23:28 +0200 Subject: Issues with 2.5.8. In-Reply-To: <20250623162601.EC05720357@remailer.paranoici.org> (Lorum Ipsum via Gnupg-users's message of "Mon, 23 Jun 2025 16:26:01 +0000 (UTC)") References: <20250623162601.EC05720357@remailer.paranoici.org> Message-ID: <87ldphy7xb.fsf@jacob.g10code.de> On Mon, 23 Jun 2025 16:26, Lorum Ipsum said: > gpg: encrypted with secp256k1 key, ID 0xDEADBEEF, created 2025-06-23 secp256k1 is an --expert option and not supported by other *PGP implementations. We should actually hide this thing even more and not even display it with --expert. Thus do no expect an immediate 2.5.9 release to fix this issue. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 24 09:01:06 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Jun 2025 09:01:06 +0200 Subject: Locked resources post execution In-Reply-To: (Suhas Srivastava via Gnupg-users's message of "Sun, 22 Jun 2025 21:46:18 +0530") References: <878qll1a1a.fsf@jacob.g10code.de> Message-ID: <87h605y66l.fsf@jacob.g10code.de> On Sun, 22 Jun 2025 21:46, Suhas Srivastava said: > library. After examining that issue, the author suggested that the leftover > lock files may be a gpg issue and not a library issue. The whole error These lock files like ~/.gnupg/#lk0x0000558d3fe5e990.foo.24728 are created as part of atomic updates. If an update fails for example due to improper spawning of the gpg binary, gpg's cleanup can't run and thus the files will not removed. All classical Unix installations employ a cron job to remove files name ".#*" after a few days. If you have a lot of them there might be a problem in your python-gnupg library (SIGPIPE ignored?). I would suggest to switch to a gpgme based library like gpgme 1.24 or the new gpgmepy 2.0.0. 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 gniibe at fsij.org Tue Jun 24 08:11:03 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 24 Jun 2025 15:11:03 +0900 Subject: Issues with 2.5.8. In-Reply-To: <20250623162601.EC05720357@remailer.paranoici.org> References: <20250623162601.EC05720357@remailer.paranoici.org> Message-ID: <87ikkl6554.fsf@haruna.fsij.org> Lorum Ipsum wrote: > I just installed GnuPG 2.5.8., and immediately ran into issues with with it. > > The first issue was encrypting data: when attempting to encrypt a message, > I got the following error message: > > gpg: pubkey_encrypt failed: Invalid data > gpg: build_packet(PLAINTEXT) failed: Invalid data > gpg: lorum_ipsum_setup.txt: sign+encrypt failed: Invalid data > > When attempting to decrypt a reply from the nymserver, I got the following: > > gpg: encrypted with secp256k1 key, ID 0xDEADBEEF, created 2025-06-23 > "Lorum Ipsum " > gpg: public key decryption failed: Bad secret key > gpg: decryption failed: Bad secret key Sorry, those are regressions introduced by me. The intention of changes are internal ones to be friendly to crypto API standards. I'm going to fix the problem. It's tracked by: https://dev.gnupg.org/T7649 -- From damon.tu at outlook.com Tue Jun 24 04:39:29 2025 From: damon.tu at outlook.com (To Damon) Date: Tue, 24 Jun 2025 02:39:29 +0000 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> Message-ID: gpg (GnuPG) 2.4.8 still has these issues. Hi Werner Koch, would you mind taking a look at this issue when you have a moment? > On 13 Jun 2025, at 22:34, Andrew Gallagher wrote: > > On 13 Jun 2025, at 15:29, To Damon wrote: >> >>> gpg --list-secret-keys --with-fingerprint >> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 51f9e32f62fa6745c5cb09c2412a0000 >> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 577e8f3f61625918c9c53c226b335000 >> gpg: key 0000000000000000 occurs more than once in the trustdb >> gpg: checking the trustdb >> gpg: Note: ultimately trusted key 0000000000000000 not found >> gpg: no ultimately trusted keys found >> /home/user/.gnupg/pubring.kbx > > This looks like there is a second issue, which is that the trustdb was updated with a null fingerprint or long keyID, twice. Not clear from the outside whether this is a related bug or independent, but it all seems to indicate a baked-in assumption that fingerprints will never have a large number of trailing zeros... > > A > From ccogcj at gmail.com Tue Jun 24 15:08:05 2025 From: ccogcj at gmail.com (ccogcj@Gmail.com) Date: Tue, 24 Jun 2025 08:08:05 -0500 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> Message-ID: This has been an ongoing problem after the yang merge On Tue, Jun 24, 2025 at 4:05?AM To Damon via Gnupg-users < gnupg-users at gnupg.org> wrote: > gpg (GnuPG) 2.4.8 still has these issues. > > > Hi Werner Koch, would you mind taking a look at this issue when you have a > moment? > > > > On 13 Jun 2025, at 22:34, Andrew Gallagher wrote: > > > > On 13 Jun 2025, at 15:29, To Damon wrote: > >> > >>> gpg --list-secret-keys --with-fingerprint > >> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 51f9e32f62fa6745c5cb09c2412a0000 > >> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: > 577e8f3f61625918c9c53c226b335000 > >> gpg: key 0000000000000000 occurs more than once in the trustdb > >> gpg: checking the trustdb > >> gpg: Note: ultimately trusted key 0000000000000000 not found > >> gpg: no ultimately trusted keys found > >> /home/user/.gnupg/pubring.kbx > > > > This looks like there is a second issue, which is that the trustdb was > updated with a null fingerprint or long keyID, twice. Not clear from the > outside whether this is a related bug or independent, but it all seems to > indicate a baked-in assumption that fingerprints will never have a large > number of trailing zeros... > > > > A > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jun 25 17:50:08 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Jun 2025 17:50:08 +0200 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: (To Damon via Gnupg-users's message of "Tue, 24 Jun 2025 02:39:29 +0000") References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> Message-ID: <87o6ubx1lb.fsf@jacob.g10code.de> Hi! >>> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: >>> 51f9e32f62fa6745c5cb09c2412a0000 The trustdb is probably corrupt. Try this: $ gpg --fix-trustdb gpg: You may try to re-create the trustdb using the commands: gpg: cd ~/.gnupg gpg: gpg --export-ownertrust > otrust.tmp gpg: rm trustdb.gpg gpg: gpg --import-ownertrust < otrust.tmp Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From minfrin at sharp.fm Wed Jun 25 18:59:05 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Wed, 25 Jun 2025 17:59:05 +0100 Subject: Verifying multiple detached signatures avoiding "multiple signatures detected. Only the first will be checked" Message-ID: <8711441E-7C3D-4E8F-94D2-5272B3A80E47@sharp.fm> Hi all, I have a file, with multiple ascii armoured PGP signatures in them, and I want to count the number of valid signatures found. To verify them I run "gpg2 --verify sigs.asc", and the verify counts just one signature of the two that are present by giving up with the following warning: gpg: WARNING: multiple signatures detected. Only the first will be checked. Oops. Digging through archaeological layers of the internet we find this: https://lists.gnupg.org/pipermail/gnupg-devel/2013-January/027284.html Which summed up says concatenated signatures don't work unless they all have the same digest. Assuming concatenating signatures is wrong, can anyone confirm what the correct way is to handle this? Is there a way to combine the concatenated signature into one ascii armoured entity, something else? Regards, Graham -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From damon.tu at outlook.com Thu Jun 26 09:39:27 2025 From: damon.tu at outlook.com (To Damon) Date: Thu, 26 Jun 2025 07:39:27 +0000 Subject: Trust assignment fails for key with fingerprint ending in multiple zero blocks In-Reply-To: <87o6ubx1lb.fsf@jacob.g10code.de> References: <15477A3B-3F53-4272-9FA4-90A0B683475D@outlook.com> <5E8CE795-94C8-44ED-85B2-615A4B5C316F@andrewg.com> <6C1B8995-C00E-4056-835D-EF5B0233B2F9@outlook.com> <19A1CD22-D4E7-4403-8D41-5FAFF33C462C@andrewg.com> <87o6ubx1lb.fsf@jacob.g10code.de> Message-ID: <643D73C3-B800-4B34-9DB9-6D1510B19E42@outlook.com> I've tried to fix the trustdb following the recommended steps (exporting ownertrust, deleting trustdb.gpg, and importing ownertrust), but the issue still persists. When I run gpg --list-secret-keys --with-fingerprint --with-keygrip, I see the following warning: gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 51f9e32f62fa6745c5cb09c2412a0000 gpg: Note: ultimately trusted key 0000000000000000 not found gpg: no ultimately trusted keys found And when trying to sign: echo "test" | gpg --clear-sign --user 412A000000000000 I get: gpg: WARNING: recipients (-r) given without using public key encryption gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: 51f9e32f62fa6745c5cb09c2412a0000 It seems like the key is still missing or not trusted properly. Any ideas on what else I can try? > On 25 Jun 2025, at 23:50, Werner Koch wrote: > > Hi! > >>>> gpg: DBG: Oops: keyid_from_fingerprint: no pubkey; fpr: >>>> 51f9e32f62fa6745c5cb09c2412a0000 > > The trustdb is probably corrupt. Try this: > > $ gpg --fix-trustdb > gpg: You may try to re-create the trustdb using the commands: > gpg: cd ~/.gnupg > gpg: gpg --export-ownertrust > otrust.tmp > gpg: rm trustdb.gpg > gpg: gpg --import-ownertrust < otrust.tmp > > > Shalom-Salam, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein