Works, tested with VS-Desktop-3.2.94.474-Beta

The layout is totally different now in VS-Desktop-3.2.94.474-Beta but the "generate new key" action is now hidden for the slots (while still there in Gpg4win 4.4).

There's the VERSION file that is used for customizing the About data for VSD and GnuPG Desktop. It's an ini format file that's read with QSettings.

Doing the changes to the text is easy enough, but I'm not sure whether we have a nice way of doing something only in a VSD version.

The changes hat to be reverted, a working solution is planned for later

Looks like there's something not correct in the completion model. Or we use different criteria for showing the blue "i" (as "information") which doesn't make it better. Reopen?

This is long done, but only for Qt 6-based releases. Andre's comment T6663#175481 has also been addressed.

Tested Gpg4win 4.4:
Interesting, when you search for the UID, it looks as before, with the green check mark:

I think this is resolved. In the Sign/Encrypt dialog we now offer the individual user IDs instead of the certificates, i.e. the two user IDs of the Udo certificate are both offered and one should be listed as certified and the other one as not certified (if one is certified and the other one isn't; for me both user IDs are ultimately trusted).

I suggest to make the following text changes for the VSD versions only:

This might fix the issue https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=commit;h=cf13e915581ca32e05e229cc54ef8e35753128e0

Gpg4win-Beta-75:
Checked the property details of some files in "Progams (X86)" and found several without product name, E.g. libgpg-error-0.dll and other dlls located at C:\Program Files (x86)\GnuPG\bin.
Or gpgolconfig.exe at C:\Program Files (x86)\Gpg4win\bin and the examble from above, libKF5JobWidgets.dll, shows no product name either.

This is now merged into master

After recompiling, it works!

I backported the work of Andre for qt6 to master/kf5. It's in the branch work/carl/product-name-kf5

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

gpg4win-Beta-50:
Columns are now displayed as expected with a fresh installation, too.

That was resolved with vsd 3.2.0

Without administrator rights it does not work for me, since it then cannot write to %PROGRAMDATA% to install the VS-NfD mode config files. But the only thing for "does not work anyway" that I know and could quickly see is that "IPC connect call failed" problem with GPGEX (which we are planning to remove / replace anyway). So I don't think it is very important to remove this and addtionally we do not know if this is something that is used, we have offered it from the beginning but have no data if our customers use it. We can suspect that we would have seen more support questions about the gpgex error if it was widely used. But I always thought that the "only for me" installation option was useful for some use cases.

I think the executables also use the same values for translation.

Okay, I see now that this is US-English and Unicode.

Okay. let me do that for the next library releases.

The additional changes have been backported for VSD 3.3

To clarify what I mean by the missing VarFileInfo block. Currently the GnuPG binaries have versioninfo.rc files but only the version number is displayed for dlls as their pattern did not have the VerFileInfo block: The libassuan-0.dll displayed in this screenshot is from the 2.2.43 package and the assuan-9.dll is self compiled but including the patch below that. I would like to commit such a patch to all libraries that require it if that is okay with you.

I added some comments to the commit. But

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.

Phew. Got it. a new script: "gccwrap.sh.in"

fixed in https://invent.kde.org/pim/kleopatra/-/merge_requests/243; we were not calling the visibility logic when initially creating the view.

I have to correct myself. After restarting Kleopatra, only the following columns are shown, without any changes from my side:

On a fresh install Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35) are now all available columns displayed by default:

Tested with Gpg4win-4.3.2-beta23:

Please, we need a fix here for 3.3.

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

• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

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