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:

setting this to resolved, werner already tested this

I also don't think, that a backport to 2.2 is neccessary.
As gnupg26 was tested in gpg4win5 beta413 as well, I also move this to done on the gnup26 workboard and mark this issue as resolved.

If we need to backport the locking fixes to 2.2, these two will be the start of changes:

I would say this is done.

This seems not to work in Kleopatra/gpg in gpg4win-5.0.0-beta413 @ win11.

Tested on gpg4win-5.0.0-beta413 @ win11 with the following entries in dirmngr.conf:

Yubikeys allow that. See my mail to the mailing list.

The extension .part is used by Mozilla/Firefox. Curl uses .tmp. Is that OK for Windows machine to use .part?

Seems like the OpenPGP Card Specification does not allow the change of retry counters.

That is a feature not a bug. Make also sense if your threat model is store-trafic-no-decrypt-later. If you can get the key you will also be abale to get the cleartext. Any nobody can remember a passphrase on par with the claimed Kyber security level.

Yes, sorry, a typo, I corrected it.

In T7759#208677, @timegrid wrote:

Forgot to note: Setting S/MIME debug level in kleopatra via GnuPG System will write the right key to gpg.conf (if I understood it right, this was also a problem)

As this looks good to me on gpg4win-5.0.0-beta413 @ win11, I move this to done on the gpd5x board.

Forgot to note: Setting S/MIME debug level in kleopatra via GnuPG System will write the right key to gpgsm.conf (if I understood it right, this was also a problem)

I think last time I didn't test the actual problem.

When --output option is used and the user uses temporary file and is ready for checking an error, that is, it's already prepared, it's redundant and useless, indeed.

With the next gpg release (2.5.14) the keyboxd has an extended fingerprint table which carries a flags column. A bit in this column can eventually be used to mark subkeys with the "R" key flag and the search funtion can be enhanced to ignore keys with that flag set. This way we can more easily lookup the actual ADSK key (with the "E" key flag) and check whether this subkey has been revoked.

@ikloecker says that Kleo already support this feature. (I didn't know that.)
So, compatibility flag to switch on/off the feature would be needed,
or this feature is not needed in GnuPG at all.

Here is my attempt to do that:

Fix applied. Thanks.

This is not a composite key specific thing despite that this is an extra challenge. The creation date is used to reconstruct a key if the public key has been lost and only the fingerprint is still available. A solution might be to test the all combinations of stored creation dates to match the fingerprint.

Werner is going to add the missing implementation so that the error will soon be gone.

Here is my idea to implement the feature:
(1) Extend struct iobuf_struct to have a field of temporary output (of int), just after real_fname.

• OUTPUTFILE: When it's 1, it means that a temporary output file generated with real_fname original suffix removed and appended .tmp

(2) Modify get_output_file in plaintext.c and make_outfile_name in openfile.c, so that OUTPUTFILE semantics above is used and the field in iobuf_struct is marked accordingly.
(3) Modify proc_encrypted in mainproc.c so that it can rename .tmp file to the OUTPUTFILE or it can remove it when failure, when the field is active.

Let me explain the background.

@gniibe Thanks for the detailed reply. Looks like we were lucky to hit v2.5.12 when building our CI containers few weeks ago, rebuilding those now with 2.5.13 fixed the problem. Thanks again!

@onickolay The change was originally introduced for PQC stuff. And then, we applied use of KEM API (of libgcrypt) also for ordinary ECDH, so, it affected ordinary ECDH encryption (between 2.5.9 and 2.5.12).
The intention is follow the recommendation of use of KEM. IIUC, next FIPS certification will require use of KEM, possibly.

@gniibe @werner Is this change is supposed to work only for PQC stuff, or non-PQC as well, and where it is defined? As it breaks RNP tests for ordinary ECDH encryption (as it looks up for 0x40 prefix). It's not a problematic to update our code, but just want to know the reason for that.

Note that currently Kleopatra (gpg4win 5 beta) fails to delete the key, which might impact other operations. I'm currently trying to figure out, if some other bugs/quirks are a subsequent error or not.

Workaround is to use --with-keygrip and delete both <keygrip>.key files. Problem here is that one part may be on a smartcard or one part might be shared (although not allowed) with other keys.

I'd sad we keep it as it is now (unless we see a regression). The real and only correct solution is the use of a daemon to serialize access.

Still, there is a fundamental problem with keydb locking.

• It only assures no-data-corruption.
• When a process doing write access, another process reading the resource may encounter a problem (inconsistent data read), since data could be changed while accessing.
  • Currently, write access may occur with keybox compress, this means that users are not safe to invoke multiple gpg/gpgsm simultaneously (to be sure).
    • It would be: only keybox compress when users explicitly ask.
  • We could introduce a lock to read access... BUT naively adding a lock (both for read and write or read-multiple-write-one) results possible deadlock in gpgsm
    • in gpgsm, gpgsm_walk_cert_chain and gpgsm_validate_chain access the resource of keydb in a way of:
      • While it has a handle kh, by find_up routine, it may call keydb_store_cert by callback routine; The callback does write access to the resource opening another handle.
      • Currently, it works because of no lock for read access and keydb_store_cert appends data at the end.