Given that we backported it to gnupg22 we should go ahead and implement that flag. For example: if the flag is set for any root CA we will show compliance only if that flag is set for the specific root CA. This way we can introduce this feature w/o too much backward incompatibility. We could also hide the feature behind a compatibility flag. There is no reason why we should not add the de-vs trustlist flag to our vsd configuraion files, right away.

This has now been implemented for gnupg26 for public key encryption. However, symmetric key encryption, a man page, and the gpgme support are missing right now.

I'd vote for the second (utf-8) which is more aligned with our other APIs.

Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:

I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).

Thank you. Applied.

The environment is a property of the C runtime and well defined as a block of concatenated C-strings terminated by a zero length C-string. In case of wmain the C-strings use wchar_t and not char.

Thank you for the bug report and your patch.

Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.

We should re-test this for gnupg26

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

The problem might be that we use getenv all over the place and don't specify the content. Frankly, it is not 100% clear to me whether the value of an enbvar need to be a string or can be arbitrary data sans nul? However, I can't remember that I ever wrote any code which did not assume ascii or utf8 for the value.

Here is my attempt:

Additionally to performing the lookup also for OpenPGP cards the status messages that are emitted during the lookup are now shown in the status bar instead of with a label above the key list.

Use of execve is better (avoiding use of environ).

This ticket got superseded by T7262: gpgme: Move C++ bindings, Qt bindings and Python bindings to separate git repositories.

Since VSD 3.3 will likely include this change in gpgme I add the vsd33 tag.

In T4060#190972, @werner wrote:

We need a way to pass --known-notation to gpgme_op_verify

We need a way to pass --known-notation to gpgme_op_verify

I asked you to write to the mailing list instead of filing a bug report. A mailing list has a far wider audience than a single bug report. Our bug tracker is not a help forum or a place to ask questions.

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

I re-consider. Adding arguments to existing gcry_kem_keypair is not good since it introduces API break.
Instead, I add gcry_kem_genkey with additional arguments (which can be used for deterministic key generation).

Wouldn't anyone suspect that you are in the habit of dispensing the ''Invalid'' label without discernment for reports that, however, have no basis as such? But what on earth could you possibly be trying to achieve by acting in this way?

In T7283#190941, @gniibe wrote:

I can replicate the problem.

The cause of this is that when it's comes with loopback mode, gpg-agent inquires back to the frontend and the buffer overwritten, which results parsing the line wrong.
I'm going to fix.

In T7283#190901, @werner wrote:

y38k problems with some frontends are known for some 32 bit platforms.

Please write a proper bug report and don't expect us to read a reddit thread.

I can replicate the problem.