Thanks for clarification. I added this to the doc enhancement ticket https://dev.gnupg.org/T7911 and set this ticket to invalid.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Thu, Nov 6
Wed, Nov 5
So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?
HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra
My point about action restrictions was to add one sentence in the docs section to clarify, what exactly is restricted then.
Allright, then the dash notation for those two groups are intended and the documentation needs to be adjusted
Note: The tab name is displayed after restart, if
- The tab was renamed manually
- The filter was changed (leading to a rename)
Mon, Nov 3
So this means, the order in the description should be implemented, right?
Fri, Oct 31
The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?
So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.
I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is
The configuration readout order still needs to be specified/fixed.
Looks good to me on vsd-3.3.3-beta90.29 @ win11
Thu, Oct 30
In gpg4win-4.4.1 it works too.
Note: In the current vsd beta (29) it works (pinentry for the next key is opened):
Note: It works with gpg-card url --clear.
Wed, Oct 29
Right, gpg CLI output depends on it, too.
PS C:\Users\g10> gpg -K --with-colons sec:u:256:19:AFC0D3F82B25E93B:1761728062:1856426400::u:::scESCA:::D276000124010304000500009D590000::brainpoolP256r1:23::0: fpr:::::::::8501CB7EF858A7CFE5E1F6E4AFC0D3F82B25E93B: grp:::::::::2675ADEF564A96F12D6E5A9B29D4FB8FE0C6D741: uid:u::::1761728062::BE090A7B8780003B05D5F193AFF64BA827F1F05B::card::::::::::0: ssb:u:256:19:23FF18B366E41CFC:1761728062:1856426400:::::a:::D276000124010304000500009D590000::brainpoolP256r1:23: fpr:::::::::6EF74BF349E0E14886C521D323FF18B366E41CFC: grp:::::::::FD28C8EC5995AF83CFBEFA10A901745318C72D81: ssb:u:256:18:8D2D2E42DF4CD03A:1761728062:1856426400:::::e:::D276000124010304000500009D590000::brainpoolP256r1:23: fpr:::::::::7253B2F829C431CD4E0A5CE28D2D2E42DF4CD03A: grp:::::::::0459891236233D2D970E3B8A08EE662E1B5D9C42: sec:u:255:22:B889A166FB44BC68:1761727895:1856426400::u:::scESC:::+::ed25519:::0: fpr:::::::::F05E296612506679B40CC2EDB889A166FB44BC68: grp:::::::::50D88C2461B477037B39367E9AB262B8DDDFF0AE: uid:u::::1761727895::C1171D48754E1CC7C9A68E7C3D4B7951925F9A8D::Has ADSK::::::::::0: ssb:u:255:18:E8DAB91AEA053CCC:1761727895:1856426400:::::e:::+::cv25519:: fpr:::::::::50BB79B5B878C769F0973247E8DAB91AEA053CCC: grp:::::::::2B5EF50EC6A1797557F1543CE1198DE67BA9F675: ssb:u:256:18:8D2D2E42DF4CD03A:1761728062:1856426400:::::r:::D276000124010304000500009D590000::brainpoolP256r1:23: fpr:::::::::7253B2F829C431CD4E0A5CE28D2D2E42DF4CD03A: grp:::::::::0459891236233D2D970E3B8A08EE662E1B5D9C42:
Tue, Oct 28
ZeitControl OpenPGP v3.4 card
Windows Language Settings:
- ISO: EnglishInternational
- Windows Language: English (United Kingdom) - note: i installed English (United States), but can't select it
- Country or Region: German
- Regional Format: German
The screenshots were made with
- ISO: EnglishInternational
- Windows Language: English (United Kingdom) - note: i installed English (United States), but can't select it
- Country or Region: German
- Regional Format: German
Mon, Oct 27
- I might want to know the fingerprints of those unknown recipients to search for them (in the audit log I can't see, which of those fingerprints are unknown immediately)
Note that currently Kleopatra (gpg4win 5 beta) fails to delete the key, which might impact other operations. I'm currently trying to figure out, if some other bugs/quirks are a subsequent error or not.
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Fri, Oct 24
Not sure, if my test covers all cases (especially regarding cache): encrypted for alice with several ADSKs (local/card, v4/v5, several algos, 1 unknown = not in keyring).
- If the cert associated with the adsk is in keyring, the userid of this cert is shown.
- The number of unknown recipients (cert not in keyring) is shown at the end.
Makes sense to me. Possible optimizations:
- I might want to know the fingerprints of those unknown recipients to search for them (in the audit log I can't see, which of those fingerprints are unknown immediately)
- The cert used for decryption could be listed first
The option is still displayed on gpg4win-5.0.0-beta395 @ win11, probably the fix is not included yet.
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks mostly good to me on gpg4win-5.0.0-beta395 @ win11.
nvda speech viewer output:
Related Addresses tab control Related Addresses tab Alt+ R Related addresses list edward.tester@demo.gnupg.com not selected
speech viewer:
Search missing keys when verifying a signature check box not checked Alt+ S X.509 Directory Services grouping Directory services list This is a list of all directory services that are configured for use with X.509.
Right, it's the same with gpgol disabled. I set it to invalid.
Sounds good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Thu, Oct 23
Tested on gpg4win-5.0.0-beta395 @ win10/win11
Mostly looks good to me on gpg4win-5.0.0-beta395 @ win11.
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Issue is still present in gpg4win-5.0.0-beta395 @ win11:
gpgol logs:
Maybe related to https://dev.gnupg.org/T7813
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11 (gpg 2.5.13).
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11 (tested with/without keyboxd, 20 keygen rsa3072 each, with/without password)
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Mon, Oct 20
that's probably at least partly another issue: https://dev.gnupg.org/T7843
Oct 13 2025
Happens on vsd 3.3.2, too.
In pgp signed unencrypted text mails it happens, too, that first the "converted to plain text" message is shown without content, and after open/close the message is gone and the content is displayed.
I can't reproduce this in vsd-3.3.90.19 @ win10 anymore.
Probably the fixes in https://dev.gnupg.org/T7827 or https://dev.gnupg.org/T7855 solved this, too.
Oct 2 2025
(removed: wrong statement)
Note: I also activated Sign/Encrypt by default, if that matters
see also https://dev.gnupg.org/T7609