The code had the assumption that a content-id
could only exist on an attachment for HTML mails as it otherwise
does not make sense.

fix build with a fixup that got applied twice. better benchmarks

I doubt that we are going to implement this.

Thanks to your very good analysis, this was easy to fix.

@werner Thank you for resolving this issue.

See the man page on how to delete subkeys or just the primary secret key with --delete-key.

I was able to reproduce this when I forwarded the mail after opening it in a new window. Somehow that appears to influence it.

I think that when using GNU autoconf's configure, you should have the ${prefix}/bin in your PATH.

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