Hello Eva,

The beta145 Werner talks about can be found here: https://www.gpg4win.org/version5.html
It is from our master branch which is not de-vs capable at this time.

If RestorePositionForNextInstance=false is still there after gpgpass has been quit then either KMainWindow::closeEvent() didn't run or the dirty state config wasn't sync'd to disk. When reading the code in KMainWindow I was wondering if a sync() was missing, but in Kleopatra it worked without this.

Interestingly, from this i'm learning that the patch actually *normalizes* the output so that we see the same thing regardless of ordering. the different output based on certificate order happens only in the unpatched version.

Please test without the --import keys.pgp -- just import filtered.pgp or filtered2.pgp.

Looks good, Gpg4win-5.0.0-beta145:

I can't replicate your findings here . In a test directory w/o a gpg.conf:

Hello Werner,
thank you for your support ...

Uihhh

Window is open:

with --no-sig-cache --check-sigs i get the following error with the patch applied:

This is about attachments of encrypted emails opened with the mail viewer that Carl wrote. If one opens those attachments with an external application then the decrypted attachments are written to temporary files. I don't see that this has anything to do with Kleopatra (unless the mail viewer is considered part of Kleopatra which, technically, it isn't).

@ebo: What does the MainWindow section in gpgpasstaterc contain?

QA would like to now what exactly to test here… if there is a succinct description of that in a ticket, it will get tested at the very least sooner. Or at all.

The versioninfo.txt line of 5.0Beta-145 for gpgpass is:

We investigated this a bit and it only happens when trying to sign with a non VSD key when gnupg is in VSD mode

It seems to work here on Windows and Linux

Note: Restoring the last window location is a built-in feature of KMainWindow/KXmlGuiWindow. It should work out-of-the-box if one makes sure that KMainWindow::closeEvent() is called even if it's overwritten. (Instead of overwriting KMainWindow::closeEvent() the better approach is to overwrite KMainWindow::queryClose() which is what I changed in Kleopatra.)

works with Gpg4win 4.4.0, too

Something went wrong during signing - the question is what.

Did you also tried with --no-sig-cache ? That could help to get a better insight into the reason for that difference.

OK, now i really don't know what the issue is on the 2.4 branch. trying to replicate it with and without this patch, the --with-colons output of --check-sigs appears to depend on the order in which the certificates were ingested.

hm, digging a bit further, i think the above changes have to do with third-party signatures using SHA1, *not* with expired certifiers. in 2.4.7, i see a change from % to ! for these certifications. (2.2.x, which i know is EOL) shows the difference between ? and !. I'm trying to make a simpler replicator now.

Please test using the latest gpg4win installer (beta145).

The problem is that it may take really long to read the certificates form a card and some card applications even require to give a PIN for reading the certs. A background operation may thus surprisingly lock up the box

Which other Qt applications do we want to apply this to? Okular? GpgPass?

As this is minor anyway and does not show in kf6, I close this again

For a fresh install with version 4.0.0.250370 (Gpg4win-5.0.0-beta145) all kleo config files are below %APPDATA%\gnupg\kleoaptra:

Backported for VSD 3.3.x / Gpg4win 4.4.x

I believe at least the "automatically" needs to be there.
And you can not close "this" window, really, only all future windows of this kind. If the operation was successfull…

+1 in general; Maybe slightly rephrase to "Close this window after completion"?

tested with Version 4.0.0.250370 (Gpg4win-5.0.0-beta145), works as described.

works, Version 4.0.0.250370 (Gpg4win-5.0.0-beta145)

Confirmed with version 4.0.0.250370 (Gpg4win-5.0.0-beta145), I checked only the default light mode.