Similarly if you decrypt with a PKI BW card and the mimeviewer there are also no longer problems which again might be related that the internal states where somewhat disturbed by the loop in Kleopatra.

I retested this with the current beta and It works without problems. I somehow suspect that the permanent access loop from Kleopatra caused other Smartcard operations to be canceled. Since the test setup is not really good to reproduce to for Ebo I resolved this myself.

Works on windows, too. VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

I have added a workaround and tested it on Windows. Works now for me, including T6566.

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

And it's the signals that are not found. I don't see any indication that this has anything to do with the slots/lambdas.

Well, the failed new style connects are logged for me with "QObject::connect: signal not found in QGpgME::QGpgMEQuickJob". I haven't dug into how the check works for those connects. It turns out that none of the three connects to the signals of QuickJob work (two of those connects are done in ProgressDialog). Even the connect to the argument-less done() signal. So this has nothing to do with default arguments. This is very disturbing because this means that any other connect might also be broken.

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.

works, VS-Desktop-3.1.90.287-Beta

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.

Seems T6813 blocks me from testing this. The generate window does not close and even if I abort the window, the generated key is not loaded. It is not selectable even if I remove the filter.

Does Qt log failed connections?

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.

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

Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).

This may not be reproducible on Windows for the same reasons as T6813.

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.

Fixed with the above two commits.

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

Reopened as I noticed that the last testmail had an empty body in my sent folder. And I am sure that I wrote some text. Please check.

works better than I expected. With VS-Desktop-3.1.90.277-Beta now there is no delay any more, neither after nor before the new message window

Ok closing, remaining issue is in T6813

This can be also reproduced easily on Linux with test_keyresolver from libkleo:

After reading the initial description of this, I think that might even be a yet a different bug. For which we then would not yet have a ticket. :)

The issue for that is: https://dev.gnupg.org/T6566 so I think this can be resolved here?

No it is just not properly selected after generation but it is there. I think there might even be an issue for that already. But definitely not something related to vsd 3.2

With VS-Desktop-3.1.90.277-Beta the generated key is the default RSA 3072.

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.

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.

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.

See https://dev.gnupg.org/T6685#174802

To be honest. While I get that the customer wishes for even more non standard behavior and I somewhat agree in the case of smime that it makes more sense to encrypt to an expired key.

Hello, I sen you logs.

But I wonder if we should not address https://dev.gnupg.org/T6683#176429, the text there is not changes in this Beta version.

In GnuPG-VS-Desktop-3.1.90.267-Beta-Standard it works, aside from T6805:
You do not get the new "no x509" message wrongly any more even when quickly sending a mail after restart of Outlook.
But it correctly appeares if no X509 is available.
And the message is configurable via the registry setting HKLM/HKCU \Software\GNU\GpgOL\smimeNoCertSigErr (although I do not know how to add line breaks there, but that is not important).

The observed behavior is exactly what was requested in T6743

Update: "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address. If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

This is an incarnation of T6685 while we decided to deprecate that job we did not open a ticket to do it and forgot about it. So we did not notice that it was still used in the keyapprovaldialog. Fix is to replace it there with the correct key generation job.

with VS-Desktop-3.1.90.267-Beta when trying to send a secured mail to the expired Berta X509 testkey I get the confirmation dialog but now the OK button is greyed out:

Well the icons are there. So I don't think this needs more QA.

Test version is available intern.

I think this works as intended.

Yeah there were some logic errors with this but I think I caught them all.

While I want to investigate the syntax error in URI since I don't think the testkolabs have a syntax error in their URI the behavior you are describing is completely correct in my understanding:

Hello,
I will send the logs as soon as possible.
Thank you.
Daniel

In T6775#177408, @werner wrote:

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.

Yes pretty sure about that, ok we will provide you log, thank you

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.