I can't see any bug here so I will close this bug now.

Please use one of the mailing lists to solve your problem. 2.3 is a development version, so I wonder from where you got this version of GnuPG.

Actually the temp file is created but because the photo viewer is run as a detached process and gpg keeps on running, the temp file has been removed by gpg at the time the photo viewer tries to open it. Ooops. The correct behaviour would be to wait for the photo viewer to be finished. We use

That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.

Fixed in amster and 2.2:

This requires too much changes and does not reflect the reality. It actually makes debugging harder for us.

I pulled that branch with the commit w/o problems. However, as noted on your commit I won't apply that because it does not make any sense to change boilerplate blurbs for just an additional 's'. Nobody really uses that and browser can try to use https first. Sorry, there are more important things around.

Will give you more detailed info about your certificate. For even more details use --dump-chain instead of --list-chain.

Thanks

Applied to master and 2.2. Thanks.

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.