From gnupg at jfr.im  Fri Feb  6 19:17:52 2026
From: gnupg at jfr.im (John Runyon)
Date: Fri, 6 Feb 2026 11:17:52 -0700
Subject: Extra socket forwarding - SUCKS
Message-ID: <CAN4EqKX-MNLW=zhJpyVU=0h6cWKPJGVeBBJdXPUuTcd4Q9rcSw@mail.gmail.com>

Ok, can we talk about how much of a pain it is to forward the extra socket
as a result of putting it in /run?

Like... "Note: On Systems where systemd controls the directories under
/var/run/user/<uid> it may be that the socket forwarding fails because
/var/run/user/<uid>/gnupg is deleted on logout. To workaround this you can
put gpgconf --create-socketdir in the startup script of your shell e.g.
~/.bashrc or ~/.zshrc." (https://wiki.gnupg.org/AgentForwarding)
Ok, this is just plain WRONG:
- Nothing relevant to systemd here. Nor is /var/ relevant. I don't even use
systemd. But, /run is *meant* to be cleared of files regularly, systemd or
not. (In fact, mine is a tmpfs.)
- The shell startup files are not run until AFTER the forwarding is
attempted (and FAILS). So you have to connect twice for this to actually
work.

As far as I can tell, an actual solution is creating
user-tmpfiles.d/gnupg.conf with:
d /run/user/%U 0700
d /run/user/%U/gnupg 0700

Along with a separate script:
su -c 'systemd-tmpfiles --user --create --remove' $PAM_USER

AND a PAM config to run that script (early enough that it happens before
SSH tries to create the socket):
-session        optional    pam_exec.so quiet_log
/usr/local/sbin/run-systemd-tmpfiles

(Of course, this still has the problem that it's reliant on a UID that
often changes between systems rather than a username which is, for most
people, identical across systems, but oh well)

Great fun! Good luck!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260206/1d033d9f/attachment-0001.html>

From bluestreak1776 at gmail.com  Fri Feb  6 20:58:01 2026
From: bluestreak1776 at gmail.com (Bluestreak)
Date: Fri, 06 Feb 2026 12:58:01 -0700
Subject: Gnupg-users Digest, Vol 269, Issue 1
In-Reply-To: <mailman.10419.1770406040.18299.gnupg-users@gnupg.org>
References: <mailman.10419.1770406040.18299.gnupg-users@gnupg.org>
Message-ID: <C4549EB3-7D80-4635-B6A5-A0B74A5CF2E2@gmail.com>

STOP

