Right, that was missing. Fixed for master and 2.2. Noet that for kill and reload we added this already in 2016.

No, that is excessive. If the license blurb will ever be change this can be done but not just because of changing a single letter.

Sorry, I will revert this.

Attacks always get better and thus mitigation based on uncommon jpeg UATs would help only for a short time.
Maybe having a SHA-1 warning in 2.2 is also needed.

I would prefer not to fix that. I did some experiments on replacing all the runtime parsed ECC constants by static data. Adding the other constants will then be simple.

There is actually a problem with --use-embedded-filename. Given that the option his highly dangerous to use we have not tested this for ages. We will see what you we can about it.

Thanks for the hint on the existing OID I already looked into that and planned to use one from the GnuPG arc, But an existing OID is better. I still need to figure useful workflows but something like this will be useful for smartcards..

Good catch. Thanks for that work. I'll apply it to master and 2.2.

Yes, that term is overloaded. The reason in this case is that we once replaced "trusted key" by "valid key". That term "valid" now conflicts with another older use of valid. Using "self-signed" here seems to be more confusing that just removing the (first) "valid".

This is easy to explain: dirmngr receives already escaped data and that is what you see in the log. For proper parsing of the URI the escaping needs to be removed and only before sending the request the required escaping is applied. '@', '<', and '>' do not need to be escaped and thus you see them as they are.

I anyway plan to extend the --quick-gen-key parameters to allow the specification of several subkeys on the command line.

I removed this specialized error message. Thanks for reporting.

"valid user-id" means a user id which is properly bound to the key; that is the self-signature checks out.

I keep this open to track the mentioned change for gnupg 2.2

How a digest algorithim is selected for a key signature

No, personal-digest-preferences are not used to select a digest algorithm for key signatures. The only way to use a different digest-algorithm than select by gpg is by using --cert-digest-algo. But take care, you can easily cut into your fingers when using such override options.

I have not yet looked at the details but I do not consider one-time allocation a problem. If you want to silence ASAN it is possible to use gpgrt_annotate_leaked_object( foo). Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

• For 2.3 we should ignore all SHA-1 key certifications and warn about SHA-1 binding signatures and offer to migrate them.

How a digest algorithim is selected for a key signature

We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

Thanks for the tests. I just fixed this one and will do replace some code in master, soon.

I often put an extra nul byte at the end of binary data so that accidental printing the data (e.g. in gdb) assures that there is a string terminator. But right, it should not go out to a file.

We fixed this bug already in the repo. See T4459.

Isn't the Sparc crypto instruction set only available in kernel mode?

That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.

Argh, that Python specific stuff Ben used is weird and does not fit into the autotools model. Someone(tm) need to have a closer look at it.

The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.

The thing is that that I accidentally added the -Wno-* flags only in maintainer-mode as they were -Wmore-strict-warning-flags. One reason for using more strict warnings in maintainer mode is to allow building with older gcc versions without having to test for the availability of the warning flags.

Put

log-file /somewhere/scd.log
debug ipc,cardio
verbose

into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a

debug-ccid-driver

in scdaemon.conf will also be helpful.

If you have a patch please send it either by mail to gnupg-devel or attach it here. Thanks.

Please explain in more detail what the problem with Cygwin is.

Since 2.1 the standard use of gpg-agent is to have it started on demand by the components which require it. The use of
"gpg-agent --daemon /bin/sh " should be used for debugging only.

FWIW, with 4a130bbc2c2f4be6e8c6357512a943f435ade28f I fixed a similar report by @syscomet but lacking a test case this was a blind flight ("This patch is not tested but a good guess."). Thanks for tracking it down.

That might have been a regression since one of the Phrabricator updates (we need to apply out own patches each time).