From jcb62281 at gmail.com  Sun Feb  1 05:40:41 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sat, 31 Jan 2026 22:40:41 -0600
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <87jywxeggw.fsf@gmail.com>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee> <87bji9x5oq.fsf@jacob.g10code.de>
 <CAH8yC8m+wBzSB9yDhpO0cc5+FPi5Vh1NJEWDb9pGX-z+BRAckw@mail.gmail.com>
 <87jywxeggw.fsf@gmail.com>
Message-ID: <7bad5af1-879d-4b64-bcf9-f518b7f6265f@gmail.com>

On 1/31/26 13:21, Collin Funk via Gnupg-devel wrote:
> Jeffrey Walton via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
>> On Sat, Jan 31, 2026 at 8:36?AM Werner Koch via Gnupg-devel <
>> gnupg-devel at gnupg.org> wrote:
>>> On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
>>>> Address compiler warning when variable is unused because it?s used
>>>> only in assert.
>>> Anyone who defines NDEBUG does not known what s/he does.  An assert is
>>> there for a reason.  It is plain stupid to use an assert but disable it
>>> for production.
>> Asserts are a debugging and diagnostic tool.  Confer, <
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html>.
>> Asserts should not be enabled in production software.
> I generally agree, but there is some benefit to having a program crash
> instead of continuing in an undefined state.

There is also the small matter that we are talking about assertions in a 
testsuite, not the main program that will actually be installed.? These 
programs help to validate that the main program was probably actually 
compiled correctly.

Maybe adding "#undef NDEBUG" to each C source file in the testsuite 
would be a more appropriate solution to these warnings?

>> If an assert triggers, it usually causes a program to crash.  Sensitive
>> data can leave the app's security boundary and be egressed through the
>> crash dump or report.  Companies like Apple, Canonical, Google and
>> Microsoft could have access to the sensitive data.
>>
>> I've even seen asserts used in BitCoin wallets, and the crash reports
>> uploaded to Microsoft App Center Diagnostics.  The private keys for the
>> wallets were burned!
>>
>> I've never seen a project document that private keys and shared secrets
>> should be rotated after a program crashes due to an assert.
> Yeah, that is bad.

GPG also has its own assertion infrastructure for checks that remain 
effective in production builds, and presumably kills the process in a 
controlled manner that avoids potentially including sensitive 
information in a crash dump.

Remember that GPG has a "secmem" facility for storing sensitive data.? I 
would be surprised to see a similar feature in a typical BitCoin wallet, 
just as I would be very surprised if Werner Koch had not considered and 
addressed this risk in GPG years ago.


-- Jacob




From bernhard at intevation.de  Tue Feb  3 10:27:57 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 10:27:57 +0100
Subject: git.gnupg.org access does not work 404
Message-ID: <202602031028.04123.bernhard@intevation.de>

Hi,
https://git.gnupg.org/ gives me 404
  Not Found
  The requested URL was not found on this server.

Linked from https://gnupg.org/download/git.html
where they point here for reporting.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260203/d2e34642/attachment.sig>

From bernhard at intevation.de  Tue Feb  3 10:57:41 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 10:57:41 +0100
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <aTBx3FDrY6YrpBjN@watt.59.ca>
References: <20251203113804.21c3fe3c@hermes.development.it>
 <aTBx3FDrY6YrpBjN@watt.59.ca>
Message-ID: <202602031057.48019.bernhard@intevation.de>

Hi,

Am Mittwoch 03 Dezember 2025 18:22:36 schrieb Bruce Walzer via Gnupg-devel:
> > The scenario is running "gpg --locate-keys email at example.org" with the
> > configured keyservers returning different keys for that email address.
>
> So the problem seems intrinsic to me. The user will
> eventually be expected to determine which key fingerprint/ID is
> correct.

note that if you restrict your request to WKD (web key directory)
you can use all pubkeys you will get. Which will be one.
So there is no interaction necessary in the common case,
you can just encrypt to the pubkey you get from WKD for an email address.


gpg  --locate-keys --auto-key-locate clear,nodefault,wkd 
bernhard.reiter at intevation.de 

or gpg  --locate-external-keys --auto-key-locate clear,nodefault,wkd 
bernhard.reiter at intevation.de

should help you test this. (Should be possible via GPGME as well.)

WKD should be enabled and used by default
and Claws can do some more steps to do that right from the start.

