Related to GnuPG VS-Desktop.
(note that there is also a gpd to indicate GnuPG Desktop)
Related to GnuPG VS-Desktop.
(note that there is also a gpd to indicate GnuPG Desktop)
From your description it is not clear what you did exactly.
I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.
So, what is the state of this. Did a change already land in Kleopatra and how can we assure that all binaries have a W32INFO_PRODUCTNAME in their rc file?
I guess we should put this on the agenda for our next RL meeting.
Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24
I'm putting this back to triage because I cannot act on this ticket. There's way too much text and the outcome what should be done is unclear. Either rewrite the description so that it tells the reader concisely what should be changed and how it should be changed. Or, maybe better, create a new ticket referring to the discussion in this ticket and close this ticket.
In T6708#181592, @werner wrote:I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.
I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.
Sorry, it was my fault building the test installer.
To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.
Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.
The fix was not included in the Testbuid...
Does not work in Gpg4win-4.2.1-beta178
Note for myself: This is the behavior for key resolving in GpgOL. GpgEX has different code for this and the above examples will not work.
In GpgEX the group is not resolved into its component keys currently.
The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.
works, VS-Desktop-3.1.90.287-Beta
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.
Ok. With a simple group with one valid and one expired certificate it looks fine:
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
Well the checkbox is before this dialog. This dialog only comes up if you have checked sign or if your administration has checked sign for you (which they _should_ only do if they also ensure to give you a certificate). But usually this should not come up this way.
I like the explicit check boxes in the file encryption dialog more than this "hidden" combo box entry. (BTW, the file encryption dialog says "sign as" and "prove authenticity (sign)" but in this case there's little potential to confuse "sign" with email signatures. The wording should probably still be unified.)
I am mostly sure that for the majority of our users "sign" means the "signature" of the email. So the bottom text below an email so I try to avoid that wording as much as possible. It is only visible in the "advanced" sub options of GpgOL which I think should only interest people who actually know what the context "sign" means when clicking the button "sign".
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.
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.
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.
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.
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.
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.