From gniibe at fsij.org  Wed Jul  1 02:34:13 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 01 Jul 2026 09:34:13 +0900
Subject: [PATCH gnupg] scd: Add Nitrokey 3 to pcsc-shared interference
 detection
In-Reply-To: <f4525d75-2f88-4519-ba9c-1633965d8740@bigdan.in>
References: <84855138-a7c5-494e-8629-1c83727f9d53@bigdan.in>
 <87mrwnnqpe.fsf@haruna.fsij.org>
 <c7d1e251-e884-4a72-b755-6c1c37b6cf83@bigdan.in>
 <87y0fweje2.fsf@haruna.fsij.org>
 <f4525d75-2f88-4519-ba9c-1633965d8740@bigdan.in>
Message-ID: <874iij35ve.fsf@haruna.fsij.org>

Hello,

Artemii Bigdan <artem at bigdan.in> writes:
> Unfortunately, it did not achieve the desired bugfix. The `gpg: OpenPGP 
> card not available: Card error` is back after KeePassXC interference, as 
> before.

Thank you for testing.

> So, as of my testing, I unfortunately have to insist on the 
> `0025-scdaemon-nitrokey3-pcsc-shared.patch` as it was submitted earlier. 
> I am open to perform more tests if you can come up with a more concise 
> way to achieve the same result.
>
> I would also like to ask Robin and NIIBE Yutaka: maybe Nitrokey and 
> GnuPG could cooperate and deliver an R&D Nitrokey 3 device to one of 
> GnuPG's core maintainers for better first-class support?
>
> Thank you for your time and attention to this issue. It means a lot, 
> this bug has bothered me constantly in my daily workflow, and I really 
> do not want to manually re-patch each update. I hope we can upstream this.

I understand your situation.

I found this documentation:

    https://github.com/Nitrokey/nitrokey-3-firmware/blob/main/docs/index.md

