That version of gpg is too old that I will look at it.

MRs for reference:

I have prepared a first patch:

Note to self.

@CarlSchwan I think this one should be fairly easy to fix and I would really like to see it gone before the release, so I am tagging it for the release and raising the prio.

So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.

I need the S/MIME group if I shall look into this. Are you sure that all S/MIME keys in the group can be used for encryption? Groups containing sign-only keys (OpenPGP or S/MIME doesn't matter) are never offered for encryption. That's why we wrote T6722: Kleopatra: Forbid adding non-encryption keys to groups.

In T6701 it was reported that this also occurs if we block outlook long enough in the send event and not only if we disable the window like we do with the async encryption.

That it takes so long the first time is to be expected since we are hitting the dirmngr timeouts. I wonder though why it would be much faster in 3.1.26, if anything i would have expected that the timeouts are now shorter.

Since this is a bugfix and it was related to 6742 with some commits having overlap i decided to also pick this for the 32 release branch.

Discussed this with ebo. This is a bugfix that should be in the release even though it is multiple changes I will cherry pick them over to the release branches.

For an OpenPGP group it looks now like this:

When testing with the viktor-gnupg testcertificate I get the new warning message instead of the not very helpful "no name" error in 3.1.26.
But it takes at least 30 seconds to get to that message (the error message in 3.1.26 came up much faster). And when acknowledging the warning it again takes almost as long as before until the message is sent. And in 2 out of 3 tries the Compose Window remained open, so that it looked like the message was not send. Clicking again on Send did not make anything happen, though. And checking the mailbox showed that the mail was sent already.

That sounds very good.

We are now generating a key with whatever defaults gpg uses.

works. "archive (1).tar.gpg" is now the suggestion on Windows, too. Tested with VS-Desktop-3.1.90.267-Beta

Thanks for the reviews. And your beautiful work, by which I also mean the response to the feedback and how you managed to work with phabricator. I will commit the patch on your behalf then later.

Well in Gpg4win it actually works better :) At least there the configuration files are all in one place (or mostly, or should be). Anyway a difficult issue which I am only planning to touch when we do the migration to Qt6 since this is heavily Qt releated. But the current plan (which might change) is to do that for the GnuPG VSD summer release which will be the next feature release after 3.2.

We discussed this at length again. I would not veto a change that would allow users to encrypt to expired S/MIME certificates but the main use case I had in mind here was with regards to "Some error" happening when encrypting ( like T6545 T6398 ) . So that in the keyresolver everything is green but you cannot encrypt. Or that you have an incomplete certificate chain or an untrusted root certificate and it will take your administration some weeks to mark that as trusted. That makes this feature a bit hard to test so ebo mostly tested with expired certificates. (And I know that technically you can't verify if a cert is expired or not if you have an incomplete chain). A better test will be with a fully valid cert that has an unreachable CRL distribution point. I have such a cert and will give it to ebo. So she can test again and if that works as intended -> Key resolver green -> Error -> Allow to encrypt anyway but not vs-nfd compliant. I think we can set this issue to resolved.
The whole question regarding expired / non expired is a different topic on which, as I said, I changed my mind. You can easily explain to users "You cannot encrypt to expired certificates" but you cannot easily explain "you cannot encrypt to support@greenbone.com because they have unsupported cert extensions in their certitifcate"

I disagree. We already talked about this and we should proceed as planned.

Further investigation showed that this was due to a bogus key creating during I wrote the code.

I think that tried_password_cache in the documentation is wrong. The text:

and @code{tried_password_cache} is false

ok, then I'll add the tag for the VSD release after the upcoming one. It is of course relevant for Gpg4win also, but we do not have a dedicated workboard for that (at least not yet)

Setting back to Testing to get some more debug logs with a build that includes the latest commits.

Thanks for the update.