(Please don't set a milestone tag for a fix to an already released version - we use the milestones to track done tickets). Use instead the branch specific tag so it ends up on the workboard.

Fix backported to 2.4

Passing ticket to werner to consider backports.

I suggest always updating modifications which are "exportable".

I do not want to do that for 2.2.45 (T7255) because we want to do that release RSN

works for VS-Desktop-3.2.94.2-Beta (Beta for VSD 3.2.4)

Porting to 2.2 was straightforward - we won't give it an extra QA run.

gpgme should handle lists correctly. In Kleopatra those options are not shown in the configuration dialog because they are GC_LEVEL_INVISIBLE, i.e. Kleopatra can read them programmatically but they are not shown to the user.

In T6882#191854, @werner wrote:

While testing this I noticed that only the last adsk or trusted key is listed. Thus several assurances of this options are not properly represented. See T7313

Fixed for master. Let's first test this with kleopatra.

Done for 2.2. It is already in 2.4.

Will do.

werner: Can you also backport listing of "default-new-key-adsk" with gpgconf so that Kleopatra can check whether a default ADSK is set?

Backported to 2.2

Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3

I guess this is now fixed for all branches.

The test with Gpg4win 4.3.1 (using GnuPG 2.4) seems to indicate that:

1. gpg didn't update the trustdb automatically after importing the extended trusted certificate.
2. gpg updated the trustdb automatically after deleting and re-importing the expired trusted certificate, but Kleopatra still showed the certificates signed by the trusted certificate as "certified". This could be a bug in the trustdb calculation (note the log message "Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet" which could indicate that gpg treats the key as valid although it's expired). On the other hand, my test with GnuPG 2.4 on Linux doesn't reproduce this problem.

And I can replicate it with the Appimage for VSD 3.2.2, too.

The issue is the same on import on the command line. So it's a gpg issue.

Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.

libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.

The new option `--proc-all-sigs' will be available in 2.5.1, 2.4.6, and 2.2.45.

2.2.44 seems to be released. Is it correct that this issue shows as "open"?

Did a quick manual test import and encryption/decryption with VS-Desktop-3.2.93.1-Beta with the relevant test-X509 certificate.
Works as expected.

This patch has a new fix for T5793 which is now only used where needed.

I don't think that we can do much manual testing here because we have all test cases anyway in the regression test suite and our local non-public regression tests (which has the p12 files we are not allowed to publish)

Alright. Done for master; backport will come soon.

Status is testing for 2.4, no backport yet for 2.2, so there it stays in the backlog column

The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).

Backported to 2.4. Options are now listed with gpgconf.

It would be helpful if gpgconf --list-options gpg listed the default-new-key-adsk option so that Kleopatra knows whether the option is set.

Not much QA can do here.

Now also with support for --quick-add-adsk in 2.6. This will work also for gpgme without further changes.

Done for 2.6.

Backported to 2.4 and relevant parts also to 2.2

I think it would be cleaner to create a separate ticket for making gpg fetch the requested key from LDAP.

Although it is implemented in gnupg-2.2 we should add another feature: Iff this option is configured, gpg shall try to load the requested key from LDAP in the same manner as it does for a trusted-key.

This should not be configured in Kleopatra but an option to gpg because this is a core crypto functionality. Thus is now a gpg task.

Pushed the fix: rGbb57c808b2ad: scd:openpgp: Fix PIN pin2hash_if_kdf.