And it seems that USB/IP simulation is available.  If it can work (I
read the ticket #261), I'll try with the simulation.
-- 


From mikhail at filippov.me  Wed Jul  1 10:09:42 2026
From: mikhail at filippov.me (Mikhail Filippov)
Date: Wed, 1 Jul 2026 12:09:42 +0400
Subject: [PATCH] w32: Modernize dialog for Windows Vista and later.
In-Reply-To: <875x302p6w.fsf@jacob.g10code.de>
References: <6b89d6f0-983b-4b5a-b0b5-9163edb72675@filippov.me>
 <875x302p6w.fsf@jacob.g10code.de>
Message-ID: <b4c0e40d-8da6-4fb8-bad9-4acadc7c58a5@filippov.me>

Hi!
> I tried to apply your patch but it is broken - Maybe due to
> Thunderbird's signing.  Can you please send it as a gzipped attachment.?
Yes, it looks like the Thunderbird issue. Sorry for the inconvenience.
I'm a newbie to the mailing lists. I attached a patch file from the git format-patch.

On 6/30/26 4:22 PM, Werner Koch wrote:
> Hi!
>
> On Sat,  6 Jun 2026 21:04, Mikhail Filippov said:
>> I updated the basic pinentry to look more native on modern operating
>> systems. I also included an SVG file for the GnuPG logo, which I
> I tried to apply your patch but it is broken - Maybe due to
> Thunderbird's signing.  Can you please send it as a gzipped attachment.?
>
>
> Salam-Shalom,
>
>     Werner
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-w32-Modernize-dialog-for-Windows-Vista-and-later.patch
Type: text/x-patch
Size: 26553 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260701/d6e5aafd/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260701/d6e5aafd/attachment-0001.sig>

From mikhail at filippov.me  Thu Jul  2 10:26:56 2026
From: mikhail at filippov.me (Mikhail Filippov)
Date: Thu, 02 Jul 2026 08:26:56 -0000
Subject: [PATCH] w32: Improve foreground window activation.
Message-ID: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me>

 From 29acf556715d0c32e28e5d6b8864f2155b3b6c05 Mon Sep 17 00:00:00 2001
From: Mikhail Filippov <mikhail at filippov.me>
Date: Thu, 2 Apr 2026 00:40:14 +0300
Subject: [PATCH] w32: Improve foreground window activation.

* w32/main.c (dlg_proc): Replace ShowWindow with a minimize/restore
sequence followed by SetForegroundWindow and BringWindowToTop.
--

This reliably brings the dialog to the foreground, similar to the
raiseWindow approach used by pinentry-qt on Windows.? Implements
the suggestion from abbecc6 to "use the hack from our Qt Pinentry"
for reliable foreground activation.

Signed-off-by: Mikhail Filippov <mikhail at filippov.me>
---
 ?w32/main.c | 8 +++++++-
 ?1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/w32/main.c b/w32/main.c
index f821fb5..8912f8b 100644
--- a/w32/main.c
+++ b/w32/main.c
@@ -359,7 +359,13 @@ dlg_proc (HWND dlg, UINT msg, WPARAM wparam, LPARAM 
lparam)

 ? ? ? ?center_window (dlg, HWND_TOP);

-? ? ? ShowWindow (dlg, SW_SHOW);
+? ? ? /* Use the minimize/restore trick to reliably bring the
+? ? ? ? ?dialog to the foreground.? Similar to the raiseWindow
+? ? ? ? ?approach used by pinentry-qt on Windows.? */
+? ? ? ShowWindow (dlg, SW_MINIMIZE);
+? ? ? ShowWindow (dlg, SW_RESTORE);
+? ? ? SetForegroundWindow (dlg);
+? ? ? BringWindowToTop (dlg);

 ? ? ? ?break;

-- 
2.54.0


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260702/97cc071e/attachment.sig>

From wk at gnupg.org  Thu Jul  2 11:22:59 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 Jul 2026 11:22:59 +0200
Subject: [PATCH] w32: Improve foreground window activation.
In-Reply-To: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me> (Mikhail
 Filippov via Gnupg-devel's message of "Thu, 28 May 2026 04:21:43
 +0400")
References: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me>
Message-ID: <87echl21ak.fsf@jacob.g10code.de>

Hi!

Thanks for the patch.  I just applied it.  However I had again problems
to to pass the patch to git and instead retyped it.  The problem are
dozens of these characters:

            character: ? (displayed as ?) (codepoint 160, #o240, #xa0)
              charset: unicode (Unicode (ISO10646))
code point in charset: 0xA0
               script: latin
               syntax:   	which means: whitespace
             category: .:Base, b:Arabic, j:Japanese, l:Latin

  name: NO-BREAK SPACE
  old-name: NON-BREAKING SPACE
  general-category: Zs (Separator, Space)
  decomposition: (noBreak 32) (noBreak ' ')

A simple replace by space did not worked.  What is TB doing?


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-devel/attachments/20260702/e357a6df/attachment.sig>

From wk at gnupg.org  Thu Jul  2 15:49:49 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 Jul 2026 15:49:49 +0200
Subject: [Announce] GnuPG 2.5.21 released
Message-ID: <8733y11oxu.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
Version 2.5.21.  This release adds a few new features and fixes some
bugs.

The main features in the 2.5 series are improvements for 64 bit Windows
and the introduction of Kyber (aka ML-KEM or 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.

Note that the old 2.4 series has reached end-of-life.  Thus expect no
more updates for 2.4.  As always with GnuPG, new versions are fully
compatible with previous versions.


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.21 (2026-07-02)
=================================================
         [compared to version 2.5.20]
         
 * New and extended features:

   - gpg, gpgsm: Use partial file on decryption, remove on failure.
     Disable with "--compatibility-flags=no-partial-file-guard".
     [T7873]

   - gpg: Use the INT_RCP_FPR subpacket in revocation signatures.
     [T8252]

   - Create a pkgversioninfo.txt file when building using the speedo
     build system.

 * Bug fixes:

   - gpg: Fix potential use-after-free in batch key generation when
     handling the keyserver URL option.  [T8277]

   - gpgsm: Fix regression in gpgsm_verify with expired certificates.
     [T8188]

   - gpgsm: Require a minimum tag length for GCM decryption.
     [rG4c7e68cf3d, CVE-2026-34182]

   - scd: Limit the size of returned APDU objects from faulty cards.
     [T8281]

   - scd: Fix condition to retrieve ATR.  [rGca25a7a61b]

   - scd:openpgp: Fix regression in CHV1 retry counter byte index.
     [rG245330ebea]

   - agent: Make batch import of Kyber keys work.  [T8029]

   - dirmngr: Add a validation check in get_dns_cert_standard.
     [T8303]

   - gpgconf: Raise an error on certain parse errors.  [T8261]

   - Fix use of usleep in file remove function on Windows.  Regression
     since 2.5.13.  [rGab9ce5f5e7]

 Release-info: https://dev.gnupg.org/T8262


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> 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
<https://gnupg.org/download/mirrors.html>.  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.21.tar.bz2 (8156k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.21.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.21_20260702.exe (5636k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.21_20260702.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.21_20260702.tar.xz (15M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.21_20260702.tar.xz.sig

This source tarball may also be used to download all required libraries
at once to build a Unix version on any modern system.  See the included
README.


Debian Packages
===============

We also provide Debian style packages for a couple of Debian variants.
See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch
to other distros/releases.  If you encounter packaging problems please
report them to the gnupg-devel mailing list.  It may however take a few
days until they are available.


Windows Installer
=================

A new version of Gpg4win is in planning.  For those who are affected by
one of the now fixed bugs, it is possible to install the simple Windows
installer mentioned above on top of Gpg4win 5.0.2.


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.21.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.21.tar.bz2.sig gnupg-2.5.21.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.21.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.21.tar.bz2

   and check that the output matches the next line:

51fae4f4d902787624eb7047f6d3e7c263ad7690  gnupg-2.5.21.tar.bz2
2e6712f413e47bb23fb4ba5b07f9b0a6aaa266e7  gnupg-w32-2.5.21_20260702.tar.xz
65e7528baf8ec1bf83d3df56e6e9e377620f2de6  gnupg-w32-2.5.21_20260702.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, Georgian, 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.

If you are using cleartext signatures in your application please read
https://gnupg.org/blog/20251226-cleartext-signatures.html and maybe
https://gnupg.com/20260122-39C3_reply_gpg_fail.html

In case of build problems specific to this release please first check
https://dev.gnupg.org/T8262 for updated information.  We are sorry that
due to ongoing DoS on this service, you may end up at a "is under
maintenance page".  Static copies of the ticket pages are provided in
any case.

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.

* 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.

* List of Release Signing Keys:
  To guarantee that a downloaded 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 five 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)

    brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23]
    1493 269D E61F 124A A69A  316E 3ADF 34EB DBB2 00A4
    GnuPG.com (Release Signing Key 2026)

  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.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260702/6e3f5341/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From jcb62281 at gmail.com  Fri Jul  3 03:33:06 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 2 Jul 2026 20:33:06 -0500
Subject: [PATCH] w32: Improve foreground window activation.
In-Reply-To: <87echl21ak.fsf@jacob.g10code.de>
References: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me>
 <87echl21ak.fsf@jacob.g10code.de>
Message-ID: <c49cf844-cb34-4737-a423-3b51da7c4838@gmail.com>

On 7/2/26 04:22, Werner Koch via Gnupg-devel wrote:
> Hi!
>
> Thanks for the patch.  I just applied it.  However I had again problems
> to to pass the patch to git and instead retyped it.  The problem are
> dozens of these characters:
>
>              character: ? (displayed as ?) (codepoint 160, #o240, #xa0)
>                charset: unicode (Unicode (ISO10646))
> code point in charset: 0xA0
>                 script: latin
>                 syntax:   	which means: whitespace
>               category: .:Base, b:Arabic, j:Japanese, l:Latin
>
>    name: NO-BREAK SPACE
>    old-name: NON-BREAKING SPACE
>    general-category: Zs (Separator, Space)
>    decomposition: (noBreak 32) (noBreak ' ')
>
> A simple replace by space did not worked.  What is TB doing?

I am not entirely certain, but I have seen this behavior. Thunderbird 
appears to convert runs of multiple spaces to some combination of spaces 
and non-breaking spaces.? For example, I space twice between sentences 
and expect that those will go out as either 0x20 0xA0 or 0xA0 0x20.? (I 
forget which order it uses.)

I *think* that Thunderbird behaves differently if the text is
in a "Preformat" block.  This is an example.  I typed it in
"Preformat" style and broke the lines manually.

When pasting patches or other pre-formatted text into Thunderbird, I 
have developed the habit of (1) starting a new paragraph, (2) changing 
the style for that paragraph to "Preformat", (3) typing the "8<------" 
lines, then (4) pasting the text between the scissor lines.


-- Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260702/5d9b6990/attachment.html>

From wk at gnupg.org  Fri Jul  3 11:04:14 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Jul 2026 11:04:14 +0200
Subject: Thunderbird and patches oddity (was: [PATCH] w32: Improve
 foreground window activation.)
In-Reply-To: <c49cf844-cb34-4737-a423-3b51da7c4838@gmail.com> (Jacob Bachmeyer
 via Gnupg-devel's message of "Thu, 2 Jul 2026 20:33:06 -0500")
References: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me>
 <87echl21ak.fsf@jacob.g10code.de>
 <c49cf844-cb34-4737-a423-3b51da7c4838@gmail.com>
Message-ID: <87se60zbox.fsf_-_@jacob.g10code.de>

On Thu,  2 Jul 2026 20:33, Jacob Bachmeyer said:

> I *think* that Thunderbird behaves differently if the text is
> in a "Preformat" block.  This is an example.  I typed it in
> "Preformat" style and broke the lines manually.

I am not sure what a preformat block is in Thunderbird but assume that
is related to HTML to Text conversion.  The patch mail had no HTML part
but it was

Content-Type: text/plain; charset=UTF-8; format=flowed

Your mail was also flawed^Wflowed.  But indeed the above quote paragraph
was oka but your first paragraph had 0xC2, 0xA0, 0x20 sequences after
the end of sentence fullstop.  And my quoted text was another part as
text/html.

> When pasting patches or other pre-formatted text into Thunderbird, I
> have developed the habit of (1) starting a new paragraph, (2) changing
> the style for that paragraph to "Preformat", (3) typing the "8<------"
> lines, then (4) pasting the text between the scissor lines.

Good advise.  But TB should stop this weird behaviour in particular if
it is configured to send text/plain.  


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-devel/attachments/20260703/815b66f2/attachment.sig>

From tmz at pobox.com  Fri Jul  3 16:13:41 2026
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 3 Jul 2026 10:13:41 -0400
Subject: Thunderbird and patches oddity (was: [PATCH] w32: Improve
 foreground window activation.)
In-Reply-To: <87se60zbox.fsf_-_@jacob.g10code.de>
References: <0ee27782-6e45-487b-af8d-31ebe70ceb18@filippov.me>
 <87echl21ak.fsf@jacob.g10code.de>
 <c49cf844-cb34-4737-a423-3b51da7c4838@gmail.com>
 <87se60zbox.fsf_-_@jacob.g10code.de>
Message-ID: <20260703141330.8eoVuQB8@teonanacatl.net>

Werner Koch via Gnupg-devel wrote:
> On Thu,  2 Jul 2026 20:33, Jacob Bachmeyer said:
> 
>> I *think* that Thunderbird behaves differently if the text is
>> in a "Preformat" block.  This is an example.  I typed it in
>> "Preformat" style and broke the lines manually.
> 
> I am not sure what a preformat block is in Thunderbird but assume that
> is related to HTML to Text conversion.  The patch mail had no HTML part
> but it was
> 
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Your mail was also flawed^Wflowed.  But indeed the above quote paragraph
> was oka but your first paragraph had 0xC2, 0xA0, 0x20 sequences after
> the end of sentence fullstop.  And my quoted text was another part as
> text/html.
> 
>> When pasting patches or other pre-formatted text into Thunderbird, I
>> have developed the habit of (1) starting a new paragraph, (2) changing
>> the style for that paragraph to "Preformat", (3) typing the "8<------"
>> lines, then (4) pasting the text between the scissor lines.
> 
> Good advise.  But TB should stop this weird behaviour in particular if
> it is configured to send text/plain.  

Perhaps the suggestions from the Git and Linux kernel
projects would be useful?

https://git-scm.com/docs/git-format-patch#_thunderbird
https://www.kernel.org/doc/html/latest/process/email-clients.html#thunderbird-gui

They include largely similar advice.  Alternately, the git
send-email? command can be very helpful in removing the need
to fight with a mail client.  There is also the b4? tool
which is used by the kernel folks and has recently been
proposed as the recommended method for the Git project as
well.

? https://git-scm.com/docs/git-send-email
? https://b4.docs.kernel.org/

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260703/1c544990/attachment.sig>

From diggsey at googlemail.com  Tue Jul  7 19:03:19 2026
From: diggsey at googlemail.com (Diggory Blake)
Date: Tue, 7 Jul 2026 18:03:19 +0100
Subject: Occasional invalid RSA signature under repeated signing (gpg 2.3.7 /
 libgcrypt 1.10.1)
Message-ID: <CAAnrWj_XDheORodZhju-mk1FQSsf4pMJ9ac35Hz4R3p_LNH6Pw@mail.gmail.com>

Hi all ? I hit an odd signing failure and did enough digging that I
thought it was worth writing up in case it's useful. Happy to be told
this is already known, or that I'm barking up the wrong tree.

## What happened

I signed a git commit with `git commit --amend --no-edit` (which calls
`gpg -bsau <KEY>` under the hood), and later noticed `git verify-commit`
reports it as `BAD signature`. The key is the right one, and every
other commit I've signed around that time verifies fine ? only this one
is broken.

When I dug into it, `gpg --debug 4 --verify` shows the signature is
well-formed but `s^e mod n` doesn't match the PKCS#1 v1.5-padded
expected value. Re-signing the same bytes with the same gpg immediately
after produces a good signature, so it was a one-off. If it were just
that I'd have shrugged and moved on, but the shape of `cmp` turned out
to be pretty specific.

## Environment

- Windows 10 Pro 22H2
- gpg (GnuPG) 2.3.7 (the standalone installer from gnupg.org, not the
  one bundled with Git for Windows)
- libgcrypt 1.10.1
- RSA-4096 key, SHA-256 signatures
- No custom `gpg-agent.conf`, defaults throughout

## The signature that failed

Comparing what gpg computed the expected padded value should be against
what it got from `s^e mod n`:

```
data:  01ff?ff003031300d0609608648016503040201050004200c8d58d745?ad3409
 (expected)
cmp :  a0ed2c0ca3a3401628b3eb3436885a1992b551c589176ef0adddfccea17aef24
       ad6e76df617bf9e4e5a6ecf455feb0cb939030402b9e986e37b2243431070c7e
       f86a1b3e1ee98da51d8250bd215274d98ec3ec329930b65880c2b4c3f7db8559
       ? (matches n bytewise for ~480 bytes with byte 1 offset by ?2) ?
       <32-byte tail varies per failure>
```

The public modulus starts:

```
n:     a0ef2c0ca3a3401628b3eb3436885a1992b551c589176ef0adddfccea17aef24
       ad6e76df617bf9e4e5a6ecf455feb0cb939030402b9e986e37b2243431070c7e
       ?
```

Byte 1 of `cmp` is `0xed`, byte 1 of `n` is `0xef`, so `cmp` looks like
`n ? 2^4081` in the high half. Middle 460+ bytes match `n` exactly.
Only the last 32 bytes differ from a straight copy of `n`.

I checked (with an independent BigInt reimplementation) that this is
the actual `s^e mod n`, not just something libgcrypt's debug printer
was showing me ? same result.

## Reproducer

I wondered how rare this actually was, so I wrote a small stress
harness ? a Node script that loops `gpg -bsau <KEY>` on a fixed 1305-byte
payload and verifies each signature. Rough hit rates:

- Sequential (1 sign at a time): **1 BADSIG in 500**
- 5-way concurrent: **1 BADSIG in ~100?200**

So concurrency isn't necessary ? it just makes it faster to reproduce.

I collected two more BADSIGs this way. Both have the same shape as the
original: the first 480 bytes of `s^e mod n` are byte-for-byte identical
to the original failure (`a0ed2c0ca3a3401628b3eb?`), and only the
trailing 32 bytes vary. Three independent failures agreeing to that
extent doesn't look like random memory noise; it looks like a specific
intermediate value is leaking through.

## Fault-attack safety

Before sharing failing signatures I checked they don't enable a
Bellcore-style CRT fault attack. For each failure:

```
gcd(|s^e mod n ? PKCS1_pad(hash)|, n) = 1
```

so the corruption affects both CRT branches (mod p *and* mod q)
coherently, not one branch only. The private key isn't recoverable
from these signatures.

That's also an interesting data point about the mechanism, I think ?
it's not a fault in one exponentiation but something that survives
CRT recombination.

## Things I ruled out

- **Race condition** ? sequential reproduces at 1/500
- **git ? object corruption** ? base64 CRC-24 verifies over the sig
  packet; git writes exactly what gpg returned
- **Wrong payload / encoding** ? the LEFT16 field in the sig packet
  matches the SHA-256 prefix of the exact bytes git presents to gpg,
  and I brute-forced ~thousands of nearby payload variants (CRLF, BOM,
  encoding header, timestamp sweeps, every tree hash in the repo) ?
  none verify
- **Wrong key** ? issuer fingerprint is correct
- **Transient bad state** ? re-signing the same bytes moments later
  succeeds

## Where I got to on the mechanism

I read some of `libgcrypt-1.10.1/mpi/mpi-pow.c`, `mpi/mpiutil.c`, and
`cipher/rsa.c`, but I didn't manage to pin down the specific line.
The candidates I noticed (may be wrong):

- `_gcry_mpi_powm`'s W==1 branch skips the `MPN_ZERO(rp, rsize)` the
  W>1 branch does (though I'm not sure W==1 is even reached for
  RSA-4096 sign)
- `_gcry_mpi_alloc_limb_space` doesn't zero the buffer except in the
  `nlimbs==0` case
- `secret_core_crt`'s output MPI might reuse limbs from a previous
  operation whose contents happened to be shaped like `n`

The fact that `s^e mod n` is *deterministic* across failures except for
32 bytes at the tail suggests something in the blinding intermediate
path, since the blinding factor `r` is the only fresh input per sign.
libgcrypt 1.11 rewrote the modexp as `_gcry_mpih_powm_lli` which might
already have addressed this class of bug ? I haven't tested that yet.

## Attachments

Files in this gist:
https://gist.github.com/Diggsey/ac9232486c7347f60dc77970521ec0bd

- `bad.payload.bin` ? the exact 1305-byte payload
- `bad_original.asc`, `bad_concurrent.asc`, `bad_sequential.asc` ? three
  failing signatures (one from the original git commit, two from the
  stress reproducer)
- `stress.js` ? the reproducer (~90 lines of Node)
- `decode-sigs.js` ? the independent BigInt verifier that also does the
  Bellcore-safety `gcd` check

Thanks for taking a look, and apologies if this turns out to already
be fixed in a version I haven't tested.