Kleopatra (gnupg, gpgsm) hang on key-creation when x.509 certs are in keystore
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	vitusb
	Feb 26 2025, 12:36 PM

Description

Hello,

when i have the x.509 pub-cert from "GRP Poststelle" and its cert dependency-tree imported in my keystore, then "Kleopatra" (respective gnupg with gpgsm) will hang on key creation.

"gpgsm" could not be killed by: "gpgconf --kill gpgsm". When gpgsm was killed by "procexp" (sysinternals), the key-creation will be finished:

Here are the certs for testing:

GRP_Poststelle_public.zip6 KBDownload

This error was reproducible on two computer systems (Windows 10 and Windows 11). If the certificates were removed from the keystore, key creation was possible. No smartcards were used ...

Maybe T7434 or T7396 are affected ?

I used a private build of "gpg4win" v3.3.0 with "gnupg" v2.2.46 ...

Here is the same situation on commandline from GnuPG (used a test-key):

C:\Users\xxxxxxxxxx>gpg --version
gpg (GnuPG) 2.2.46
libgcrypt 1.8.11

C:\Users\xxxxxxxxxx>gpg --debug=all --full-generate-key
gpg: Optionen werden aus 'C:/ProgramData/GNU/etc/gnupg/gpg.conf' gelesen
gpg: Optionen werden aus '[cmdline]' gelesen
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) RSA und RSA (voreingestellt)
   (4) RSA (nur signieren/beglaubigen)
   (14) Vorhandener Schlüssel auf der Karte
Ihre Auswahl? 1
RSA-Schlüssel können zwischen 2048 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (3072) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 0
Schlüssel verfällt nie
Ist dies richtig? (j/N) j

GnuPG erstellt eine User-ID, um Ihren Schlüssel identifizierbar zu machen.

