Note: The tab name is displayed after restart, if
- The tab was renamed manually
- The filter was changed (leading to a rename)
Note: The tab name is displayed after restart, if
So this means, the order in the description should be implemented, right?
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
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.
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:
ZeitControl OpenPGP v3.4 card
Windows Language Settings:
The screenshots were made with
- 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
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).
Makes sense to me. Possible optimizations:
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
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
that's probably at least partly another issue: https://dev.gnupg.org/T7843
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.
(removed: wrong statement)
Note: I also activated Sign/Encrypt by default, if that matters
see also https://dev.gnupg.org/T7609
Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:
Looks good to me on vsd-3.3.3-beta90.12 @ win10:
Looks good to me on vsd-3.3.3-beta90.12 @ win10 (temporary filename is now attachment.odt or e.g. attachment (002).odt)