We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.

Things for 2.4 are all done.

For 2.2 we will for now only implement the encryption.

@gniibe: Would you mind to look at this?

README and INSTALL now suggest to to use a build directory.

Error checking of the parameter file is usually enhanced when adding new features. Keeping this task open for this specific request does not make sense,

Turned out to be a bit come complicated. I hope that I did not break any of the other pinentries:
rP8ab1682e80a2b4185ee9ef66cbb44340245966fc

This header was introduced close to 20 years ago. I agree that it does not make any sense - it might be a left-over from an old Hurd version. We can entirely remove it because string.h is already included and we also don't use memory.h anywhere in gnupg proper.

Yes, --export creates the OpenPGP specified format.

We stopped maintaining GPA in favor of Kleopatra.

Do you mean the pubring.gpg format or the on-wire OpenPGP format; ie. what gpg --export gives?

Not if there are technical reasons to keep the address. BTW, you solution would not help because the fingerprint of key is personal data in the same way as a mail address.

Will go into 1.19.0

A tool can't make some thing GDPR compliant - this is all about policy and informed choice. There is actually no problem if you allow ppl to decide whether to upload personal information to a public service.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

That is not a bug but required for backward compatibility. See me/ksba.m4:

I would suggest that with the VSD 3.2 we make --no-user-trustlist the default via the corresponding registry entry and explain how to use --sys-trustlist-name to use a custom trustlist.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.

I did some reworking and the outcome of the READKEY command is now (agent log):

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

Pushed to this site. Thanks for noting.

Its not used, so it can't harm.

Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.

I think we should make it explicit - this will be safer. As of now agent_write_shadow_key will do a check only in its special update mode which should be okay for now.

I can't see any explicit thing there.

That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.

I doubt that the bug is only in 2.2. The code in 2.4 is different but it may happen there anyway. It depends on the usage pattern.

(That's actually an old ticket but we still open)