Ihr Name ("Vorname Nachname"): Archive_20250225
Email-Adresse:
Kommentar: Key for long-time archive ...
Sie haben diese User-ID gewählt:
    "Archive_20250225 (Key for long-time archive ...)"

Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? f
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_0x00000298 <- OK Pleased to meet you, process 17044
gpg: DBG: connection to agent established
gpg: DBG: chan_0x00000298 -> RESET
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> GETINFO version
gpg: DBG: chan_0x00000298 <- D 2.2.46
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> OPTION allow-pinentry-notify
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> GETINFO jent_active
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> RESET
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> GENKEY --timestamp=20250225T152215
gpg: DBG: chan_0x00000298 <- S INQUIRE_MAXLEN 1024
gpg: DBG: chan_0x00000298 <- INQUIRE KEYPARAM
gpg: DBG: chan_0x00000298 -> D (genkey(rsa(nbits 4:4096)))
gpg: DBG: chan_0x00000298 -> END
gpg: DBG: chan_0x00000298 <- INQUIRE PINENTRY_LAUNCHED 2104 qt5 1.3.1 - - - - 0/0 -
gpg: pinentry launched (2104 qt5 1.3.1 - - - - 0/0 -)
gpg: DBG: chan_0x00000298 -> END
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen X 100 100
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen X 100 100
gpg: DBG: chan_0x00000298 <- S CACHE_NONCE 1A3E7B4440BFA91AE231F6C9
gpg: DBG: chan_00000298 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(566 byte(s) skipped) ]
gpg: DBG: chan_0x00000298 <- OK
gpg: Die Eigenbeglaubigung wird geschrieben
gpg: DBG: get_keygrip for public key
gpg: DBG: keygrip= 9F 1A 35 7D 1C BA 76 85 C6 B1 AB EE 47 CF 06 5A 2E 1F A5 EA
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '258A14BC0BE4EE9F'
gpg: DBG: keydb: kid_not_found_p (258a14bc0be4ee9f) => indeterminate
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: DBG: keydb: kid_not_found_insert (258a14bc0be4ee9f)
gpg: DBG: [not enabled in the source] keydb_search leave (not found)
gpg: DBG: chan_0x00000298 -> RESET
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SIGKEY 9F1A357D1CBA7685C6B1ABEE47CF065A2E1FA5EA
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SETKEYDESC Sie+benötigen+ein+Passwort,+um+den+geheimen+OpenPGP+Schlüssel+zu+entsperren:%0A%22[User-ID+nicht+gefunden]%22%0A4096-Bit+RSA+Schlüssel,+ID+258A14BC0BE4EE9F,%0Aerzeugt+2025-02-25.%0A
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SETHASH 10 ############################################################################
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> PKSIGN -- 1A3E7B4440BFA91AE231F6C9
gpg: DBG: chan_00000298 <- [ 44 20 28 37 3a 73 69 67 2d 76 61 6c 28 33 3a 72 ...(537 byte(s) skipped) ]
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '258A14BC0BE4EE9F'
gpg: DBG: keydb: kid_not_found_p (258a14bc0be4ee9f) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: RSA/SHA512 Signatur von: "258A14BC0BE4EE9F [?]"
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
gpg: DBG: chan_0x00000298 -> RESET
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> GENKEY --timestamp=20250225T152215 1A3E7B4440BFA91AE231F6C9
gpg: DBG: chan_0x00000298 <- S INQUIRE_MAXLEN 1024
gpg: DBG: chan_0x00000298 <- INQUIRE KEYPARAM
gpg: DBG: chan_0x00000298 -> D (genkey(rsa(nbits 4:4096)))
gpg: DBG: chan_0x00000298 -> END
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen X 100 100
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen . 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen + 0 0
gpg: DBG: chan_0x00000298 <- S PROGRESS primegen X 100 100
gpg: DBG: chan_0x00000298 <- S CACHE_NONCE 1A3E7B4440BFA91AE231F6C9
gpg: DBG: chan_00000298 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(560 byte(s) skipped) ]
gpg: DBG: chan_0x00000298 <- OK
gpg: Schreiben der "key-binding" Signatur
gpg: DBG: cache_public_key: already in cache
gpg: DBG: get_keygrip for public key
gpg: DBG: keygrip= 9F 1A 35 7D 1C BA 76 85 C6 B1 AB EE 47 CF 06 5A 2E 1F A5 EA
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '258A14BC0BE4EE9F'
gpg: DBG: keydb: kid_not_found_p (258a14bc0be4ee9f) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: chan_0x00000298 -> RESET
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SIGKEY ########################################
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SETKEYDESC Sie+benötigen+ein+Passwort,+um+den+geheimen+OpenPGP+Schlüssel+zu+entsperren:%0A%22[User-ID+nicht+gefunden]%22%0A4096-Bit+RSA+Schlüssel,+ID+258A14BC0BE4EE9F,%0Aerzeugt+2025-02-25.%0A
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> SETHASH 10 ################################################################################################################################
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: chan_0x00000298 -> PKSIGN -- ########################
gpg: DBG: chan_00000298 <- [ 44 20 28 37 3a 73 69 67 2d 76 61 6c 28 33 3a 72 ...(543 byte(s) skipped) ]
gpg: DBG: chan_0x00000298 <- OK
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '258A14BC0BE4EE9F'
gpg: DBG: keydb: kid_not_found_p (258a14bc0be4ee9f) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: RSA/SHA512 Signatur von: "258A14BC0BE4EE9F [?]"
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search_reset
gpg: DBG: keydb_search: reset  (hd=0x0088cfe0)
gpg: schreiben des öffentlichen Schlüssels nach 'C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx'
gpg: DBG: keydb: kid_not_found_flush
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
gpg: waiting for lock C:/Users/xxxxxxxxxx/AppData/Roaming/GnuPG/pubring.kbx.lock...
^C

Best regards,
vitusb

Details

Version: Kleopatra 3.3.0 / GnuPG 2.2.46

Related Objects

Mentioned Here: rG25d48663f9ed: dirmngr: Use the same thread init strategy as gpg-agent et al.

Event Timeline

vitusb created this task.Feb 26 2025, 12:36 PM

The certificate can also be downloaded from https://www.bsi.bund.de/DE/Service-Navi/Kontakt/smime.html

