I don't think that we are going to change this. All data is utf-8 including the *conf files.

Sure, but lets use that ticket for this. if you have another topic, feel free to open another ticket.

See also T4013 which is about ed25519 key support

It is in the tarball:

doc/DETAILS

and for example Debian installs it as /usr/share/doc/gnupg/DETAILS.gz. Check out the first section "Format of the colon listings". Or use GPGME which provides C, C++, Python and JSON bindings. Sorry, it never made it to the website.

@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?

Okay, I see the problem. The microsoft toolchain is more picky about de-facto standard use patterns with common blocks and the author of that code was not ware of this. Thanks for reporting, will be fixed in the next release.

Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.

This function is not exported on purposes. Even the name of the header file indicates that tis is internal. External, that is public functions of the API, are defined gpgrt.h and only made externally visible by including them in the .def file. This has not been done and so I don't understand your bug report.

According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

Fixed. Thanks.

Good idea.

The quality bar is switched off by default. That feature including the quality was ordered and accepted by a client. I don't like it either and thus the new default of having it disabled is a useful solution.

So you mean the bug that you see a second set of passphrase dialogs iff you told the first one that you don't want a passphrase? That is not trivial to fix because we use the passphrase cache to avoid the double passpharse questions. Without passphrase cache we need a separate code path.

Yeah, it is annoying. Maybe it is indeed better not to ask for a passphrase at all.

Enigmail used to use gpg-wks-client. @kai implemented it back then and we had a milestone meeting to show that it works with posteo.

Thanks.

Thanks.

Thanks.

Thanks for the report. Fix will be in the next release.