[copied from gnupg-devel@]

I can replicate this even with master. Good catch.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

Do you mean this?

The only mitigation I can see for this is a better error message.

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

So, this is VERIFY reset allows the host to implement the "force" flag we always had in the card for the first key. At least kind of, because malware can still suppress the VERIFY reset ;-). The integrated "force" flag requires the admin PIN, which is malware should have more problems to snoop.

The idea with the smartcard is that you can limit the time of exposure
of the key. Leaving the card accessible to the host is thus not a good
idea. Malware can simply snoop the PIN from the last operation and
then, at its own discretion, use the keys of the card. This can only be
avoided by using a smartcard reader equipped with a pinpad and able to
filter commands so that it is not possible to bypass the pinpad (which
is easy for the host).

dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

Please move this also to another branch.

Thanks. That reminds me again that a GPA release is due.

I recall something about this on our mailing list.

Do you have the specs for getenv_r? I can't find such a thing on FreeBSD or Debian

IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.

I prepared Libgcrypt for the 1.9 series, thus feel free to merge your patches to master anytime you like.

The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.

Can you please try 2.1.23 ? We might have fixed that already.

Nice talk, just watched it.

Is that really the entire mail? I can see only the header of the mail but not the body. How did you copy the raw mail?

Please see my comments on rM9f24e6c9010e171fd11c5cdac797cb8ce2e501dd

It would also be good to explain the relation ship of this feature and the gpgme_get_dirinfo - if there is any

I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.

I would suggest that MUAs who care about privacy do no use S/MIME at all or at least direct GPGME to not consider CRLs during signature verification. We don't have such a feature in GPGME right now but I think that is the right place to add it. X.509 is way to complicated to avoid meta data leaks.

Smartcards and on-disk keys are very different things and handled by different processes.

Please try again with a recent version of GnuPG. We had a dozen more releases since 2.1.11 and we can't spend time on trying to replicate bugs which may have already been fixed in the last 18 month.