No sorry, we won't do that for the regular source. However, the full source for the binary installer is xz compressed. That is because we are legally required to publish the source but in reality the source ist not used and weel, to build you have lots of other requirements with xz being the simplest one.

proper benchmarks

Fix alignment needs of vcrypto instructions.

I guess we can do that. Thanks for the hint.

Interesting tinge: The main CRL of the dgn.de CA uses a nextUpdate in the year 2034 (15 years in the future) which would force dirmngr to cache the CRL until then. However, the CRL of the intermediate certificate has a nextUpdate only one month in the future. There is currently no entry in that second level CRL, so their idea might be that an updated second level CRL will also trigger a reload of the main CRL. I have not checked how we implement that in Dirmngr but I doubt that such a thing will work for us and that it is in any way standard compliant.

Consider using tests/bench-slope to get cycles/byte results so they can be compared with https://github.com/dot-asm/cryptogams/blob/master/ppc/aesp8-ppc.pl#L34

Didn't do sufficient testing.

Actually include modified perlasm file.

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 I 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

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).