Assigned to me for testing.

I think cancel should not save the settings. A case of "uuuh I clicked something wrong and now I am confused" -> "Cancel" -> "Phew everything back to normal". Is more valid then just looking around, canceling and then coming back later and expecing the same state. I would say this resolved.

@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 I thought about this some more. Why do we do the READKEY when we could look up the keygrips and see that we already have keys for this. That sounds to me like a simpler fix then changing how gpg-agent behaves here. Although I still think that gpg-agent is in the wrong to just overwrite and potentially delete softkeys here.

Ok since this does not happen with other cards this is definetly a gnupg issue I just checked with a telesec card and the behavior there is different.

@werner I think this question is for you to answer. IMO these files should not be overwritten. I mean they could contain actual secret keys instead of just the shadow keys and then those would be overwritten, right?

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.

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

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.

Yes these files are rewritten on every iteration.

I know that there is an issue here that the about data in the option dialog of gpgol that is fixed with afb6ce9ce00538242ac69434f586749217f9f619 but did not make it in the current beta. And since this is also related to the tender version i leave this a bit open for now. I think we also might need to reload the welcomewidget in case the signature verification takes longer then constructing the welcomewidget.

So I tested this with an S/MIME certificate for which the CRL was not available and as described by the original reporter Outlook just froze. And you had to kill it. With the current beta you would get the dialog to encrypt the message anyway but this does not make sense for draft encryption where you can only select your own keys.

@ikloecker I would like your opinion if this should not wait for Qt6 if it is an issue with Qt. I guess "prio low" would anyway mean. "Let us leave this for a while" :)

Merci vielmals. Cherry-picked.

I cherry picked it anyway. See my notes in T6813 I think I will at least workaround that one tomorrow.

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".

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.

Not important for VSD 3.2 but yes I would like to see that fixed. Especially since we want the resolver also in KMail.

Belongs to T6789

The commits ^ added here accidentally linked the wrong task number.

We don't need that anymore in my opinion if customers do not complain that taskkill is too evil for them.

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

The reason for this is that this still uses the libkleo::gpg4win class for the version info, the about data in GpgOLs help dialog should be similarly broken.

We decided that this is an invalid issue most likely related to the test cert / test card. We have tests done with real world Signature cards with brainpool and they worked.

Welcomewidget is broken now: Welcome to Kleopatra: [Kleopatra] instead of showing the version.

Screenshot with details about the key in question. It might be a weird one since it does not have usage flags set. But this is the only brainpool key on my test card and it shows up for encryption in Kleopatra.

I set the pin on my card, so this still works in kleo :)
When I had not set the pin, pinentry informed me correctly that the pin was not yet set and I got as an error "Nutzungsvorraussetzungen nicht erfüllt" so this works nicely.
With faked system time I was able to sign with a vs-nfd compliant brainpool key.

So the last thing to do here would be an NTBTLS release? Then we should make sure not to forget to do that?

This would of course all be also in vsd32

So if you tested this with the signature cards this can be resolved? My signature card still has the nullpin. I should probably set that to test it myself but if you have one and tested this why not resolved?

The whole part with colorschemes and high contrast mode and dark mode I have already tested.

For testing I would take procmon, filter for Kleopatra start Kleopatra from an older version. Save the log, take the current beta277 kleopatra and do the same and compare the number of lines in the log.

Same as with T6344 this is already in beta-277

This is in vsd32. But I am not sure what to test here. You could take a previous beta and look at the startup timining debug output which says "mainwindow shown" and compare that to beta-277? The mainwindow shown timing debug output is not part of 3.1.26

This is in VSD32-beta277

Sorry @ebo tested this on Windows with 2.2. I myself should have tested it since the test is trivial and only took me about 30 seconds to type. Similar to T6701 this should have never reached the QA stage. I am including myself now that we have someone for QA that I test my own changes less. We need to talk / think about that in our whole team. We developers should test more before sending an issue into QA.

Since I did not have a valid signing cert on that dev keyring I only tested with encrypt,...

As discussed in chat has nothing to do with only signing. Only that signing makes it easier to get errors by cancelling pinentry or entering bad passwords.

I reprodcued this with a simple: "gpgtar --status-fd 2 --verbose --create --sign -u foo@bar vimfiles > foo.tar.gpg" on the command line. Which gives me the proper status lines but then ends up in kleo with general error.

I tested it some more. Gpgtar reports proper erors like:

I edited the task description.

Ok maybe because of the task description with timeout. But for a Cancel to report "General Error" that is unacceptable.

In T6575#178532, @ikloecker wrote:

The same happens when the pinentry is canceled, i.e. General Error is reported although in this case the dialog should simply be closed (because the user canceled the operation).

Then we need to kill it with fire! :) Or maybe some context is still open at the time that keeps the process alive? I could investigate on windows. But on linux it might be easier to just breakpoint kleo right before the delete and do an lsof on the file? even though on linux the deletion would likely succeed.

In T6584#177453, @ikloecker wrote:

We now use a temporary .part files when creating the archive. On success, they are renamed. Otherwise, they are removed (if possible).