restarting gpg-agent works in release version 3.2.2

Backported to VSD 3.2

We decided the latter is to small an issue, we'll close this ticket without opening another for the reverse case.
Tested only in VS-Desktop-3.1.92.39-Beta yet

I don't see a problem here. Of course Kleopatra could run a gpgconf -K all when it really exits but I doubt that we need to do that in this special elevated case

yes, the box comes up, the second "user-level"-Kleopatra exits again after clicking the "ok" Button.
After quitting the Kleopatra process with the admin rights again the privileged background processes remain, like I mentioned in https://dev.gnupg.org/T7050#184583.

Yes, the kleopatra.exe process ist shut down for me with that version, too.
But I wonder if the remaining gpg-agent and scdaemon processes which remain may cause issues later on. The are still running with elevated rights according to the process explorer after restarting as normal user. It does not cause any immediately obvious issues, though.

ok, then I set this ticket to resolved, as it now works in version VS-Desktop-3.1.92.39-Beta as far as in Gpg4win.
That is only the "Refresh Keys" does not work yet. Which we now track in the above mentioned Tickets T7036 and T7037

works for latest VSD Beta, too (VS-Desktop-3.1.92.39-Beta)

Works for me using the latest vsd beta (3.1.92.39)

Done and backported for 3.2.

Sorry I just noticed that I mixed up the duplicate closing. I wanted to close 7050 as a duplicate of this and not the other way around. Since this description was more general and better.

Just to triage this

In T6761#183780, @ebo wrote:

But in the case "Refresh OpenPGP keys" (in Kleopatras certificate Details) there is no error message but instead ~"the key is unchanged".

with Version 3.2.2.231170+git~ (Gpg4win-4.3.1-beta12):

• no error message any more with keyserver = none
• correct error message when choosing "publish on server"

But in the case "Refresh OpenPGP keys" (in Kleopatras certificate Details) there is no error message but instead ~"the key is unchanged".

Version 3.2.2.231170+git~ (Gpg4win-4.3.1-beta12): works, when entering a mail address the search result is presented very fast now. When entering only a name, nothing happens. So functionality is there, the improvement in UX is T6493.

I have backported the commits to gpg4win/23.10 for VSD 3.2.

I have backported the relevant commits to gpg4win/23.10 for VSD 3.2. I left out the commit that adds a tooltip.

For VSD there should at least no info message be shown - which has to be clicked away - when keyserver is set to "None"

It does not matter how many gpgsm instances try to start a daemon. The same code is used for starting and this code first takes a lock. When using gpgconf --launch the same code is used too (indirect by calling gpg-connect-agent NOP /bye wityh options for the respective daemon).

Works in VS-Desktop-3.1.91.9-Beta.

In a first commit, I have switched back to the simple check done by QFileInfo::isWritable() (see https://doc.qt.io/qt-5/qfileinfo.html#isWritable).

Another hint: When they checked "write temporary files in the folder of the encrypted file" they got a message window from gpgex "Error returned by the GnuPG user interface: Input/output error".

can be tested with beta312

Damn this actually happens with every file with a space. Why didn't our Gpg4win users,.. report this. 😐 I checked T6056 was part of the last Gpg4win release...

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

Oh, the user is actually asked with this? I wonder if that is something that is new now, I think so. I mean its been quite a long time that we added support for embedded filenames but 3.1.26 was also long ago.

assuan_pipe_connect, etc., is outside of my comfort zone. Somebody else (@werner ?) should check how to prevent two gpgsm's started via gpgconf --launch and assuan_pipe_connect (if that's what happens).

fixed in beta302

Fixed in the according repo. The sentence structure made it easy to just replace the word README with pkg-licenses.txt

Ah, forgot about the license text in the installer, I hope that I can do an easy search and replace.

I guess that the second instance is started by gpgsm_new (engine-gpgsm.c) via assuan_pipe_connect.

When I do a search which is found on the keyserver, only the one without the multiple backslashes comes up, this seems to be started via gpgme call.
When starting again without a dirmngr and searching for a key which can only be found via WKD both entries appear in the taskmanager after only one search. The same is true if the key can be found in neither place. It seems the backslashes are associated with WKD and start is probably via gpgconf.

further improvement after the 3.2 release

One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.

I can confirm this

I can at least confirm that in VS-Desktop-3.1.90.300-Beta a file pkg-licenses.txt is included, as mentioned in the about dialog.

With VS-Desktop-3.1.90.300-Beta I do not any more see more than one dirmngr for the test user who is not in the windows test-domain.
But I still see 2 processes for the domain user. Which is less than before. Task manager for all users:

Fyi, Carl already, asked me to include that in our build so I will add this.

In T6832#179438, @ebo wrote:

VS-Desktop-3.1.90.300-Beta: The executable is now found.
Therefore now the details of the signing key are listed when clicking on "keys".

But the keys for which the message are encrypted are not listed after clicking on "Details" in the first blue frame.

After clicking all "links":

The "Load Certificates" button still remains greyed out if nothing changed, i.e. if no new certificates could be loaded from the card. This could be changed, but pressing "Load Certificates" multiple times won't magically fix loading the broken certificates.

Should really work now.

Looks like ReaderStatusThread assumes that the data for the card didn't change. Therefore the card view is not updated (as before the changes for this issue).

Aha, the certificates are listed in the certificate view, though. And when you remove the smart card and re-insert it the keys are then listed without having to press the "load certificates" button.

For the X509 brainpool test cards I used it does not work in VS-Desktop-3.1.90.300-Beta . After clicking "load certificates" the button remains greyed out:

VS-Desktop-3.1.90.300-Beta: The executable is now found.
Therefore now the details of the signing key are listed when clicking on "keys".

In T6839#179343, @aheinecke wrote:

Wait,.. I misunderstood this issue B81CE112B26A8EA8BE7B95D2E375339BF4C51840 has no encryption subkey o.O

I created T6842 for the "Cleaning Kleopatra directories on startup" so that we can close this task once ebo confirms that all is fine. Usually I would close this task myself since I already tested it. But well we have QA now ;-)

Works nicely for me in beta300

I'm quite happy with that now. The only thing left to do would be to benchmark this, but to keep this as a an open task for that seems wrong.

So this is done now to my liking. I took the pkg-copyright from GNUPG as a baseline at the top and then went through all other packages. It is mostly about licenses though and not about copyright holders, even the license information for some packages was weird to figure out. Let alone the individual copyright holders. So I don't think we can or should say "The list of other copyright holders". I changed that now "For a complete list of licenses see: "

Looks good now

This now works to my liking.

I read the documentation (and stackoverflow) as owner we have to close our handle before deleting the file. With FILE_SHARE_DELETE we only ensure that others must live with the fact that we can always delete the file, but since we hold an exclusive READ right (which we gracefully share with others) our handle needs to be closed. So the trick was just to CloseHandle first and then the file could be deleted.

Wait,.. I misunderstood this issue B81CE112B26A8EA8BE7B95D2E375339BF4C51840 has no encryption subkey o.O

New MR: https://invent.kde.org/pim/libkleo/-/merge_requests/61

MR for this: https://invent.kde.org/pim/libkleo/-/merge_requests/60/

Or you use a Cleaner like the one I added to QGpgME: https://dev.gnupg.org/rM278f92b189ece58dee2036450ac029e3599fdb1f

It might also depends on the file type as I wouldn't be surprised if for example the photo viewer opens the file differently than the text editor.

I tested it and for me the files are not deleted:

Since I have such a test card, I just tested it and the issue is indeed gone.