To avoid additional keylistings esp. when users insist on always showing the key approval dialog we might want to consider moving the dialogs into Kleopatra so that kleopatra can be autostartet and then just bring up the dialogs without having to do additional keylistings.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.
Comment Actions
Something which has high priority but has not been touch can't have a super high priority.
Comment Actions
The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.
Comment Actions
Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.
Comment Actions
I thought about this and any change here has a regression risk and the release is already overdue. If we change this now as a band aid before a release with keyboxd we really need this only for one release.
That is if keyboxd migration is also planned for 2.6 so if existing keyrings / boxes are migrated to keyboxd I would say its better to keep the current, slow but established and robust way.
But if a keyboxd migration is not planned then this should be done. But for 3.3 I don't think that it is a good idea as this is larger. There are several things to solve for this, which is why i had not done this yet. We need a way that the output of a process called by GpgOL retuns the same as the current keyresovler form Gpg4win-tools. And since we need to change the way the windows unique service code for Kleopatra works anyway for T6331: Gpg4win: Replace GpgEX functionality through Windows registry this is related. So we need it that the wrapper blocks until the call is done by the original application and also writes the output of the call to stdout and stderr. And then we need to verify that this is really robust. Since kleopatra can be in very different states there is a ton of potential of issues if the user is actively using kleopata while the process call from GpgOL comes in. It might be no problem but it has regression risk. So I would recommend to migrate the existing keyboxes to keyboxd in Gpg4win 5 and close this ticket as wontfix as this would be another source for problems otherwise and the current code works. But if we don't want to do the migration I would then still recommend not to do this for the next release as it has regression risks and so needs to be thoroughly tested.
Comment Actions
When I last talked about this ticket I had not thought of the fact that we need to have this in some kleowrap wrapper and that currently stdout and stderr are not printed in a process which forwards its call to an already running kleopatra.