if a user decided to use the Web Key Directory, this should be used instead of falling back to whatever has been configured (nothing else by default)

On the ml there was another request for this use case

What is the current encoding? OEMCP ?

So if gnupg version >= 2.2.22 Kleopatra needs to convert the passed filenames to UTF-8 and pass them with the --utf8-strings option to gpgtar. This needs to be changed in Kleo. -> Assigned to me.

Unicode file names will now also work - see T4083 and T5030

Unfortunately we can't help you here as this is not a GnuPG problem or one of software we maintain.

Excellent! thanks for having considered this.

Done for master and 2.2.22 - libgpg-error 1.39 (not yet released) is required for the actual fix.

Read through it, thanks for the updated description!

Good catch

The options now work as documented. More tests on Window are required and eventually we need to handle non-ascii characters in file names.

Fixed for 2.2.22

Thanks. Fixed for 2.2.22

Thanks for reporting. Fixed for 2.2.22. repeat==0 works like before and repeat>1 also (that is several passphrase pinentries will pop up).

I's say we should not do anything but solve that along with the move of all fd/fp/sock/HANDLE stuff to gpgrt to solve this at one place. We need that anyway to properly support Windows64. We won't be abale to do this for 2.3, though.

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

For GNU/Linux, it's done.

If you use

Hello,
just reading the issue in detail.

Just reading this issue in detail.

It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.

Thanks

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

Here's the patch:

I believe the problem here is OS X 10.12's (and above) System Integrity Protection (SIP). SIP protects system integrity by doing things like sanitizing environmental variables for system programs. Sanitizing environmental variables on system programs avoids code injections.

-std=c99 is probably the reason that the tests fail.