Page MenuHome GnuPG

GpgOL: Key generation window does not close
Testing, HighPublic


Leftover issue from T6805.
But it is seen in OpenPGP key generation originating from GpgOL in general.

Try to a signed mail without a certificate for the sender.
Choose "Generate key" -> a "generate key, this may take a while"- window appears and does not go away, although the key is generated already.
You have to click "Abort" in the "generate key" and the "security confirmation" windows to be able to continue with the newly generated key.
That is you have to hit "Send" in the mail window again.

In contrast to T6566 the newly generated key is not selectable in the "security confirmation" window:



Event Timeline

I'm not seeing this on Linux with test_keyresolver as mentioned in T6566. Even after allowing test_keyresolver to be run in sign-only mode as seen in the screenshot.

The only possible explanation I can see is that the signal-slot connections (using function pointers and lambdas) don't work because the progress dialog should be hidden when the job emits done() (which works on Linux with test_keyresolver).

aheinecke triaged this task as Normal priority.
aheinecke edited projects, added libkleo, gpgol; removed kleopatra.
aheinecke added a subscriber: aheinecke.

Me neither. But I take this since I can better debug this on Windows directly since this seems to be a windows only issue and it might be a build issue.

We had some problems with connections on Windows in the past which appear to be gone now. I was neither sure what created these problems nor when and how they were fixed. Laurent just came along and overwrote these old type connections with new style ones even though I had a comment on them "Please do not change that because it does not work on Windows otherwise" and it still kept working.

Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).

Mh, I found some commits related to that 0796e04aa43c4500fb0f2c378b9a6cadf53a0a94 a43080fb0472afb46726cc555efffa102de9c7cc 810ed7b374f38eb7e038a83a557c8b6b91a65da3 if I remember correctly I even discussed this with Thiago and or David Faure back then and we figured it was a problem with default arguments. And there might have been a difference in KDE Compile settings and the compile settings with which QGpgME are compiled. It is pretty weird though even after some searching I can't find an initial commit from me that might be more verbose about the topic then just "Again new style connects won't work".

And then this commit is where most of them where changed back but somehow kept working: 96da231f97eff9485f62ab925d81252f5f97fc31

Does Qt log failed connections?

aheinecke raised the priority of this task from Normal to High.Mon, Nov 20, 1:40 PM

Let me put this on the 3.2 workboard since we already have the "reports error when canceled" on that workboard and T6566 too depens on this, in fact I am currently working on this even though it was not on the workbaord.

aheinecke moved this task from Backlog to WiP on the vsd32 board.

It does not log failed connections but new style connections are never logged when they fail. Since they can't fail ;-)

I was thinking that maybe adding KDE Compiler settings to gpg4-tools might fix the issue, I will try to figure it out a bit and if nothing helps I will probably switch to SIGNAL / SLOT syntax and hope that the problem either goes away with Qt6 or if we use KDE Compiler Settings in gpg4win-tools.

Ah no I see the difference here. Instead of connecting to a lambda with no args 96da231f97eff9485f62ab925d81252f5f97fc31 connected to the functions which were used in the old signal / slot syntax. I think the fix might be to explicitly list the args of the quickjob result or to use afunction to handle the keygenresult.

Well, the failed new style connects are logged for me with "QObject::connect: signal not found in QGpgME::QGpgMEQuickJob". I haven't dug into how the check works for those connects. It turns out that none of the three connects to the signals of QuickJob work (two of those connects are done in ProgressDialog). Even the connect to the argument-less done() signal. So this has nothing to do with default arguments. This is very disturbing because this means that any other connect might also be broken.

And it's the signals that are not found. I don't see any indication that this has anything to do with the slots/lambdas.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

@ikloecker I suggest giving up on this, I know that it is frustrating but it does not make much sense, it is probably related to some compiler settings / Qt cross compile issue and might be a bug in qt. Just do an old style connect and leave a comment that we will revisit this with Qt6. When VSD 3.2 is our last major release based on Qt5 we should not spend too much time investigating this which might be completely different (or not) with Qt6.

ikloecker changed the task status from Open to Testing.Tue, Nov 21, 1:58 PM

I have added a workaround and tested it on Windows. Works now for me, including T6566.

works, VS-Desktop-

ebo edited projects, added vsd32 (vsd-3.2.0); removed vsd32.
ikloecker mentioned this in Unknown Object (Event).Mon, Nov 27, 10:00 AM