I remove the milestone tag, as that one means "fixed in version 2.2.46" and added the general gnupg tag

rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.

The background is that due to the switch to Libassuan 3.0 we use a different way to init our userland thread library (npth) and it seems that the dirmngr reading loop blocked.

Please test using the latest gpg4win installer (beta145).

Hello Werner,
thank you for your support ...

In T7544#199002, @werner wrote:

Please test using the latest gpg4win installer (beta145).

Your patch is tagged wih "gnupg-2.5.5" ... as you can see, the error comes from GnuPG 2.2.46 that is used by Gpg4Win 3.3.0.

Is GnuPG 2.5.5 de-vs capable ?

In the past, only GnuPG 2.2.xx was de-vs capable (2.4 blocked the de-vs mode in previuos versions).
Will be there a new version after 2.2 or a branch, that will be de-vs capable ?

Where do i find "beta145" ... ?? Patch ? Branch ? On git.gnupg.org or on dev.gnupg.org ?

Best regards ...

The beta145 Werner talks about can be found here: https://www.gpg4win.org/version5.html
It is from our master branch which is not de-vs capable at this time.

After your report I tried to replicate this with the last Beta (125, was internal only) build from the master branch.
There I saw Kleopatra freeze after importing the problematic certificate you supplied when I tried to view its certificate details. I do not have this issue any more with Beta-145.
I did not have issues with Beta-125 with OpenPGP key creation before the freeze caused by the key refresh.

When trying to replicate the issue with GnuPG VSD 3.3.0 (wich includes gpg 2.2.46) and the current Gpg4win version 4.4.0,
I did not encounter any issues at all. Therefore I suspect you might have a combination of components in your build which is not compatible. Maybe wrong npth or libassuan?

Hello Eva,

The beta145 Werner talks about can be found here: https://www.gpg4win.org/version5.html
It is from our master branch which is not de-vs capable at this time.

... oh !! ... my fault i didn't looked at the beta-directory ;-(

After your report I tried to replicate this with the last Beta (125, was internal only) build from the master branch. There I saw Kleopatra freeze after importing the problematic certificate you supplied when I tried to view its certificate details. I do not have this issue any more with Beta-145.

I never had issues after importing these certificates but on the first start of Kleopatra i often had some hangs of Kleo if these certificates have been processed ...

I'm using a "trustlist.txt" with the directories "trusted-certs" (containing Mozilla's ROOT-CERT STORE and "extra-certs" (containing some other certs) like relevant "x500.bund.de"-certs. Allmost all of these "x500.bund.de"-certs from "extra-certs"-folder are providing an LDAP-URL call as the first request in their cerfificate-revocation-list distribution-point (attribute in certificate). LDAP has some drawbacks (not proxy-capable, etc.) so I think there could be a problematic timing-issue with CRL-checks by ldap, with all these bund.de-certificates ... Because of using timers on crl-checks, the issue seems to be difficult to reproduce after completion.

When trying to replicate the issue with GnuPG VSD 3.3.0 (wich includes gpg 2.2.46) and the current Gpg4win version 4.4.0,
I did not encounter any issues at all.

There could be an issue with crl-check timing and caching and the design of the URLs (ldap-request as first CRL-check in list of some certificates) ...

Therefore I suspect you might have a combination of components in your build which is not compatible. Maybe wrong npth or libassuan?

That is impossible, because i'm not using a private-build of GnuPG ... I'm using a private build of Gpg4Win with an official signed GnuPG 2.2.46-binary backend ...

I came to the CRL-issue because i moved all x500.de-certs from "extra-certs"-folder to "trusted-certs"-folder, killed all backend processes and launched Kleo again ... i could not reproduce the issue again ...

Then i moved all certs back ... killed all processes ... restarted Kleo:

With the same version of Kleo and GnuPG, i could not reproduce the issue again ...
Key-creation when x.500-cert-chain is in key-store works now ... strange ...

I don't know how much we need to pay attention to the priority of the provided URLs in the CRL checks (RFC), but maybe we're allowed to prioritize the http-url over the ldap-url, when this is the issue ?