On February 6, 2026 12:27:20 PM MST, gnupg-users-request at gnupg.org wrote:
>Send Gnupg-users mailing list submissions to
>	gnupg-users at gnupg.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.gnupg.org/mailman/listinfo/gnupg-users
>or, via email, send a message with subject or body 'help' to
>	gnupg-users-request at gnupg.org
>
>You can reach the person managing the list at
>	gnupg-users-owner at gnupg.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Gnupg-users digest..."
>
>
>Today's Topics:
>
>   1. Re: Bad signatures issued on macOS (John Soo)
>   2. Re: Bad signatures issued on macOS (Werner Koch)
>   3. [Announce] Libgcrypt 1.12.0 released (Werner Koch)
>   4. Extra socket forwarding - SUCKS (John Runyon)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 28 Jan 2026 10:38:37 -0700
>From: John Soo <john.soo+gnupg-users at arista.com>
>To: John Soo via Gnupg-users <gnupg-users at gnupg.org>, John Soo
>	<john.soo+gnupg-users at arista.com>
>Subject: Re: Bad signatures issued on macOS
>Message-ID:
>	<CAJyRyRroZaE2ZySmO6R-fmYW2kAHuRtWAW+F+vgHKTmKU5itHg at mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>Thanks Werner!
>
>I tried with -v --debug hashing and the content for hashing was not
>printed, is there another flag I need to use?
>
>For reference, this was a good sig:
>
>gpg: reading options from '[cmdline]'
>gpg: reading options from '/Users/<redacted>/.gnupg/common.conf'
>gpg: enabled debug flags: hashing
>gpg: enabled compatibility flags:
>gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED
>gpg: writing to 'data.txt.asc'
>gpg: RSA/SHA256 signature from: "B67EB1E57374A315 <redacted>"
>gpg: secmem usage: 1344/32768 bytes in 2 blocks
>
>signature was
>-----BEGIN PGP SIGNATURE-----
>
>iQEzBAABCAAdFiEEG34w4o9D0vlGnPYqtn6x5XN0oxUFAml6SJwACgkQtn6x5XN0
>oxXMrgf9HQbhUZZUp+pPHSpT5Rw3GvnJLH5Sq5KUtmEYs0PArjwNN86OeHN+EENd
>f5F2PXHCTtNgY4OKibm5iJWO1qsCVKJeg/nhdqdx6xLuskAzBi5ogKJOfORSYKpY
>vLvRWbK55ag4iZqxeLJHrt6Chu9qsdlPyWMptzSQGlX2+9fVybmghdthFiUUOoBk
>FZDXuH1s30pUha7h4mNAn52A3P8pIpqX4f46vRTCYqjTtRuc1bXotQFvcmv8WmP+
>URcluMyQc4G5eSBGAeTODtgOBTLntvWMbFxLopO9o7HSIiKUNqgJxl6ZtUzbUxQu
>hziwl6C2gT+1/OUn16hz1m8cIEkAJA==
>=m0Gd
>-----END PGP SIGNATURE-----
>
>verification was
>gpg: reading options from '[cmdline]'
>gpg: reading options from '/Users/<redacted>/.gnupg/common.conf'
>gpg: enabled debug flags: hashing
>gpg: enabled compatibility flags:
>gpg: Signature made Wed Jan 28 11:34:20 2026 CST
>gpg:                using RSA key 1B7E30E28F43D2F9469CF62AB67EB1E57374A315
>gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED
>gpg: using pgp trust model
>gpg: Good signature from "<redacted>" [unknown]
>gpg: WARNING: This key is not certified with a trusted signature!
>gpg:          There is no indication that the signature belongs to the owner.
>Primary key fingerprint: 1510 C864 04E2 F6EC A028  71DB 6E62 8CC4 145F D2ED
>     Subkey fingerprint: 1B7E 30E2 8F43 D2F9 469C  F62A B67E B1E5 7374 A315
>gpg: binary signature, digest algorithm SHA256, key algorithm rsa2048
>gpg: secmem usage: 0/32768 bytes in 0 blocks
>result: succeeded
>
>
>--- John
>
>On Wed, Jan 28, 2026 at 7:19?AM Werner Koch <wk at gnupg.org> wrote:
>>
>> Hi!
>>
>> On Tue, 27 Jan 2026 15:33, John Soo said:
>>
>> > Running the following script will often issue a bad signature after
>> > only a few rounds:
>>
>> You may run into problems when mixing stdout and stderr (&>FILE).  Also
>> please do not use --debug-level guto or any other of those debug
>> levels; they are too noisy or don't print what you want.
>>
>> Always use -v or --verbose and then selected debug flags.  In your case
>> I would suggest
>>
>>   --debug hashing
>>
>> which writes files with what was actually hashed for signature creation
>> and verification.  Compare them.
>>
>>
>>
>> Shalom-Salam,
>>
>>    Werner
>>
>>
>> --
>> The pioneers of a warless world are the youth that
>> refuse military service.             - A. Einstein
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 29 Jan 2026 10:53:23 +0100
>From: Werner Koch <wk at gnupg.org>
>To: John Soo via Gnupg-users <gnupg-users at gnupg.org>
>Cc: John Soo <john.soo+gnupg-users at arista.com>
>Subject: Re: Bad signatures issued on macOS
>Message-ID: <87ms1wycbw.fsf at jacob.g10code.de>
>Content-Type: text/plain; charset="us-ascii"
>
>On Wed, 28 Jan 2026 10:38, John Soo said:
>> Thanks Werner!
>>
>> I tried with -v --debug hashing and the content for hashing was not
>> printed, is there another flag I need to use?
>
>Let's see using some arbitrary signature
>
>  $ gpg --verify --debug hashing swdb.lst.sig swdb.lst
>  
>  gpg: reading options from '/home/wk/.gnupg/gpg.conf'
>  gpg: reading options from '[cmdline]'
>  gpg: reading options from '/home/wk/.gnupg/common.conf'
>  gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
>  gpg: It is only intended for test purposes and should NOT be
>  gpg: used in a production environment or with production keys!
>  gpg: enabled debug flags: hashing
>  gpg: enabled compatibility flags:
>  gpg: Signature made Fri 23 Feb 2024 02:34:37 PM CET
>  gpg:                using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
>  gpg: using pgp trust model
>  gpg: please do a --check-trustdb
>  gpg: Good signature from "Werner Koch (dist signing 2020)" [ultimate]
>  gpg: binary signature, digest algorithm SHA256, key algorithm ed25519
>  gpg: secmem usage: 0/32768 bytes in 0 blocks
>
>  $ ls -lt | head -3
>  total 29839972
>  -rw-r--r--   1 wk   wk          4725 Jan 29 10:44 dbgmd-00001.verify
>  -rw-r--r--   1 wk   wk            41 Jan 29 10:44 dbgmd-00002.unknown
>
>dbgmd-00001.verify is the same as swdb.lst
>dbgmd-00002.unknown is the trailer hashed after swdb.lst.
>
>When creating the signature you should have seen
>dbgmd-00001.sign with the to be signed data
>dbgmd-00001.unknown with the trailer.
>
>dbgmd-00001.unknown gets overwritten so you need to store it away for
>later comparing.
>
>
>Salam-Shalom,
>
>   Werner
>
>
>-- 
>The pioneers of a warless world are the youth that
>refuse military service.             - A. Einstein
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: openpgp-digital-signature.asc
>Type: application/pgp-signature
>Size: 284 bytes
>Desc: not available
>URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260129/37cb8e79/attachment-0001.sig>
>
>------------------------------
>
>Message: 3
>Date: Thu, 29 Jan 2026 14:09:43 +0100
>From: Werner Koch <wk at gnupg.org>
>To: gnupg-announce at gnupg.org
>Cc: info-gnu at gnu.org
>Subject: [Announce] Libgcrypt 1.12.0 released
>Message-ID: <87ecn8y38o.fsf at jacob.g10code.de>
>Content-Type: text/plain; charset="utf-8"
>
>Hello!
>
>We are pleased to announce the availability of Libgcrypt version 1.12.0.
>
>This release starts a new stable branch of Libgcrypt with full API and
>ABI compatibility to the 1.11 series.  Since the last major release
>Jussi Kivilinna put again a lot of work into speeding up the algorithms
>for modern CPUs.  Niibe-san implemented new APIs and algorithms and
>adjusted the interface for new FIPS requirements.  See below for a list
>of improvements and new features in 1.12.
>
>Libgcrypt is a general purpose library of cryptographic building blocks.
>It does not provide implementations of protocols like *PGP.  Thorough
>understanding of applied cryptography is required for safe use of
>Libgcrypt.
>
>
>Noteworthy changes in version 1.12.0 (2026-01-29)
>-------------------------------------------------
>
> * New and extended interfaces:
>
>   - Allow access to the FIPS service indicator via the new
>     GCRYCTL_FIPS_SERVICE_INDICATOR control code.
>     [T7338,rCd0db6a5abf,rCf51f4e9893]
>
>   - Add GCRYCTL_FIPS_REJECT_NON_FIPS control code.  [T7338,rCe52adf0948]
>
>   - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS constant.  [T7338,rC0414e126b9]
>
>   - Make SHA-1 non-FIPS internally for the 1.12 API.  This introduces
>     the GCRY_FIPS_FLAG_REJECT_MD_SHA1 constant.  [rC4ee91a94bc]
>
>   - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS.  [rC0414e126b9]
>
>   - Provide macros for each KEM enum constant.  [rCe9b1c3ec91]
>
>   - Add Dilithium (ML-DSA) support.  [T7640]
>
>   - Support optional random-override and support byte string data.
>     [rCcbefff5fca,rC3bb4a54f43]
>
> * Performance:
>
>   - Add VAES/AVX512 accelerated implementation for AES which boosts
>     OCB performance by about 2 times on AMD Zen5.  [rC9e3af928ee]
>
>   - Avoid AVX512/AVX2/SSSE3 for single block processing with Zen5 for
>     ChaCha20.  [rCc1d9fff3b2]
>
>   - Avoid AVX/AVX2/AVX512 when CPU has high vector inst latency like
>     Zen5 for Blake2.  [rCe5bc3b2826]
>
>   - Various optimizations for Camellia.
>     [rCf5848080d4,rCb9bafd6c6c,rC8b538a8c76]
>
>   - Add POLYVAL acceleration for RISC-V and GCM-SIV.  [rC00815c4207]
>
>   - Add RISC-V Zbb+Zbc implementation of CRC.  [rCab4fa2a19c]
>
>   - Add RISC-V vector cryptography implementation of GHASH.
>     [rCcc2a4b6388]
>
>   - Add RISC-V vector cryptography implementation of AES.
>     [rCb000ab6025]
>
>   - Add RISC-V vector cryptography implementations of SHA256 and
>     SHA512.  [rCcc1d5b0b5e]
>
>   - Add AVX2 and AVX512 code paths to improve CRC.  [rCc30788969d]
>
> * Bug fixes:
>
>   - Use secure MPI in _gcry_mpi_assign_limb_space.  [rC6e77b09cff]
>
>   - Use CSIDL_COMMON_APPDATA instead of /etc on Windows.  [rCd5e3cbfd88]
>
>   - Apply a Kyber patch from upstream.  [rCbdc3724d72]
>
>   - Fix an edge case in Jent initialization.  [rC0ceca9993f]
>
>   - mceliece6688128f: Fix stack overflow crash on win64/wine
>     [rC5bd9320171]
>
> * Other:
>
>  - Add support for IBM z/OS, fixing -lpthread check with glibc.
>    [rC5af59d8454]
>
>  - Introduce mpi_tfr and use it for point_tfr to decrease EM signal
>    and increase EM noise.  [rC4e65996bb8]
>
>  - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN.
>    [T7889]
>
>  - Harden mask generation against branch optimization for several
>    algorithms.  [e.g. rC4012e9a037,rCbf7546c502,rC052b03fb0c]
>
>  - Improve constant-time operation for ECDSA.  [T7519,rC0bd4c77be6]
>
>
> Changes also found in 1.11.2:
>
> * Bug fixes:
>
>   - Fix link errors in regression test t-thread-local on some
>     platforms (e.g. NetBSD).  [T7634]
>
>   - Add missing file to allow building for RISC-V.  [T7647]
>
>   - Support secp256k1 by KEM API.  GnuPG has recently switched to use
>     the KEM interface and a few folks are using this curve.  [T7698]
>
>   - Fix a missing initialization in RSA's generate_fips.
>     [rG292cb75a72]
>
> * Other:
>
>   - Silence GCC 15 warnings [rCd5fb7cd9b3,T7617]
>
>   - Provide a prototype for __udiv_qrnnd for PowerPC and Alpha which
>     is required due to GCC-15 changes.  [T7721]
>
>   - Add missing abi versions and machine tags for PowerPC assembly
>     with GCC-15.  [T7721]
>
>   - Use '.rodata' section for read-only data of poly1305-p10le.
>     [T7721]
>
>
> Changes also found in 1.11.1:
>
> * Bug fixes:
>
>   - Fix build regression on 32 bit Windows using Clang. [T7175]
>
>   - Fix build regression on macOS due to symbol naming.  [T7170]
>
>   - Fix Kyber secret-dependent branch introduced by recent versions
>     of Clang.  [rCf765778e82]
>
>   - Fix build regression due to the use of AVX512 in Blake.  [T7184]
>
>   - Do not build i386 asm on amd64 and vice versa.  [T7220]
>
>   - Fix build regression on armhf with gcc-14.  [T7226]
>
>   - Return the proper error code on malloc failure in hex2buffer.
>     [rCc51151f5b0]
>
>   - Fix long standing bug for PRIME % 2 == 0.  [rC639b0fca15]
>
> * Performance:
>
>   - Add AES Vector Permute intrinsics implementation for AArch64.
>     [rC94a63aedbb]
>
>   - Add GHASH AArch64/SIMD intrinsics implementation.  [rCfec871fd18]
>
>   - Add RISC-V vector permute AES.  [rCb24ebd6163]
>
>   - Add GHASH RISC-V Zbb+Zbc implementation.  [rC0f1fec12b0]
>
>   - Add ChaCha20 RISC-V vector intrinsics implementation.
>     [rC8dbee93ac2]
>
>   - Add SHA3 acceleration for RISC-V Zbb extension.  [rC1a660068ba]
>
> * Other:
>
>   - Add CET support for i386 and amd64 assembly.  [T7220]
>
>   - Add PAC/BTI support for AArch64 asm.  [T7220]
>
>   - Apply changes to Kyber from upstream for final FIPS 203.
>     [rCcc95c36e7f]
>
>   - Introduce an internal API for a revampled FIPS service indicator.
>     [T7340]
>
>   - Several improvements for constant time operation by the
>     introduction of Least Leak Intended (LLI) variants of internal
>     functions.  [T7519,T7490]
>
>   - Remove WindowsCE support.  [T7486]
>
>
> * Interface changes relative to the 1.11.0 release:
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   GCRY_KEM_RAW_P256R1                   NEW enum and const.
>   GCRYCTL_FIPS_SERVICE_INDICATOR        NEW enum.
>   GCRYCTL_FIPS_REJECT_NON_FIPS          NEW enum.
>   GCRY_FIPS_FLAG_REJECT_PK_FLAGS        NEW const.
>   GCRY_FIPS_FLAG_REJECT_MD_SHA1         NEW const.
>
>
> For a list of links to commits and bug numbers see the release info at
> https://dev.gnupg.org/T7643
>
>
>
>Download
>========
>
>Source code is hosted at the GnuPG FTP server and its mirrors as listed
>at https://gnupg.org/download/mirrors.html.  On the primary server
>the source tarball and its digital signature are:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2.sig
>
>or gzip compressed:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz.sig
>
>In order to check that the version of Libgcrypt you downloaded is an
>original and unmodified file please follow the instructions found at
>https://gnupg.org/download/integrity_check.html.  In short, you may
>use one of the following methods:
>
> - Check the supplied OpenPGP signature.  For example to check the
>   signature of the file libgcrypt-1.12.0.tar.bz2 you would use this
>   command:
>
>     gpg --verify libgcrypt-1.12.0.tar.bz2.sig libgcrypt-1.12.0.tar.bz2
>
>   This checks whether the signature file matches the source file.
>   You should see a message indicating that the signature is good and
>   made by one or more of the release signing keys.  Make sure that
>   this is a valid key, either by matching the shown fingerprint
>   against a trustworthy list of valid release signing keys or by
>   checking that the key has been signed by trustworthy other keys.
>   See the end of this mail for information on the signing keys.
>
> - If you are not able to use an existing version of GnuPG, you have
>   to verify the SHA-1 checksum.  On Unix systems the command to do
>   this is either "sha1sum" or "shasum".  Assuming you downloaded the
>   file libgcrypt-1.12.0.tar.bz2, you run the command like this:
>
>     sha1sum libgcrypt-1.12.0.tar.bz2
>
>   and check that the output matches the first line from the
>   this list:
>
>02f80e9bc9967609b7041ef874eae4e542f240a5  libgcrypt-1.12.0.tar.bz2
>1327dd6ca3ec2309ac750ef1c01cbd96432f11a8  libgcrypt-1.12.0.tar.gz
>
>   You should also verify that the checksums above are authentic by
>   matching them with copies of this announcement.  Those copies can be
>   found at other mailing lists, web sites, and search engines.
>
>
>Copying
>=======
>
>Libgcrypt is distributed under the terms of the GNU Lesser General
>Public License (LGPLv2.1+).  The helper programs as well as the
>documentation are distributed under the terms of the GNU General Public
>License (GPLv2+).  The file LICENSES has notices about contributions
>that require that these additional notices are distributed.
>
>
>Support
>=======
>
>For help on developing with Libgcrypt you should read the included
>manual and if needed ask on the gcrypt-devel mailing list.
>
>In case of problems specific to this release please first check
>https://dev.gnupg.org/T7643 for updated information.
>
>Please also consult the archive of the gcrypt-devel mailing list before
>reporting a bug: https://gnupg.org/documentation/mailing-lists.html .
>We suggest to send bug reports for a new release to this list in favor
>of filing a bug at https://bugs.gnupg.org.  If you need commercial
>support go to https://gnupg.com or https://gnupg.org/service.html .
>
>Please see https://gnupg.org/documentation/security.html for information
>on how to report security issues and for our threat model.
>
>If you are a developer and you need a certain feature for your project,
>please do not hesitate to bring it to the gcrypt-devel mailing list for
>discussion.
>
>
>Thanks
>======
>
>Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
>and has mostly been financed by donations.  Several full-time employed
>developers and contractors are working exclusively on GnuPG and closely
>related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.
>
>Fortunately, and this is still not common with free software, we have
>now established a way of financing the development while keeping all our
>software free and freely available for everyone.  Our model is similar
>to the way RedHat manages RHEL and Fedora: Except for the actual binary
>of the MSI installer for Windows and client specific configuration
>files, all the software is available under the GNU GPL and other Open
>Source licenses.  Thus customers may even build and distribute their own
>version of the software as long as they do not use our trademarks
>GnuPG Desktop? or GnuPG VS-Desktop?.
>
>We like to thank all the nice people who are helping the GnuPG project,
>be it testing, coding, translating, suggesting, auditing, administering
>the servers, spreading the word, answering questions on the mailing
>lists, or helping with donations.
>
>*Thank you all*
>
>   Your Libgcrypt hackers
>
>
>
>p.s.
>This is an announcement only mailing list.  Please send replies only to
>the gcrypt-devel'at'gnupg.org mailing list.
>
>* List of Release Signing Keys:
>  To guarantee that a downloaded GnuPG version has not been tampered by
>  malicious entities we provide signature files for all tarballs and
>  binary versions.  The keys are also signed by the long term keys of
>  their respective owners.  Current releases are signed by one or more
>  of these four keys:
>
>    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
>    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
>    Werner Koch (dist signing 2020)
>
>    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
>    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
>    Niibe Yutaka (GnuPG Release Key)
>
>    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
>    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
>    Alexander Kulbartsch (GnuPG Release Key)
>
>    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
>    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
>    GnuPG.com (Release Signing Key 2021)
>
>  The keys are available at https://gnupg.org/signature_key.html and in
>  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
>  Note that this mail has been signed by a different key.
>
>* Debian Package Signing Key:
>  The new Debian style packages are signed using this key:
>
>  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
>  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
>  GnuPG.org Package Signing Key <package-maintainers at gnupg.org>
>
>  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
>  of supported distributions and a download link for the key.
>
>-- 
>The pioneers of a warless world are the youth that
>refuse military service.             - A. Einstein
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: openpgp-digital-signature.asc
>Type: application/pgp-signature
>Size: 284 bytes
>Desc: not available
>URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260129/cb1db4ee/attachment-0001.sig>
>-------------- next part --------------
>_______________________________________________
>Gnupg-announce mailing list
>Gnupg-announce at gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-announce
>
>------------------------------
>
>Message: 4
>Date: Fri, 6 Feb 2026 11:17:52 -0700
>From: John Runyon <gnupg at jfr.im>
>To: gnupg-users at gnupg.org
>Subject: Extra socket forwarding - SUCKS
>Message-ID:
>	<CAN4EqKX-MNLW=zhJpyVU=0h6cWKPJGVeBBJdXPUuTcd4Q9rcSw at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Ok, can we talk about how much of a pain it is to forward the extra socket
>as a result of putting it in /run?
>
>Like... "Note: On Systems where systemd controls the directories under
>/var/run/user/<uid> it may be that the socket forwarding fails because
>/var/run/user/<uid>/gnupg is deleted on logout. To workaround this you can
>put gpgconf --create-socketdir in the startup script of your shell e.g.
>~/.bashrc or ~/.zshrc." (https://wiki.gnupg.org/AgentForwarding)
>Ok, this is just plain WRONG:
>- Nothing relevant to systemd here. Nor is /var/ relevant. I don't even use
>systemd. But, /run is *meant* to be cleared of files regularly, systemd or
>not. (In fact, mine is a tmpfs.)
>- The shell startup files are not run until AFTER the forwarding is
>attempted (and FAILS). So you have to connect twice for this to actually
>work.
>
>As far as I can tell, an actual solution is creating
>user-tmpfiles.d/gnupg.conf with:
>d /run/user/%U 0700
>d /run/user/%U/gnupg 0700
>
>Along with a separate script:
>su -c 'systemd-tmpfiles --user --create --remove' $PAM_USER
>
>AND a PAM config to run that script (early enough that it happens before
>SSH tries to create the socket):
>-session        optional    pam_exec.so quiet_log
>/usr/local/sbin/run-systemd-tmpfiles
>
>(Of course, this still has the problem that it's reliant on a UID that
>often changes between systems rather than a username which is, for most
>people, identical across systems, but oh well)
>
>Great fun! Good luck!
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260206/1d033d9f/attachment.html>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Gnupg-users mailing list
>Gnupg-users at gnupg.org
>https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
>------------------------------
>
>End of Gnupg-users Digest, Vol 269, Issue 1
>*******************************************

