That it. Things works nicely for me. Won't be backported to 2.2 because this introduces minor changes in the behaviour.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 5 2021
So far -- unlike the previous patch -- this seem to help (but since the issues are infrequent I can't be entirely sure yet).
Mar 4 2021
So we now get UTF-8 argv in all GnuPG modules. Globing has been enabled for gpg using our own globing code instead of the ASCII only "int _dowildcard = 1;" mingw way.
Ingo, as you are currently working on the config dialog, maybe you could also fix this issue on the way.
Mar 3 2021
(For completeness, people don't know if there was no documentation change, so if anything strikes them as strange, they cannot say if this is because they don't have the right version of the documentation.)
Also:
org.kde.pim.kleopatra: "Backend error: gpgconf doesn't seem to know the entry for gpg-agent/Security/allow-mark-trusted"
org.kde.pim.kleopatra: "Backend error: gpgconf doesn't seem to know the entry for gpgsm/Security/auto-issuer-key-retrieve"
When opening the configuration dialog Kleopatra reports:
Backend error: gpgconf does not seem to know the entry for dirmngr/LDAP/LDAP Server
Backend error: gpgconf does not seem to know the entry for gpg/Keyserver/keyserver
Backend error: gpgconf has wrong type for dirmngr/LDAP/ldaptimeout: 2 0
Backend error: gpgconf does not seem to know the entry for dirmngr/LDAP/max-replies
The certificate selection dialog for file encryption certificates is now restricted to encryption keys of the selected key protocol. The "New..." button allows the creation of a key of the selected key protocol.
========= 0110.asc ========== # off=0 ctb=88 tag=2 hlen=2 plen=117 :signature packet: algo 22, keyid E267B052364F028D version 4, created 1614755507, md5len 0, sigclass 0x01 digest algo 10, begin of digest 4f 78 hashed subpkt 33 len 21 (issuer fpr v4 249CB3771750745D5CDD323CE267B052364F028D) hashed subpkt 2 len 4 (sig created 2021-03-03) subpkt 16 len 8 (issuer key ID E267B052364F028D) data: ADEE890B755C3B52D46FB0105097F23B5905B472C626222ACB4E441D8EB40001 data: 007119FF80C34DA152BDB07E1EF5D968CB9F2773002A0CF57911670BE248CF06 ========= 0354.asc ========== # off=0 ctb=88 tag=2 hlen=2 plen=117 :signature packet: algo 22, keyid E267B052364F028D version 4, created 1614755520, md5len 0, sigclass 0x01 digest algo 10, begin of digest 28 19 hashed subpkt 33 len 21 (issuer fpr v4 249CB3771750745D5CDD323CE267B052364F028D) hashed subpkt 2 len 4 (sig created 2021-03-03) subpkt 16 len 8 (issuer key ID E267B052364F028D) data: 001DB3839E3FD8D4CB81357EE5E42F4AF652C252A03A0FB21768621B1025C08C data: AF5A0910EF1D4D6BDD07EA0AA6D69049CB7BA7ED42427E14B8B72CF2C2231704
Mar 2 2021
Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.
fixed
I thought about this a bit regarding the search dialog.
Please test this with the Outlook plugin. It doesn't seem to be used elsewhere.
Mar 1 2021
Not many changes. Eventually a 2.2.28 will be pushed.
In T5250#143872, @kaie wrote:It seems gpgme-json is intended to execute in the Web JavaScript sandbox of a browser.
I said "we're offering the optional use of GPGME
At the time I started to add an optional binding from Thunderbird to GPGME, I wasn't aware of gpgme-json.
In T5250#141705, @werner wrote:Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging.
Hi Ingo,
@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.
[2021-02-24] gnupg2 2.2.27-1 MIGRATED to testing (Debian testing watch)
I am happy with the result, this seems very workable. Especially the Group Details dialog is a nice touch to inspect a group.
We could add compatibility mode for Ed25519 signature to conform well-formed MPI (expecting recovery).