With today's release of npth everything should be set.

The patch is part of 1.7 - please test and in case of problems feel free to re-open.

A way to generated keys in the usual s-expression way has been added. This allows us to get the keygrip for the key.

Closing due to age and because gpg4win 4 started to using the much improved GnuPG 2.4

With backup and restore import/export options all should be set for a long time. I guess this bug can be closed.

Way to old. Does anyone still uses CAcert?

Lowering priority because it does not seem to be a popular issue.

Thanks for your work. I applied it to Gpgex.

Okay, backported to 2.2.

FWIW, I posted some ideas at https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000043.html . For official use in Germany we will very likely also add Brainpool curves as a replacement for the IETF curves.

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Please note that this is a bug tracker and not a general support channel. You would also need to write in English - we can't triage reports written in other languages.

gpg --list-packets shows this:

I need to come up with a better strategy here. --refresh-keys is a very useful command and it should do what the user expects. Maybe we can adjust the behaviour iff we detect that there is an LDAP keyserver.

No, I am not aware. I can't remember whether PGP once had such a bug because @dshaw did most cross-testing and fixing for PGP bugs. I would suggest to remove any such checks. IIRC, this was introduced by PGP 2 to speed up signature checking. 30 years ago RSA operations were quite expensive.

Although, we don't use our usual s-expressions we need to add a way to derive a keygrip from Kyber et al and also to wrap the key into an s-expression to that it can be stored by gpg-agent in its usual files. An exported new API to get the keygrip of a KEM key would be good to avoid encapsulation but for other purposes an encapsulation is still required.

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Portable Apps are a Bad Idea because they bypass important security mechanisms. In any case please tak such discussions to a mailing list and please do not use the bug tracker for this. The audience of bug reports is pretty limited.

Quick hint how to test a fix given that the versions.gnupg.org currently does not carry an entry for gpg4win.

You mean the Authenticode signature? Afaics, only the gnupg files come with such signatures.

@Jakuje, you are right. This is a plain error and we should do a new release to avoid false errors.

There is no Enigmail for TB anymore.

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

@Karam, please test as suggested by @ikloecker.

Setting the priority to low because that is the task for the KDE translation team. I am not sure how we can interact with the translation team, bug tracker wise. Do they have their own tracker?

Please post the output of "gpgconf -X" and "gpgconf -V".

VS-NfD is not a standard but a classification for restricted data. Software used to convey such material needs an official approval and is bound to certain organizational requirements. That is what "VS-NfD konform" says. The community version of gpg4win does not have this approval despite that it is technically the same code as the approved GnuPG VS-Desktop.

Oh well, it does not use the c++ binding .

The old debug output is in genral okay but what I would do is to add a couple of log_debug calls like