-- 
"I'm old but I'm not obsolete," 
Arnold Schwarzenegger 
Terminator Genisys
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260206/54bf3f13/attachment-0001.html>

From wk at gnupg.org  Mon Feb  9 11:27:26 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Feb 2026 11:27:26 +0100
Subject: Extra socket forwarding - SUCKS
In-Reply-To: <CAN4EqKX-MNLW=zhJpyVU=0h6cWKPJGVeBBJdXPUuTcd4Q9rcSw@mail.gmail.com>
 (John Runyon via Gnupg-users's message of "Fri, 6 Feb 2026 11:17:52
 -0700")
References: <CAN4EqKX-MNLW=zhJpyVU=0h6cWKPJGVeBBJdXPUuTcd4Q9rcSw@mail.gmail.com>
Message-ID: <87v7g6b4a9.fsf@jacob.g10code.de>

Hi!

On Fri,  6 Feb 2026 11:17, John Runyon said:
> Ok, can we talk about how much of a pain it is to forward the extra socket
> as a result of putting it in /run?

The problem is if there is no /run/user directory.  I think systemd
creates these directories; on other systems

--8<---------------cut here---------------start------------->8---
[ ! -d /run/user ] && mkdir /run/user
awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
  | ( while read uid rest; do
        if [ ! -d "/run/user/$uid" ]; then
          mkdir /run/user/$uid
          chown $uid /run/user/$uid
          chmod 700 /run/user/$uid
        fi
      done )
--8<---------------cut here---------------end--------------->8---

in /etc/rc.local might be helpful.  And of course you need to

  loginctl enable-linger USER

once for each desired user.  The socket directories are created by GnuPG
on-the-fly - but not the top directories to to insufficent permissions.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260209/2b09b1a5/attachment.sig>

From john.soo+gnupg-users at arista.com  Thu Feb 12 18:48:54 2026
From: john.soo+gnupg-users at arista.com (John Soo)
Date: Thu, 12 Feb 2026 10:48:54 -0700
Subject: Bad signatures issued on macOS
In-Reply-To: <87ms1wycbw.fsf@jacob.g10code.de>
References: <CAJyRyRrs9-xq3y-46ZXbhZepAuq97v-WFCQLvveJYf8KsuO8-w@mail.gmail.com>
 <87h5s5zuj9.fsf@jacob.g10code.de>
 <CAJyRyRroZaE2ZySmO6R-fmYW2kAHuRtWAW+F+vgHKTmKU5itHg@mail.gmail.com>
 <87ms1wycbw.fsf@jacob.g10code.de>
Message-ID: <CAJyRyRq1GDuvw_-fjyzqJK-E-KogfKtrTP7-ZNtBJ2a+4Q2uag@mail.gmail.com>

Hi Werner, thank you!

Attached is the result of a good and a bad signature using the attached
script. I see no difference in the trailer or signed data or swdb.lst

Do you have any ideas what might be going on?

Thank you,

John

On Thu, Jan 29, 2026 at 2:49?AM Werner Koch <wk at gnupg.org> wrote:

> On Wed, 28 Jan 2026 10:38, John Soo said:
> > Thanks Werner!
> >
> > I tried with -v --debug hashing and the content for hashing was not
> > printed, is there another flag I need to use?
>
> Let's see using some arbitrary signature
>
>   $ gpg --verify --debug hashing swdb.lst.sig swdb.lst
>
>   gpg: reading options from '/home/wk/.gnupg/gpg.conf'
>   gpg: reading options from '[cmdline]'
>   gpg: reading options from '/home/wk/.gnupg/common.conf'
>   gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
>   gpg: It is only intended for test purposes and should NOT be
>   gpg: used in a production environment or with production keys!
>   gpg: enabled debug flags: hashing
>   gpg: enabled compatibility flags:
>   gpg: Signature made Fri 23 Feb 2024 02:34:37 PM CET
>   gpg:                using EDDSA key
> 6DAA6E64A76D2840571B4902528897B826403ADA
>   gpg: using pgp trust model
>   gpg: please do a --check-trustdb
>   gpg: Good signature from "Werner Koch (dist signing 2020)" [ultimate]
>   gpg: binary signature, digest algorithm SHA256, key algorithm ed25519
>   gpg: secmem usage: 0/32768 bytes in 0 blocks
>
>   $ ls -lt | head -3
>   total 29839972
>   -rw-r--r--   1 wk   wk          4725 Jan 29 10:44 dbgmd-00001.verify
>   -rw-r--r--   1 wk   wk            41 Jan 29 10:44 dbgmd-00002.unknown
>
> dbgmd-00001.verify is the same as swdb.lst
> dbgmd-00002.unknown is the trailer hashed after swdb.lst.
>
> When creating the signature you should have seen
> dbgmd-00001.sign with the to be signed data
> dbgmd-00001.unknown with the trailer.
>
> dbgmd-00001.unknown gets overwritten so you need to store it away for
> later comparing.
>
>
> Salam-Shalom,
>
>    Werner
>
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260212/34ec07f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invalid-sigs-macos.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260212/34ec07f8/attachment.tar>

From gniibe at fsij.org  Fri Feb 13 03:17:49 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 13 Feb 2026 11:17:49 +0900
Subject: Bad signatures issued on macOS
In-Reply-To: <CAJyRyRq1GDuvw_-fjyzqJK-E-KogfKtrTP7-ZNtBJ2a+4Q2uag@mail.gmail.com>
References: <CAJyRyRrs9-xq3y-46ZXbhZepAuq97v-WFCQLvveJYf8KsuO8-w@mail.gmail.com>
 <87h5s5zuj9.fsf@jacob.g10code.de>
 <CAJyRyRroZaE2ZySmO6R-fmYW2kAHuRtWAW+F+vgHKTmKU5itHg@mail.gmail.com>
 <87ms1wycbw.fsf@jacob.g10code.de>
 <CAJyRyRq1GDuvw_-fjyzqJK-E-KogfKtrTP7-ZNtBJ2a+4Q2uag@mail.gmail.com>
Message-ID: <877bsh75f6.fsf@haruna.fsij.org>

Hello,

John Soo wrote:
> Do you have any ideas what might be going on?

In the original message of yours on January 28th, the log has:

==========================
gpg: DBG: finish_lookup: checking key 145FD2ED (one)(req_usage=1,verify)
gpg: DBG: exact search requested and found
gpg: DBG: checking subkey 7374A315
gpg: DBG: subkey might be fine for verification
gpg: DBG: using key 7374A315
gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED
gpg: DBG: [no clock] enter pk_verify
gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[...]
gpg: DBG: rsa_verify  sig:+c64e97c7aa8ea26a172a1589cfc8f60189ae61b895e07d3562e9bf11d60e5f44
\
[...]
gpg: DBG: rsa_verify    n:+c744addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380 \
[...]
gpg: DBG: rsa_verify    e:+010001
gpg: DBG: rsa_verify  cmp:+c742addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380
\
[...]
gpg: DBG: rsa_verify    => Bad signature
==========================

The problem is the line:

    n:+c744addf555d5da3828c0c80b5d1d18e94ef5e5933659ed7a669dc1dc2608380
    ...

According to the other part of the log, it is your RSA public raw
material of your primary key 1510C86404E2F6ECA02871DB6E628CC4145FD2ED.

The problem here is that: the subkey
1B7E30E28F43D2F9469CF62AB67EB1E57374A315 was retrieved correctly, but
the key used for verification was
1510C86404E2F6ECA02871DB6E628CC4145FD2ED for some reason.

If you want to debug further, you don't need to generate multiple
signatures, but do test verification multiple times on a single
signature.

This is my observation.  I have no idea why gpg confused
between primary key and subkey on your system occasionally.
-- 


From wk at gnupg.org  Fri Feb 13 12:15:37 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Feb 2026 12:15:37 +0100
Subject: Bad signatures issued on macOS
In-Reply-To: <877bsh75f6.fsf@haruna.fsij.org> (NIIBE Yutaka via Gnupg-users's
 message of "Fri, 13 Feb 2026 11:17:49 +0900")
References: <CAJyRyRrs9-xq3y-46ZXbhZepAuq97v-WFCQLvveJYf8KsuO8-w@mail.gmail.com>
 <87h5s5zuj9.fsf@jacob.g10code.de>
 <CAJyRyRroZaE2ZySmO6R-fmYW2kAHuRtWAW+F+vgHKTmKU5itHg@mail.gmail.com>
 <87ms1wycbw.fsf@jacob.g10code.de>
 <CAJyRyRq1GDuvw_-fjyzqJK-E-KogfKtrTP7-ZNtBJ2a+4Q2uag@mail.gmail.com>
 <877bsh75f6.fsf@haruna.fsij.org>
Message-ID: <878qcwao86.fsf@jacob.g10code.de>

On Fri, 13 Feb 2026 11:17, NIIBE Yutaka said:

> If you want to debug further, you don't need to generate multiple
> signatures, but do test verification multiple times on a single

Please use GnuPG 2.5.17 for this becuase I do not think that we will fix
that in the 2.4 branch.  I am not sure whether a macOS version exists
but it should be not too complicate to build it for macOS.  BTW, we
consider to provide macOS versions in the not-too-far future.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260213/c50c1c4c/attachment.sig>

From rjh at sixdemonbag.org  Fri Feb 13 18:35:50 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 13 Feb 2026 12:35:50 -0500
Subject: A big thank you.
Message-ID: <2725528f-f7e5-4ccf-901b-2f205a32b6af@sixdemonbag.org>

A big thank you to everyone responsible for building GnuPG, MacGPG, 
OpenPGP, libRNP, and LibrePGP. For the last few weeks I've been 
supporting someone in a domestic violence situation whose communications 
are closely monitored. GnuPG on macOS, libRNP, and Thunderbird have 
played important roles in allowing this person to communicate with 
attorneys and get help.

Obviously I'm not at liberty to give specifics, but I think a public 
thank-you is much deserved.

Thank you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260213/d072258a/attachment.sig>

From oub at mat.ucm.es  Tue Feb 17 15:52:38 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Tue, 17 Feb 2026 15:52:38 +0100
Subject: Problem with gpgsm --import and p12 files issued from a Spanish
 government agency
Message-ID: <874infv2vd.fsf@mat.ucm.es>



I am on Ubuntu 24.04 with
gpgsm --version
gpgsm (GnuPG) 2.4.4
libgcrypt 1.10.3
libksba 1.6.6

I have been using X509 generated by the Spanish FNMT sucessfully over
the last 10 years and imported them without problems into gpgsm.

However when I today received a new one,
gpgsm --import Cert.p12 gave the following error.

--8<---------------cut here---------------start------------->8---
gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=18 (tlv_expect_sequence): Invalid object - General error
gpgsm: parse_bag_data(data.oid): lvl=18 (tlv_expect_sequence): Invalid object - General error
gpgsm: p12_parse(bag.data): @0133 lvl=18 tlv_expect_sequence: Invalid object - General error
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 0
secmem usage: 0/16384 bytes in 0 blocks

--8<---------------cut here---------------end--------------->8---

ChatGTP proposed the following fix

--8<---------------cut here---------------start------------->8---
openssl pkcs12 -in Cert.p12 -out aux.pem -nodes
openssl pkcs12   -export   -in aux.pem   -out fixed-cert.p12   -certpbe PBE-SHA1-3DES   -keypbe PBE-SHA1-3DES   -macalg sha1
--8<---------------cut here---------------end--------------->8---

Indeed
ggpsm --import fixed-cert.p12 worked

--8<---------------cut here---------------start------------->8---
```
gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 2157662 gnome3 1.2.1 /dev/pts/5 xterm :0 20600/1000/5 1000/1000 -
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- OK
gpgsm: total number processed: 4
gpgsm:              unchanged: 3
gpgsm:       secret keys read: 1
gpgsm:   secret keys imported: 1
secmem usage: 0/16384 bytes in 0 blocks

but then
--8<---------------cut here---------------end--------------->8---

gpgconf --launch gpg-agent
gpgsm --list-secret-keys --with-keygrip

--8<---------------cut here---------------start------------->8---
shows

     validity: 2026-02-17 09:49:30 through 2028-12-31 22:59:59
     key type: rsa2048
      keygrip: 507DB71D232AD938C7ADC69DA2C918F4C7B8D0B6
gpgsm: DBG: chan_4 -> HAVEKEY D73925535FE8FE641A63607EC09A9B1A4962A3B1
gpgsm: DBG: chan_4 <- ERR 67108881 No secret key <GPG Agent>
--8<---------------cut here---------------end--------------->8---


Another proposal was to use
--8<---------------cut here---------------start------------->8---
openssl pkcs12 -in orignal.p12 -nocerts -nodes -out key.pem
openssl pkcs12 -in orignal.p12 -nokeys -out certs.pem
openssl pkcs12 -export -in certs.pem -inkey key.pem -out final.p12 -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -macalg sha1
--8<---------------cut here---------------end--------------->8---

But it did not work neither.

Chatgpt claims that is a problem only present in gpgsm 2.4 and should work in gpgsm 2.3
Root cause
FNMT certificates are PKCS#12 with RSA 2048 keys.

gpgsm only supports certain encodings of private keys in PKCS#12. Even
though your two-step OpenSSL trick gets the key past the import,
gpg-agent 2.4+ cannot load it properly if it uses the default
keyEncipherment/PBE algorithm. The keygrip mismatch you see (507DB? vs
D7392?) is exactly this: the agent is trying to find a key matching its
expectations, but the key on disk doesn?t match its internal format.
Killing/relaunching the agent doesn?t help, because the format itself is
incompatible with gpg-agent?s PKCS#12 loader.


Any ideas what to do? I am using gpgsm mostly with emacs to sign and
encrypt my mails.


Regards

Uwe Brauer 


From wk at gnupg.org  Tue Feb 17 21:31:52 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Feb 2026 21:31:52 +0100
Subject: Problem with gpgsm --import and p12 files issued from a Spanish
 government agency
In-Reply-To: <874infv2vd.fsf@mat.ucm.es> (Uwe Brauer via Gnupg-users's message
 of "Tue, 17 Feb 2026 15:52:38 +0100")
References: <874infv2vd.fsf@mat.ucm.es>
Message-ID: <87bjhnw1qf.fsf@jacob.g10code.de>

On Tue, 17 Feb 2026 15:52, Uwe Brauer said:
> gpgsm (GnuPG) 2.4.4

That is pretty old.  Please use the latest version - at least of 2.4 but
better the new stable 2.5 version 2.5.7.  We have Debian packages
available for https://repos.gnupg.org/deb/gnupg/ and the fingerprint of
the signing key is listed with all release notes.

If that does not help, please add

  -v --debug memstat

to the gpgsm invocation which gives more detailed output.  Should not
show sensitive information but better check before posting.


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260217/1c22c66b/attachment.sig>

From oub at mat.ucm.es  Wed Feb 18 11:53:35 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Wed, 18 Feb 2026 11:53:35 +0100
Subject: Problem with gpgsm --import and p12 files issued from a Spanish
 government agency
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
Message-ID: <87qzqitj9s.fsf@mat.ucm.es>

>>> "WK" == Werner Koch <wk at gnupg.org> writes:

> On Tue, 17 Feb 2026 15:52, Uwe Brauer said:
>> gpgsm (GnuPG) 2.4.4

> That is pretty old.  Please use the latest version - at least of 2.4 but
> better the new stable 2.5 version 2.5.7.  We have Debian packages
> available for https://repos.gnupg.org/deb/gnupg/ and the fingerprint of
> the signing key is listed with all release notes.

> If that does not help, please add

>   -v --debug memstat

> to the gpgsm invocation which gives more detailed output.  Should not
> show sensitive information but better check before posting.

Thanks, I will do that later.

Additional information:

Before Ubuntu 24.04 I ran 16.04 with gpgsm 2.1.11

With that 2.1.11 version I could successfully import my last
certificate, that was issued in 2023. 

Just now I tried to import it with my current 2.4.4 version and it
failed with the same error message.

So it rather seems to be a gpgsm problem, but I will do what you
suggested and report back

> Salam-Shalom,

>    Werner

-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel.
Stop the war in Gaza, guarantee humanitarian aid, and bring the hostages back.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 



From oub at mat.ucm.es  Wed Feb 18 15:02:36 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Wed, 18 Feb 2026 15:02:36 +0100
Subject: [Cannot install 2.5.7 in noble] (was: Problem with gpgsm --import and
 p12 files issued from a Spanish government agency)
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
Message-ID: <877bsatair.fsf_-_@mat.ucm.es>

>>> "WKvG" == Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:

> On Tue, 17 Feb 2026 15:52, Uwe Brauer said:
>> gpgsm (GnuPG) 2.4.4

> That is pretty old.  Please use the latest version - at least of 2.4 but
> better the new stable 2.5 version 2.5.7.  We have Debian packages
> available for https://repos.gnupg.org/deb/gnupg/ and the fingerprint of
> the signing key is listed with all release notes.

Hi 

I followed the instructions https://repos.gnupg.org/deb/gnupg/noble/

But the last step

sudo apt-get install gnupg2

Returns:

--8<---------------cut here---------------start------------->8---

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gnupg2 : Depends: gnupg (>= 2.5.17-1) but 2.4.4-2ubuntu17.4 is to be installed
E: Unable to correct problems, you have held broken packages.
--8<---------------cut here---------------end--------------->8---



From jb-gnumlists at wisemo.com  Wed Feb 18 23:20:07 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 18 Feb 2026 23:20:07 +0100
Subject: [Cannot install 2.5.7 in noble]
In-Reply-To: <877bsatair.fsf_-_@mat.ucm.es>
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <877bsatair.fsf_-_@mat.ucm.es>
Message-ID: <bacb0149-538c-de69-a046-3082ffd1f564@wisemo.com>

Dear Mr. Brauer


On 18/02/2026 15:02, Uwe Brauer via Gnupg-users wrote:
>>>> "WKvG" == Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:
>> On Tue, 17 Feb 2026 15:52, Uwe Brauer said:
>>> gpgsm (GnuPG) 2.4.4
>> That is pretty old.  Please use the latest version - at least of 2.4 but
>> better the new stable 2.5 version 2.5.7.  We have Debian packages
>> available for https://repos.gnupg.org/deb/gnupg/ and the fingerprint of
>> the signing key is listed with all release notes.
> Hi
>
> I followed the instructions https://repos.gnupg.org/deb/gnupg/noble/
>
> But the last step
>
> sudo apt-get install gnupg2
>
> Returns:
>
> --8<---------------cut here---------------start------------->8---
>
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>   gnupg2 : Depends: gnupg (>= 2.5.17-1) but 2.4.4-2ubuntu17.4 is to be installed
> E: Unable to correct problems, you have held broken packages.
> --8<---------------cut here---------------end--------------->8---
This seems more like an apt/dpkg problem than a gnupg problem, but
since you encountered this using an official gnupg repository, it
may still be on topic here.

 From my experience using apt/dpkg, I see too likely possibilities:

A: the Gnupg repository for noble does not include a gnupg package
new enough to satisfy the the "Depends" line in the gnupg2 package
in that same repository, if so that would be a problem for the
g10code people that manage repos.gnupg.org .

B: Some subtle bug/misfeature in apt itself causes it to try to
install a gnupg package from the Ubuntu repository instead of the
new one from the Gnupg repository.? If so, you need to explicitly
request the correct gnupg package with a command such as:

$ sudo apt-get install gnupg=2.5.17-1

(Add version numbers for related packages such as dirmngr etc. if you
keep getting similar errors for those)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From oub at mat.ucm.es  Thu Feb 19 08:24:19 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Thu, 19 Feb 2026 08:24:19 +0100
Subject: [Cannot install 2.5.7 in noble]
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <877bsatair.fsf_-_@mat.ucm.es>
 <bacb0149-538c-de69-a046-3082ffd1f564@wisemo.com>
Message-ID: <87ecmhryak.fsf@mat.ucm.es>

>>> "JBvG" == Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> writes:


Dear Mr. Bohm
> Dear Mr. Brauer



> From my experience using apt/dpkg, I see too likely possibilities:

> A: the Gnupg repository for noble does not include a gnupg package
> new enough to satisfy the the "Depends" line in the gnupg2 package
> in that same repository, if so that would be a problem for the
> g10code people that manage repos.gnupg.org .

> B: Some subtle bug/misfeature in apt itself causes it to try to
> install a gnupg package from the Ubuntu repository instead of the
> new one from the Gnupg repository.? If so, you need to explicitly
> request the correct gnupg package with a command such as:

Thanks for you detailed answer.


I tried out sudo apt-get install gnupg=2.5.17-1

And obtained
--8<---------------cut here---------------start------------->8---
The following packages have unmet dependencies:
 gnupg : Depends: dirmngr (>= 2.5.17-1)
         Depends: gpg (>= 2.5.17-1)
         Depends: gpg-agent (>= 2.5.17-1)
         Depends: gpgsm (>= 2.5.17-1)
         Depends: scdaemon (< 2.5.17-1.1~)
         Depends: scdaemon (>= 2.5.17-1)
         Breaks: dirmngr (< 2.5.17-1)
         Recommends: gnupg-utils (>= 2.5.17-1)
         Recommends: gpg-wks-client (>= 2.5.17-1) but 2.4.4-2ubuntu17.4 is to be installed
         Recommends: gpgv (>= 2.5.17-1)
         Breaks: dirmngr:i386 (< 2.5.17-1)
E: Unable to correct problems, you have held broken packages.

--8<---------------cut here---------------end--------------->8---
> $
not sure how to proceed.

Since as you said this is part of the ?official? release, recommended by
Werner Koch, I think I found a problem work to be addressed.
-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel.
Stop the war in Gaza, guarantee humanitarian aid, and bring the hostages back.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 




From oub at mat.ucm.es  Thu Feb 19 08:29:07 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Thu, 19 Feb 2026 08:29:07 +0100
Subject: [Cannot install 2.5.7 in noble]
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <877bsatair.fsf_-_@mat.ucm.es>
 <bacb0149-538c-de69-a046-3082ffd1f564@wisemo.com>
Message-ID: <877bs9ry2k.fsf@mat.ucm.es>


> Dear Mr. Brauer
> On 18/02/2026 15:02, Uwe Brauer via Gnupg-users wrote:
> This seems more like an apt/dpkg problem than a gnupg problem, but
> since you encountered this using an official gnupg repository, it
> may still be on topic here.

> From my experience using apt/dpkg, I see too likely possibilities:

> A: the Gnupg repository for noble does not include a gnupg package
> new enough to satisfy the the "Depends" line in the gnupg2 package
> in that same repository, if so that would be a problem for the
> g10code people that manage repos.gnupg.org .

> B: Some subtle bug/misfeature in apt itself causes it to try to
> install a gnupg package from the Ubuntu repository instead of the
> new one from the Gnupg repository.? If so, you need to explicitly
> request the correct gnupg package with a command such as:

> $ sudo apt-get install gnupg=2.5.17-1

> (Add version numbers for related packages such as dirmngr etc. if you
> keep getting similar errors for those)

Dear Mr Bohm

It seems that the following worked:


  sudo apt-get install libgcrypt20
  sudo apt-get install libgpg-error0
  sudo apt-get install gpgconf
  sudo apt-get install gpgsm 

Thanks

Uwe Brauer



From m at gnupg.org  Thu Feb 19 09:46:59 2026
From: m at gnupg.org (Meik Michalke)
Date: Thu, 19 Feb 2026 09:46:59 +0100
Subject: [Cannot install 2.5.7 in noble] (was: Problem with gpgsm --import
 and p12 files issued from a Spanish government agency)
In-Reply-To: <877bsatair.fsf_-_@mat.ucm.es>
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <877bsatair.fsf_-_@mat.ucm.es>
Message-ID: <2029627.JfuecHORi0@kasidy>

hi,

Am Mittwoch, 18. Februar 2026, 15:02:36 CET schrieb Uwe Brauer via Gnupg-
users:
> I followed the instructions https://repos.gnupg.org/deb/gnupg/noble/
> 
> But the last step
> 
> sudo apt-get install gnupg2
> 
> Returns:

that is actually not quite what's suggested by the instructions:

  Now you should be able to install/upgrade our packages:

  sudo apt update
  sudo apt upgrade
  sudo apt install gnupg2

we're following the recommendation for using apt instead of apt-get for 
interactive use (since the use of apt-get outside of scripts was discouraged 
years ago). AFAIK apt does a better job when it comes to dependency handling, 
in that it is better equipped to determine the optimal order of package 
replacements.

Am Donnerstag, 19. Februar 2026, 08:29:07 CET schrieb Uwe Brauer via Gnupg-
users:
> It seems that the following worked:
> 
> 
>   sudo apt-get install libgcrypt20
>   sudo apt-get install libgpg-error0
>   sudo apt-get install gpgconf
>   sudo apt-get install gpgsm

this looks to me like you had to find out a working order for yourself with 
apt-get in this case.

depending on your specific package selection, even apt may fail in finding a 
solution when multiple packages with interdependencies are to be replaced in 
one go. but it should at least return an insightful error message on why it is 
not able to satisfy the dependency tree.

there's also a blog article with some information on how to use 'apt policy' 
to look at the current package preferences when multiple versions are 
available:

https://gnupg.org/blog/20250827-new-repository.html


viele gr??e :: m.eik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260219/f4fc132a/attachment.sig>

From oub at mat.ucm.es  Fri Feb 20 18:02:09 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Fri, 20 Feb 2026 18:02:09 +0100
Subject: [Cannot install 2.5.7 in noble]
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <877bsatair.fsf_-_@mat.ucm.es> <2029627.JfuecHORi0@kasidy>
Message-ID: <87fr6vic1a.fsf@mat.ucm.es>

>>> "MMvG" == Meik Michalke via Gnupg-users <gnupg-users at gnupg.org> writes:

> hi,
> Am Mittwoch, 18. Februar 2026, 15:02:36 CET schrieb Uwe Brauer via Gnupg-
> users:
>> I followed the instructions https://repos.gnupg.org/deb/gnupg/noble/
>> 
>> But the last step
>> 
>> sudo apt-get install gnupg2
>> 
>> Returns:

> that is actually not quite what's suggested by the instructions:

>   Now you should be able to install/upgrade our packages:

>   sudo apt update
>   sudo apt upgrade
>   sudo apt install gnupg2


I did these steps but with apt-get
> we're following the recommendation for using apt instead of apt-get for 
> interactive use (since the use of apt-get outside of scripts was discouraged > years ago). AFAIK apt does a better job when it comes to dependency handling, 
> in that it is better equipped to determine the optimal order of package 
> replacements.


Ah I did not realize this, thanks for pointing out, next time, I will
try to be more careful.


> Am Donnerstag, 19. Februar 2026, 08:29:07 CET schrieb Uwe Brauer via Gnupg-
> users:
>> It seems that the following worked:
>> 
>> 
>> sudo apt-get install libgcrypt20
>> sudo apt-get install libgpg-error0
>> sudo apt-get install gpgconf
>> sudo apt-get install gpgsm

> this looks to me like you had to find out a working order for yourself with 
> apt-get in this case.

> depending on your specific package selection, even apt may fail in finding a 
> solution when multiple packages with interdependencies are to be replaced in 
> one go. but it should at least return an insightful error message on why it is 
> not able to satisfy the dependency tree.

> there's also a blog article with some information on how to use 'apt policy' 
> to look at the current package preferences when multiple versions are 
> available:

> https://gnupg.org/blog/20250827-new-repository.html

Thanks!



From oub at mat.ucm.es  Fri Feb 20 18:11:29 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Fri, 20 Feb 2026 18:11:29 +0100
Subject: Problem with gpgsm --import and p12 files issued from a Spanish
 government agency
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
Message-ID: <87a4x3iblq.fsf@mat.ucm.es>

>>> "WKvG" == Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:

> On Tue, 17 Feb 2026 15:52, Uwe Brauer said:
>> gpgsm (GnuPG) 2.4.4

> That is pretty old.  Please use the latest version - at least of 2.4 but
> better the new stable 2.5 version 2.5.7.  We have Debian packages
> available for https://repos.gnupg.org/deb/gnupg/ and the fingerprint of
> the signing key is listed with all release notes.

> If that does not help, please add

>   -v --debug memstat

> to the gpgsm invocation which gives more detailed output.  Should not
> show sensitive information but better check before posting.

It seems that successfully upgraded to 2.5.7
When running  
gpgsm --import New-Certificate.p12

I obtain 
--8<---------------cut here---------------start------------->8---

gpgsm: enabled debug flags: memstat
gpgsm: enabled compatibility flags:
gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpgsm: waiting for the agent to come up ... (8s)
gpgsm: connection to the agent established
--8<---------------cut here---------------end--------------->8---

Then a lot of 
lines like gpgsm: total number processed: 4
and then 
--8<---------------cut here---------------start------------->8---
gpgsm:               imported: 1
gpgsm:              unchanged: 2
gpgsm:       secret keys read: 1
gpgsm:   secret keys imported: 1
gpgsm: cert_chain_cache: cached=2
gpgsm: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpgsm: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpgsm: secmem usage: 0/16384 bytes in 0 blocks

gpgsm: DBG: _tlv_parser_new:1985: 0 at 0 (0x0000634260ae4860,7076)
--8<---------------cut here---------------end--------------->8---

So it seems to have worked 
also gpgsm --list-keys

Shows the key.

It is however not clear to me (or better said I forgot) how to tell
gpgsm now to use the new Certificate for signing.


Regards


Uwe Brauer 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5684 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260220/f6c9e335/attachment.bin>

From oub at mat.ucm.es  Fri Feb 20 22:12:55 2026
From: oub at mat.ucm.es (Uwe Brauer)
Date: Fri, 20 Feb 2026 22:12:55 +0100
Subject: [SOLVED] (was: Problem with gpgsm --import and p12 files issued from
 a Spanish government agency)
References: <874infv2vd.fsf@mat.ucm.es> <87bjhnw1qf.fsf@jacob.g10code.de>
 <87a4x3iblq.fsf@mat.ucm.es>
Message-ID: <87y0kngluw.fsf_-_@mat.ucm.es>

>>> "UBvG" == Uwe Brauer via Gnupg-users <gnupg-users at gnupg.org> writes:


> Shows the key.

> It is however not clear to me (or better said I forgot) how to tell
> gpgsm now to use the new Certificate for signing.



Well it seems that my experiments with chatgtp, creating a new
certificate via openssl and importing it, confused gpgsm. I deleted my
whole .gnupg directory used the backup from some days before and
imported the official certificate with 2.5.7, everything works now as
expected.

Thanks to all of you

Uwe Brauer 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5684 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260220/dfdfcf85/attachment-0001.bin>