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.

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.

We should re-test this for gnupg26

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.

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.

FWIW: the encryption part of the ADSK feature has been released with

Will be updated eventually. Thanks for reporting.

Please use the mailing list for such questions.

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

Use --large-data-tests with configure and go out for a real long lunch

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

T6512 is only for gnupg26. In gnupg24 we don't use fd-passing.

gpgtar is compatible to PGP Desktop's format which they call ZIP. This is technically ustar with the most common extensions. Don't let us go into yet another TAR format discussion.

Also added a new gpgme context flag "proc-all-sigs" and a --porc-all-sigs option to gpgme's run-verify.c tool.

The new option `--proc-all-sigs' will be available in 2.5.1, 2.4.6, and 2.2.45.

Good idea. Done for master and gnupg24

The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

Answer in non #dkgmode: Seems I don't need to evaluate the details then. However, excluding auth only keys should be a no-brainer.

Most users are able to read and in particular to answer the question: Do you see the text "rfc822-email"? Try to ask them whether they see a white box somewhere. Nearly impossible w/o a screenshot and even then you get wrong answers. The whole issue is about helping our support people. YMMV

Having a filename even for a bad or empty attachment is a Good Thing™ for the support desk. I also see no regression risk here.

I need to evaluate this. However, what we can can do already now is to ignore all Auth keys - they don't matter at all and it is pretty convenient to have Brainpool primary and encryption subkey but an ed25519 auth subkey on a card. That is because ssh does not support Brainpool. We show such a key (i.e. Yubikey) as compliant.

Please remove the any configuration file changes from kwatchgnupg. That is not a good idea. Launching kwatchgnupg is
a debugging aid and not a regular operation and thus the user can also enable debugging selectively with kleopatra.
kwatchgnupg should listen on the standard socket socket:// - for Windows we don't yet need it because there we don't have sockets anyway. Or well, eventually we will have same but that requires work in watchgnupg and gpgrt for the logging stuff.

Okay. Let us split it into different tarballs and repos. We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility. C++, Qt, Python will then go into separate projects. The old common List stuff will be kept in gpgme core for now. The gpgme core sticks with autoconf stuff but for C++ and Qt cmake style will be used instead.

Okay, I see now that this is US-English and Unicode.