Thank you!

See T7046 for the release info. Note that the mentioned fix for kwallet already landed.

I still need to land the fix for the kwallet problem, but that can be done first thing monday so nothing that really blocks a release

I had a look at the open tasks for pinentry(-qt) and didn't see anything that we should address before doing a release. @werner?

I should say: I can ship a snapshot in Gentoo if that's okay, but I'd prefer not to.

Note the relationship to T4195, T4826, and T4766

Thanks for reporting and testing my fixes.

Our tests are fine as of rM2e7a61b898fc.

It will be a lot of work to change this in gpg. Thus ISO dates were only introduced with gpgsm after the former glibc maintainer refused to switch to a 64 bit time_t - which would have been easy enough at that time (about the year 2001).

Yes, it's a problem in gpg. gpg asks for the expiration date of the subkey

[  277s] EditInteractor: 4 -> nextState( GET_LINE, keygen.valid ) -> 5

gpgme replies with an ISO date

[  277s] EditInteractor: action result "21000101T120000"

Then gpg asks again for the expiration date

[  277s] EditInteractor: 5 -> nextState( GET_LINE, keygen.valid ) -> 4294967295

which gpgme doesn't expect, so that gpgme return a "general error".

Thanks! It seems that we pass the correct expiration date to gpg:

EditInteractor: action result "21000101T120000"

So, it's maybe a problem in gpg now.

Hmm. Please run the test with

GPGMEPP_INTERACTOR_DEBUG=stderr GPGME_DEBUG=8 TESTS="initial.test t-addexistingsubkey final.test" make -e check-TESTS

in lang/qt/tests under the build folder to get (a lot of) debug output.

WIP with those three patches:

There is a reason that we switched to ISO Date strings in large parts of GnuPG ;-)

I see, I wasn't aware of this. Thanks for fixing!

Thanks for commenting. I close this bug then.

Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)

The Qt upstream bug report has just been rejected. I hope something can be done here...

Yeah, that sounds good to me.

In T5551#148510, @werner wrote:

I would prefer to see a fix/hack in pinentry-qt instead.

I see. Thanks!

To minimize the risk of regressions.

Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.

Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.

I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.

Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.

The problem only occurs with the gtk platformtheme.

I sent a message to gnupg-devel about this issue as it will probably hit more people now that the keys used are expired :-(

Oh,.. it is even worse. The conflict keys expired 2019-01-06 so they are actually expired right now.

I don't know why @BenM closed this bug given that he mentioned that the qt part is yet not solved.

We've run into the testTofuConflict failure on NixOS. gpgme v1.12, gnupg v2.2.12.

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.