To reproduce the hang, a loop will suffice (usually happens within the first 15 times, once it needed 50 runs):

There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):

Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.

setting to High as we need this for T7790

The "ca" root cert is not on the ldap, if that matters

In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

It works well for us. Thanks again.

@werner: gpg fails to batch import secret Kyber keys:

$ GNUPGHOME=/home/ingo/dev/g10/.gnupghomes/empty gpg --batch --import --verbose ~/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc 
gpg: WARNING: unsafe permissions on homedir '/home/ingo/dev/g10/.gnupghomes/empty'
gpg: enabled compatibility flags:
gpg: sec  brainpoolP256r1/DD89C34EF2B69576 2024-11-14  Kyber768 <kyber768@example.net>
gpg: using pgp trust model
gpg: key DD89C34EF2B69576: public key "Kyber768 <kyber768@example.net>" imported
gpg: key DD89C34EF2B69576/DD89C34EF2B69576: secret key imported
gpg: key DD89C34EF2B69576/D07DD3BF9F1AAF4F: error sending to agent: IPC parameter error
gpg: error reading '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc': IPC parameter error
gpg: import from '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc' failed: IPC parameter error
gpg: Total number processed: 0
gpg:               imported: 1
gpg:       secret keys read: 1

Thanks Ingo. It seems 2.5.17 is not too far away.

I can reproduce this on the command line:

C:\Users\g10code>"c:\Program Files\GnuPG\bin\gpgsm.exe" --export --armor 579BAF3DF16AD462457BCC0897ADBC143D76EA7B 5A2B80F98F518D50891B1F0C7C6131AD107F9938 DB625D2BBBB5A3FD985C0233249B03090E85D402
Issuer ...: /CN=CA IVBB Deutsche Telekom AG 20/OU=Bund/O=PKI-1-Verwaltung/C=DE
Serial ...: 02195D190EBE34
Subject ..: /CN=iOS Test-Smartcard iostest01.sc/OU=BSI/O=Bund/C=DE/SerialNumber=2
    aka ..: iostest01.sc@bsi.bund.de
Keygrip ..: 527CE32FD0552D18479442EF90DD5E434C036329

I can reproduce the issue only (!!!) with keyboxd (on Windows).

So w/o the new option we have:

The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:

testing will wait for special build

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

I am using that version and key daily. No problems seen.

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

was tested already by timegrid

This does not happen any more, tested with Gpg4win-5.0.0-beta479

Tested with Gpg4win-5.0.0-beta479

in Gpg4win-5.0.0-beta479

with Gpg4win-5.0.0-beta479 the listing after creating the new key with ADSK looks ok now:

I think we won't fix that for 2.2

It looks similar if the key is in a WKD: First search fails without error, only "no certificates found" is shown. Clicking "Search" again results then in the expected key being found and shown.

Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .

Interestingly, gpg also prints the warning about the missing trusted key signature when verifying a signature made with a revoked key that has a valid certification by a trusted key. This could be intentional (because the revocation invalidates all certifications), but it's still a bit surprising.

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf.

Regarding my comment T1825#191055 : The mane page has long been updated and gpgme support is also available. For the symmetric session key, see the feature request T8016

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

• gpg --show-only-session-key --decrypt FILE shows only the session key
• gpg --add-recipients -r UID1 FILE adds recipients (tested with one or more uids)
• gpg --change-recipients -r UID FILE changes the recipients (tested with one or more uids)

Looks good to me on gpg4win-5.0.0-beta479 @ win11.
I can't reproduce ebo's nor pl13's issue.

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf. Note that the gpgconf option feature handles only a subset of all options on purpose.

The problem was the keyserver configuration, which does not include a scheme (ldap:):

keyserver ldap.gnupg.test:389:uid=LordPrivySeal,ou=GnuPG Users,dc=gnupg,dc=test:pass:dc=gnupg,dc=test:

This has likely a similar cause as T1794

I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:

• Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)

Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:

Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).

This is really weird behavior. It seems other secret keys in the keyring may also change to "undefined" validity when the certification is done with another key. And something about the key which is certified is important.
But it can also happen that it is enough to just import a secret key without certifying anything with it for it to be shown as "undefined" validity.

This relates to T7917: Check for revocation of the ADSK's original subkey

The expected behavior is that only "Ted" (the key from where the ADSK originates) is listed, regardless of ADSKs, on every listing.
Because for regular keys there can only ever be one, "gpg -k" shows always only one key.
Subkeys which are ADSKs shall therefore never be listed with this command.

Tested with Gpg4win-5.0.0-beta446, identically to the procedure from the description: