Are you not reading what I am saying to you?? Once again, your explanation is INVALID because that would mean that gnupg would be BROKEN, because it would be a NON-COMPLIANT http client according to the RFC I quoted.

I explained why the keyserver access requires access to the DNS. If that is not possible the keyserver code will not work. If you don't allow DNS to work you either have to use Tor (which we use to also tunnel DNS requests) or get your keys from elsewhere. Also note that the keyserver network is current several broken and under DoS and thus it is unlikely that it can be operated in the future.

Simply sending "KILLSCD" is implemented.

There is also a confusing case: a subkey expiration date is set, but the associated primary key is expired.
Pushing a fix in master.

You need to update the public key and convey it to the sender. This will solve the problems. You should also ask the sender to update their software so that an MDC is always used regardless of the flag.

Actually I have a different approach to fix this bug(let). Please give me a few days.

Yes, very exactly indeed: It's GPgOL within gpg4win-3.1.1... ;) But you're right, the key itself is a legacy key, created back in 2001 with a commercial PGP Solution and later on the key was "spiced up" cipher-wise...Goal ist to get everybody (also the sender) to gpg4win-3.1.7, but how can I achive not having lots of eMails which one will never be able to decrypt?

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02
Add the if (okay) conditional back to the code

Rebased on top of master: 4c7d63cd5b02

Rebased on top of master: 4c7d63cd5b02

@werner Thanks for merging the --dry-run patch in 110a4550179f !

Committed to master: 110a4550179f

Do you know which software the sender uses for encryption? That software may simply ignore the preferences or the sender also encrypts to a legacy key using a software which does not force the use of an MDC. Sometimes keys are generated with gpg but used with other software - without updating the preferences of the keys.

I don't see why the documentation needs to be fixed. gcry_sexp_canon_len returns 0 for certain and s-expressions, meaning tha the s-expression is not valid. After all the s-expression code in libgcrypt does not claim to be a general purpose parser for s-expression but is targeted towards Libgcrypt needs.

By marking this as "wontfix", you appear to be saying that you won't even fix the documentation to describe the constraints that gcrypt intends to enforce. This is surprising to me.

Thanks. Fixed in master and 2.2.

In master, I pushed a change, closing.

Also fixed for 2.2

The behaviour related to ssh key access is due to the way ssh works: After a connection has been established to a server ssh presents to to the server all identities (public keys) it has access to (meaning it has a corresponding private key). Thus we can't tell ssh all the keys we have because that would be an information leak and may also take too long. Because the user may in some cases not want to use the ssh-agent but resort to ssh command line input of the passphrase, we do not insist on using a key known by gpg-agent.

For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.

I located the bug in agent/command-ssh.c.
Our practice is two calls of gcry_sexp_sprint; One to determine the length including last NUL byte, and another to actually fills the buffer.
The first call return +1 for NUL byte.
The second call fills NUL at the end, but returns +0 length (length sans last NUL).

Perl would be okay for maintainer mode but not for regular builds. The reason is that perl is already used by autotools but a build shall still be possible w/o perl.

I spent a lot of time trying to figure out how to automate the interface between my preferred password store (gnome-keyring, via libsecret), but with the loopback pinentry mode changes in gpg 2.1, it is much harder (if not impossible) to do. Having passphrase caching is the only thing preventing me from choosing a weaker passphrase on my gpg keyring.

Disallowing passphrase caching is likely to have the unintended consequence of users choosing weaker passphrases that are more easily memorized and/or typed. Caching should be permitted, IMO. This puts more decisions about passphrase management into the control of the user.

I'm looking into doing a pretty epic hack of using the switch_endian syscall to speed this up.

And yet, that interface is already being used by the agent-transfer utility in monkeysphere. The interface exists, it is not marked in any way as unusable or deprecated or off-limits, so it is used.

I don't know. That would make it a relatively easy transplant. We've also used the Cryptogams code as a reference for Golang enhancements, if that helps. I'd welcome guidance on the matter from a maintainer.

Would the maintainers accept having perl in the repository? Linux does it.[1]

Closing this as the moving problem was fixed.