Not sure why this was assigned to Andre.

In T5543#168681, @ebo wrote:

How about emptying both fields in case of mismatch and start from the beginning?

This exact step works. But if you misspell the repeat its unintuitive again what you should do.

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing with reference to external testing

closing and opening new tasks is the best option

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.

gpg-agent now supports READKEY --card command which creates stub file when it's not yet available on host computer.
It was implemented by rG82cbab906a3e: agent: Add --card option for READKEY.

Yes, --export creates the OpenPGP specified format.

Do you have some examples (hexdumps) of how the structure looks like? I think I have seen something similar in some other smartcards. Would that be possible to write some kind of unit test for this?

Fixed.

We are now using the new helper DeVSCompliance::keyIsCompliant everywhere where previously isKeyDeVs and uidsHaveFullValidity were used or should have been used (as in SignEncryptWidget::isDeVsAndValid).

Hello All,

We stopped maintaining GPA in favor of Kleopatra.

I mean what gpg --export gives Werner.

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.

Werner, according to GDPR if a user upload a key with it's name and email address he or she may be able in the future, to ask for removal of this information.
How is this going to happen, to a keyserver, accordingly to your suggestions?

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.