May 28 2019
Sorry, I forgot to mention it. You need to add -v to the command line.
Which pinentry are you using in in what mode? Please do a sign operation and watch out for a line similar to:
Do you have any test cases? Note that T3966 is due to missing support for SHA-256.
Can you please give more details and tell whether this is powerpc specific.
We only supported SHA-1 signed OCSP requests. Fix will go into 2.2.16.
May 27 2019
I doubt that we are going to implement this.
Thanks to your very good analysis, this was easy to fix.
See the man page on how to delete subkeys or just the primary secret key with --delete-key.
- GnuPG bug fixing
- New I-Ds for WKD and RFC4880bis due to pending expiration.
- CRL testing
May 25 2019
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.
May 24 2019
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.
May 23 2019
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.
May 22 2019
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.
May 21 2019
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.
Thanks. Fixed in master and 2.2.
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.
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.
May 20 2019
That is on purpose. Exporting of a secret key should in theory not be possible at all via gpg. In practice we need a way to export a key, but that should be the exception and thus we do not want any caches for passphrases to have an effect.