Today
Yesterday
- gpg4win 5.0.0 @ win11
gpgme logs (also of vsd-3.3.4) will be useful.
I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,
Note: This does not happen on vsd-3.3.4
Fixed and backported for VSD 3.4
None of these certificates are for qualified signatures.
Try compare with a gpg4win 3.latest.
I create diff with implementation via VirtualLock WinAPI: https://dev.gnupg.org/D622
Mon, Jan 19
The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).
pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800:::::::: fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF: uid:o::::::::search (valid) <search@gnupg.test>\r:
gpgme.log (vsd 3.3.4):
Fixed. The problem was that the selected sections were stored in the 64-bit registry (unless browser integration was installed; see T8038), but they were read from the 32-bit registry.
Fixed.
Let's give this Normal priority.
Meh! The installation of the browser integration explicitly enables the 32-bit registry. Obviously a leftover from gpg4win 4.
Thanks for checking! So now we know why the line is missing. Looks like installing browser integration causes a broken installation (at least with respect to registry keys).
I searched the whole registry and found, that if browser integration is installed, this key still lives in WOW6432Node: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Gpg4win
Oh, surpisingly it's the other way around: if the information is given in the registry key, all components are preselected. If the key is missing (browser integration installed), only the installed components are preselected. I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.
Fixed.
Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.
Without browser integrations installed, the preselection works fine though.
Probably this happens, because the info in the registry is missing as soon as browser integration is installed, see T8038: NSIS: Updating line omitted if browser integration is installed
should properly uninstall the existing installation.
Regarding 32-bit and 64-bit installers: The installer looks in both registry trees for the relevant registry keys, i.e. 64-bit over 32-bit and vice versa should properly uninstall the existing installation.
I understood that this is done on purpose, i.e. all other components are explicitly always preselected.
gpg4win-5 has no idea that gpg4win-4 is installed because the former is a 64-bit installer/application and the latter a 32-bit installer/application, i.e. they use different registry trees. More important that the missing "Updating line" is very likely that the gpg4win-5 installer does not uninstall gpg4win-4. I haven't checked if NSIS is capable of detecting/uninstalling a 32-bit application from a 64-bit installer.
It works well for us. Thanks again.
Backports have been done in both (1.10/1.11) branches.
Sun, Jan 18
Sat, Jan 17
Fri, Jan 16
See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"
Windows7 has long reached end-of-life. Do not use it unless you have a fully air-gapped system. In this case, continue to use gpg4win 4.4.1 or resort to the command line of 5.0.0 which should still work.