Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remind that until a few years, Windows had the opinion that Germany uses the Westeuropäische Zeit like Portugal or the UK.

That is quite possible because we do not have a test system for RISC-V and the make release tarbegt is not abale to verify this.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

Lucas Mülling commented yesterday on gnupg-devel:

Right now we have

I doubt that this is a gpgme problem. With a gpgme log we will be able see the exact commands send to gpg and replicate this on the command line.

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.