See:
 https://wiki.gnupg.org/EMailClients/ClawsMail
 https://wiki.gnupg.org/WKD/BachelorThesisIncreaseWKDUsage2021
 https://wiki.gnupg.org/WKD/DistributionOfWKD
 https://wiki.gnupg.org/WKD/UsabilityOfWKD  <- mentions Claws test

Best,
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260203/6bbf55ac/attachment.sig>

From kloecker at kde.org  Tue Feb  3 13:23:40 2026
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Tue, 03 Feb 2026 13:23:40 +0100
Subject: git.gnupg.org access does not work 404
In-Reply-To: <202602031028.04123.bernhard@intevation.de>
References: <202602031028.04123.bernhard@intevation.de>
Message-ID: <2207257.9o76ZdvQCi@daneel>

On Dienstag, 3. Februar 2026 10:27:57 Mitteleurop?ische Normalzeit Bernhard 
Reiter via Gnupg-devel wrote:
> Hi,
> https://git.gnupg.org/ gives me 404
>   Not Found
>   The requested URL was not found on this server.
> 
> Linked from https://gnupg.org/download/git.html
> where they point here for reporting.

You can thank AI scrapers for this. Werner had to take the web service down. A 
less radical solution is being worked on.

Regards,
Ingo
-------------- 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-devel/attachments/20260203/1b736bc9/attachment.sig>

From bernhard at intevation.de  Tue Feb  3 13:30:26 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 13:30:26 +0100
Subject: git.gnupg.org down until further notice
In-Reply-To: <2207257.9o76ZdvQCi@daneel>
References: <202602031028.04123.bernhard@intevation.de>
 <2207257.9o76ZdvQCi@daneel>
Message-ID: <202602031330.27163.bernhard@intevation.de>

Am Dienstag 03 Februar 2026 13:23:40 schrieb Ingo Kl?cker:
> > https://git.gnupg.org/ gives me 404

> You can thank AI scrapers for this. Werner had to take the web service
> down. A less radical solution is being worked on.

