The debug log was from gpg and not from dirmngr and thus it is not helpful. I also guess that an older dirmngr was still running, because the LE bug has been fixed in 2.3.4.

The odds for this case are infinitesimal so this should not have high priority. I consider this only a code-is-as-specified thing.

The problem is just that there are not that much keyservers left and thus I added those running by large organisations. I really don't want to overload your servers. I would also trust nlnet more than canoncial which is why I started with them.
Its all a mess. Maybe no keyserver should be the default.

Please see https://gnupg.org

FWIW, We have a similar mechanism for the secure memory

That is a security feature of WIndows. We can't do much about it except for bad hacks. Checkout Kleopatra to see how you can improve this.

Things are not that easy. I actually introduced a bug in 2.3.4. Here is a comment from my working copy:

For support please use the mailing list and not the bug tracker.

Seen. @jukivili can you please add it to the AUTHORS file?

We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.

It would be easier to educate gpgme about the 11.

The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.

Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.

ikloecker: Please go ahead

IIRC, the problem is/was that this breaks some old keyservers. But there are no more old keyservers - if there are useful keyservers at all.

A clumsy workaround for the Kleo bug is to put "keyserver ldap:///" into the global gpg.conf after an ignore section containing keyserver. This will let gpgconf emit "ldap:///" unless a local gpg.conf exists.

Thanks for the offer. However, the core developers are using tokens for more than a decade meanwhile. We even make our own tokens ;-).

The first is a warning and the other error codes are exactly what we want.

You may run

Yeah, remove it.

@aheinecke: Please change the Original URL to https://dev.gnupg.org/w/gpg4win-or-gnupg-vs-desktop-bug-report/
. This creates a cover sheet which does not ask the user to login or register an account to later just realize that she may seatch the tracker w/o an account.

There is a "sharing violatation", error which means another process got access to the card. You can try to put

--quick-gen-key supports this but there is no general option; the 2 years are hard coded.

Sorry, we won't do that. Actually SHA-1 is still allowed when used in a KDF mechanism like S2K. OpenPGp is about Public Key cryptography and for that it is important to keep the keys safe. Protection the private key with a passaord is a failstop scheme which gives time to revoke the actual key and handle the compromise. When suing symmtric encryption (gpg -c) ist is strongly sutested to use a password with at least 128 bit entropy (e.g. by using our magic wand button). The S2K iteration is actually not needed in such a case.

Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

We should only allow this for v5. This way we get incentive to move forward. ed448 requires a newer version anyway and thus it is good to take this as an opportunity to also demand AEAD etc.

Thanks for the well written bug report and the fix.

I guess this is solved. Feel free to re-open and schedule for 2.2.34

Might be a TOR Thing?

FWIW: We need a DCO; see doc/HACKING.