And the US administration might even change the definition of a year to, say, 100 months so that potus can rightfully keep his promise that there won't be more election in the foreseeable future ;-)

But the function works and returns the peer's credentials?

The main problem here was that this all is not async-safe and thus I once implemented only the standard cases I could test easily.

For the records:

A bug tracker shall never be used for discussion because the audience is not as expected. Only very few people follow a certain bug but several hundreds are following discussion on gnupg-devel@. That is basic hacker knowledge.

Heiko, I told you already in T7106 that it is not a good idea to re-open a ticket. If you really want to discuss stuff, take that to a mailing list.

Yes, this is related to T7547. With my last fix for that I overlooked that we use PUBKEY_USAGE_CERT to internally request the primary key but that one is not set because in general USAGE_SIG means the same (except for some case in PGP7 mode).

> I'm not sure i understand why "the latest" should be preferred.

I also spend some time with this and the problem is described by this comment in trustdb.c:

No, it is not a bug and I beg you not to change the status again. Don't start the same trouble here as some of you guys did with the IETF WG!

I can't speak for C++ but I appreciate that you used the same flag values as in gpgme proper.

This is just one build of PGP and you would need to test all versions on Windows, macOS and Unix. You also need to test against all versions of GnuPG since 1998 (when we started with interop tests). We won't change this in GnuPG and risk regression. If you have a problem with that go and add a fix to your tool - name it bug compatibility or whatever. And please do not re-open this bug.

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

The report is correct but it does not make sense to fix it. If you want to use a concrete expiration date just enter the IS date at the prompt; use ? at the prompt for a short description.

Thanks for the patch but I think it is better to fix this in yat2m. I created a new tag for bugs related to it.

This is really a minor thing and and it is actually true if you also sign something.

BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.

No more octals .-)

In T5444#146395, @werner wrote:

You should anyway use --quick-gen-key.

Gpg4win is a community version and we may or may not apply Authenticode signatures. You can do that yourself, after having checked our OpenPGP release signature. You may however be interested in GnuPG Desktop, which comes with full support and also Authenticode signature.