Thanks for the info!
Do you have a ticket that can be followed?
(Should be mentioned on https://gnupg.org/download/git.html)

Bernhard
ps.: Can you point me to your updated pubkey?
I haven't found it on keyserver and the version I have expired.


-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260203/3e4a55a6/attachment.sig>

From wk at gnupg.org  Tue Feb  3 17:30:13 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 03 Feb 2026 17:30:13 +0100
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <202602031057.48019.bernhard@intevation.de> (Bernhard Reiter via
 Gnupg-devel's message of "Tue, 3 Feb 2026 10:57:41 +0100")
References: <20251203113804.21c3fe3c@hermes.development.it>
 <aTBx3FDrY6YrpBjN@watt.59.ca>
 <202602031057.48019.bernhard@intevation.de>
Message-ID: <87fr7hu6wa.fsf@jacob.g10code.de>

On Tue,  3 Feb 2026 10:57, Bernhard Reiter said:

> gpg  --locate-keys --auto-key-locate clear,nodefault,wkd 

Please use

  gpg  --locate-external-keys foo at example.org

to get a fresh copy.  It does the same as above but is easier to
remember.  Since 2.2.17 (summer 2019).


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-devel/attachments/20260203/b20511d4/attachment.sig>

From gniibe at fsij.org  Thu Feb  5 04:01:45 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 05 Feb 2026 12:01:45 +0900
Subject: [PATCH 0/3] cleanup libgcrypt warnings
In-Reply-To: <aX1aEncu4TZxS03g@abf3d4a53bee>
References: <aX1aEncu4TZxS03g@abf3d4a53bee>
Message-ID: <87h5rvhp0m.fsf@haruna.fsij.org>

Hello,

Rudi Heitbaum wrote:
> Rudi Heitbaum (3):
>   tests: Cast to void to suppress warnings about unused variables
>   cipher: remove unused variable idx from _gcry_pk_get_keygrip function
>   Update to return a pointer to a const-qualified type to fix warning

Thank you for your work.

I applied the second and the third patches to libgcrypt (which are
uncontroversial, simple and no problem).  Pushed master.
-- 


From sam at gentoo.org  Thu Feb  5 07:54:15 2026
From: sam at gentoo.org (Sam James)
Date: Thu,  5 Feb 2026 06:54:15 +0000
Subject: [PATCH GnuPG] Fix -Wlto-type-mismatch warnings [T4416]
In-Reply-To: <874io5zs5l.fsf@jacob.g10code.de>
References: <874io5zs5l.fsf@jacob.g10code.de>
Message-ID: <40b28085f30f6031bd72ae24d736c9116d70f547.1770274455.git.sam@gentoo.org>

* agent/t-protect.c (convert_from_openpgp_native): Sync stub definition.

--

GnuPG-bug-id: 4416

When building with GCC -flto, some warnings appear because of
mismatched definitions in stubs (gpgv or tests). Sync them with the
real definitions to fix the warnings, as they just drifted over time.

Followup to 81760cc931d69f37cf2a8ad54616a1af590fd2cf.

Signed-off-by: Sam James <sam at gentoo.org>
---
Werner, could you pull this one on top? It's needed when building tests.

 agent/t-protect.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/agent/t-protect.c b/agent/t-protect.c
index e6edbffba..9508de36a 100644
--- a/agent/t-protect.c
+++ b/agent/t-protect.c
@@ -341,9 +341,12 @@ main (int argc, char **argv)
 
 /* Stub function.  */
 gpg_error_t
-convert_from_openpgp_native (gcry_sexp_t s_pgp, const char *passphrase,
-                             unsigned char **r_key)
+convert_from_openpgp_native (ctrl_t ctrl,
+			     gcry_sexp_t s_pgp,
+			     const char *passphrase,
+			     unsigned char **r_key)
 {
+  (void)ctrl;
   (void)s_pgp;
   (void)passphrase;
   (void)r_key;
-- 
2.53.0



From marian.kechlibar at circletech.net  Thu Feb  5 08:37:50 2026
From: marian.kechlibar at circletech.net (Marian Kechlibar)
Date: Thu, 5 Feb 2026 08:37:50 +0100
Subject: May I be accepted to GnuPG bugtracking system?
Message-ID: <ccbd96b5-fcf9-4095-889f-284c06555908@circletech.net>

Hello,

I would like to ask to be accepted into the GnuPG bugtracking system as 
a commenter.

I am reconfiguring an encryption system to use Kyber (LibrePGP PQC) keys 
and I am occassionally encountering issues that might be bugs.

At least one of the bugs is being discussed here: 
https://dev.gnupg.org/T8029 and I would love to make inputs on it if 
possible.

Even a temporary access (for, say, two weeks) would be appreciated. I am 
Marian-Kechlibar on GitHub if it helps.

Best regards and Vielen Dank

Marian K.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260205/7c7c50c4/attachment.sig>

From hskimse1 at gmail.com  Wed Feb 11 06:11:41 2026
From: hskimse1 at gmail.com (Kim Hee-Suk)
Date: Wed, 11 Feb 2026 14:11:41 +0900
Subject: [BUG] tpm2daemon: RSA 4096 decryption fails with "Provided object is
 too large" (regression from 2.4.9)
Message-ID: <aYwPjbBOGNlLSSDE@eps>

GnuPG 2.5.17's tpm2daemon fails to decrypt RSA 4096 pubkey-encrypted
packets when the encrypted data is exactly 4096 bits. Decryption
succeeds when the data happens to be 4095 bits. GnuPG 2.4.9 handles
both cases correctly.

Environment:

- GnuPG: 2.5.17 (fails) / 2.4.9 (works)
- libgcrypt: 1.11.2-r1
- tpm2-tss: 4.1.3-r2
- TPM: STMicro STM0925 (tpm_tis driver), firmware device-id 0x3
- Platform: Lenovo ThinkPad, Gentoo Linux
- Key type: RSA 4096, encryption subkey bound to TPM via tpm2daemon

Steps to reproduce:

1. Generate an RSA 4096 key with an encryption subkey stored in TPM
(managed by tpm2daemon)
2. Encrypt a file using the public key:
gpg --encrypt --recipient <KEY_ID> file.txt
3. Attempt to decrypt: gpg --decrypt file.txt.gpg

Decryption intermittently fails when the bit length of the
encrypted session key in the pubkey enc packet is 4096.

With 2.5.17:

```
$ gpgconf --kill gpg-agent tpm2daemon
$ gpg --list-packets ~/.password-store/hskim/mutt\@google.gpg
gpg: encrypted with rsa4096 key, ID 4898C1982AD755AE, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
gpg: public key decryption failed: Provided object is too large
gpg: decryption failed: Provided object is too large
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4096 bits]
# off=527 ctb=d4 tag=20 hlen=2 plen=107 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
    length: 107
$ gpg --list-packets ~/.password-store/hskim/github.com.gpg
gpg: encrypted with rsa4096 key, ID 4898C1982AD755AE, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4095 bits]
# off=527 ctb=d4 tag=20 hlen=3 plen=204 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
    length: 204
# off=549 ctb=ac tag=11 hlen=2 plen=151
:literal data packet:
    mode b (62), created 1769092097, name="ixdX8b-hskim-github.com.txt",
    raw data: 118 bytes
$ gpg --list-packets ~/.password-store/hskim/naver.com.gpg
gpg: encrypted with rsa4096 key, ID 4898C1982AD755AE, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
gpg: public key decryption failed: Provided object is too large
gpg: decryption failed: Provided object is too large
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4096 bits]
# off=527 ctb=d2 tag=18 hlen=2 plen=126 new-ctb
:encrypted data packet:
    length: 126
    mdc_method: 2
$ gpg --version
gpg (GnuPG) 2.5.17
libgcrypt 1.11.2-unknown
Copyright (C) 2025 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/hskim/.gnupg
Supported algorithms:
Pubkey: RSA, Kyber, 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
```

Same with 2.4.9:
```
$ gpgconf --kill gpg-agent tpm2daemon
$ gpg --list-packets ~/.password-store/hskim/mutt\@google.gpg
gpg: encrypted with rsa4096 key, ID 99A8DC6DA49AB13C, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4096 bits]
# off=527 ctb=d4 tag=20 hlen=2 plen=107 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
    length: 107
# off=548 ctb=ac tag=11 hlen=2 plen=54
:literal data packet:
    mode b (62), created 1758650396, name="eAgH9c-hskim-mutt at google.txt",
    raw data: 20 bytes
$ gpg --list-packets ~/.password-store/hskim/github.com.gpg
gpg: encrypted with rsa4096 key, ID 99A8DC6DA49AB13C, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4095 bits]
# off=527 ctb=d4 tag=20 hlen=3 plen=204 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
    length: 204
# off=549 ctb=ac tag=11 hlen=2 plen=151
:literal data packet:
    mode b (62), created 1769092097, name="ixdX8b-hskim-github.com.txt",
    raw data: 118 bytes
$ gpg --list-packets ~/.password-store/hskim/naver.com.gpg
gpg: encrypted with rsa4096 key, ID 99A8DC6DA49AB13C, created 2025-08-17
      "Hee-Suk Kim <hskimse1 at gmail.com>"
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 4898C1982AD755AE
    data: [4096 bits]
# off=527 ctb=d2 tag=18 hlen=2 plen=126 new-ctb
:encrypted data packet:
    length: 126
    mdc_method: 2
# off=548 ctb=ac tag=11 hlen=2 plen=83
:literal data packet:
    mode b (62), created 1755451993, name="LhBS6D-hskim-naver.com.txt",
    raw data: 51 bytes
$ gpg --version
gpg (GnuPG) 2.4.9
libgcrypt 1.11.2-unknown
Copyright (C) 2025 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/hskim/.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
```



From gniibe at fsij.org  Thu Feb 12 02:36:24 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 12 Feb 2026 10:36:24 +0900
Subject: [BUG] tpm2daemon: RSA 4096 decryption fails with "Provided
 object is too large" (regression from 2.4.9)
In-Reply-To: <aYwPjbBOGNlLSSDE@eps>
References: <aYwPjbBOGNlLSSDE@eps>
Message-ID: <873436d9pj.fsf@haruna.fsij.org>

Hello,

Thank you for your report with detailed explanation.

Kim Hee-Suk wrote:
> GnuPG 2.5.17's tpm2daemon fails to decrypt RSA 4096 pubkey-encrypted
> packets when the encrypted data is exactly 4096 bits. Decryption
> succeeds when the data happens to be 4095 bits. GnuPG 2.4.9 handles
> both cases correctly.

Indeed, this is the regression.

This is due to the fix:
	https://dev.gnupg.org/T8045

Possible fix is the following:

==========================
diff --git a/agent/divert-tpm2.c b/agent/divert-tpm2.c
index 5500c07f1..950e1f0fb 100644
--- a/agent/divert-tpm2.c
+++ b/agent/divert-tpm2.c
@@ -138,6 +138,15 @@ divert_tpm2_pkdecrypt (ctrl_t ctrl,
       if (!smatch (&s, n, "a"))
         return gpg_error (GPG_ERR_UNKNOWN_SEXP);
       n = snext (&s);
+      /* NOTE: gpg-agent protocol uses signed integer for RSA (%m in
+       * MPI), where 0x00 is added when the MSB is 1.  TPM2 uses
+       * unsigned integer.  We need to remove this 0x00, or else
+       * buffer overflow may occur.  */
+      if (!*s && (n&1))
+        {
+          s++;
+          n--;
+        }
     }
   else if (smatch (&s, n, "ecdh"))
     {

-- 


From mario.haustein at hrz.tu-chemnitz.de  Thu Feb 12 17:39:59 2026
From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein)
Date: Thu, 12 Feb 2026 17:39:59 +0100
Subject: secure channel support via PACE (was: Add support for D-Trust Card
 6.1/6.4)
In-Reply-To: <877bsxx5ei.fsf@jacob.g10code.de>
References: <1974271.CQOukoFCf9@localdomain> <2348949.iZASKD2KPV@localdomain>
 <877bsxx5ei.fsf@jacob.g10code.de>
Message-ID: <3742606.LM0AJKV5NW@localdomain>

Am Samstag, 31. Januar 2026, 14:45:09 Mitteleurop?ische Normalzeit schrieb 
Werner Koch:
> On Fri, 30 Jan 2026 16:31, Mario Haustein said:
> > PACE [1] on both interfaces. Are there plans to eventually support PACE in
> > scdaemon? It's not a problem for me if not, but maybe this kind of cards
> > will
> Support for secure channel is on the todo list for a very long time.  It
> would also be helpful for Yubikeys.  I am not sure, but isn't it the
> case that the German identity card also requires PACE?  In that case I
> should consider to an identity card in addition to my passport.

German identity cards require PACE as well. But they are a bit special. To 
access all features, the card terminal needs to authenticate against the card 
as well. As far as I understand you need a dedicated reader which contains the 
credentials in a HSM. But this is just my observation as a user. At least for 
me, it worked only with a "BSI TR-03119"-compliant smart card reader. But I am 
not an expert about german ID cards, as they are (currently) out of the scope 
of my work. Thus my statement may prove wrong.

The aforementioned readers are advantageous when implementing the secure 
channel. They are capable of handling PACE on its own. The secure channel 
terminates at the card reader and smart card communication can be handled as 
usual in software. One just need to send an APDU to the card reader at the 
beginning to establish the secure channel or alternatively to send a cached 
card access number (CAN) to the reader so the reads skips querying it from the 
card holder. The latter method should be preferred as it is very annoying to 
enter the CAN every time. There is now drawback in caching a CAN.

Kind regards
-- 
Mario Haustein
Facharbeitsgruppe Anwendungen
Universit?tsrechenzentrum

Technische Universit?t Chemnitz
Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303)
09111 Chemnitz
Germany

Tel:    +49 371 531-36606

mario.haustein at hrz.tu-chemnitz.de
www.tu-chemnitz.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260212/9417bef6/attachment-0001.bin>

From jcb62281 at gmail.com  Fri Feb 13 04:52:23 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 12 Feb 2026 21:52:23 -0600
Subject: secure channel support via PACE
In-Reply-To: <3742606.LM0AJKV5NW@localdomain>
References: <1974271.CQOukoFCf9@localdomain> <2348949.iZASKD2KPV@localdomain>
 <877bsxx5ei.fsf@jacob.g10code.de> <3742606.LM0AJKV5NW@localdomain>
Message-ID: <7f9d012b-c36b-4eca-a4ce-bbd4eed3d6b3@gmail.com>

On 2/12/26 10:39, Mario Haustein via Gnupg-devel wrote:
> [...]
>
> [...] One just need to send an APDU to the card reader at the
> beginning to establish the secure channel or alternatively to send a cached
> card access number (CAN) to the reader so the reads skips querying it from the
> card holder. The latter method should be preferred as it is very annoying to
> enter the CAN every time. There is now drawback in caching a CAN.

Assuming you meant "no drawback", are you sure about that?? What if a 
cached CAN leaks somehow?? Could malware abuse a cached CAN to perform 
operations without the user's knowledge?


-- Jacob




From hskimse1 at gmail.com  Fri Feb 13 21:54:22 2026
From: hskimse1 at gmail.com (Kim Heesuk)
Date: Sat, 14 Feb 2026 05:54:22 +0900
Subject: [BUG] tpm2daemon: RSA 4096 decryption fails with "Provided
 object is too large" (regression from 2.4.9)
In-Reply-To: <873436d9pj.fsf@haruna.fsij.org>
References: <aYwPjbBOGNlLSSDE@eps>
 <873436d9pj.fsf@haruna.fsij.org>
Message-ID: <0fed3fae-70c9-47b0-b399-d73f01daf08a@gmail.com>

Hello, thank you for the quick patch.

I tested it on my environment and can confirm it fixes the issue. Both 
4095-bit and 4096-bit cases decrypt correctly now.