Forgot a screenshot:

Yes. I did only one test though, with an inline PGP mail sent with Claws.

Yes it does. I even tested it yesterday.

Looks like plain old inline PGP. Does GpgOL even support inline PGP?

POSIX specifies and requires grep -E, but only mentions egrep as old.

https://flowcrypt.com/
They use OpenPGP.js according to https://flowcrypt.com/docs/getting-started/overview/openpgp-compatibility.html
They have a cooperation with Google.

What is FlowCrypt?

Removing egrep from a Unix system will break all kind of stuff. I am not even sure whether old Unices support grep -E.

And, one more update, to fix win32 builds under --disable-npth. This is a roll-up patch that i think covers everything, you can disregard the earlier patches posted here.

Hm, we probably should avoid gpgv linking to npth as well, as that's also a sticking point in debian. This updated patch (also targeting the 2.4 branch) also has gpgv building against libcommon instead of libcommonpth, which appears to remove the dependency for me.

This patch avoids the unnecessary libassuan linkage by creating a set of stub functions to handle the keydb formats while avoiding potential callouts to keyboxd:

I tried to apply crude patches. Since _POSIX_C_SOURCE is defined when <string.h> is included (in pre-compiled source I see

That error code is actually not an error code but it is the ERROR state from the Kleo SFM. We have seen that yesterday already.

this exact case is fixed in VS-Desktop-3.3.90.12-Beta
Adding further UIDs and making more certifications still works, too.

For reference the related MRs for upstream:
https://invent.kde.org/plasma/breeze/-/merge_requests/540 (pending)

For reference the related MRs for upstream:
https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/170 (merged)
https://invent.kde.org/frameworks/kcolorscheme/-/merge_requests/43 (pending)

Very likely this bug exists since 2017 when support for promotion of local certifications to exportable certifications was added.

Fixed in gpgmepp for gpd5x. I think for VSD 3.3 we'll add a patch to gpg4win.

yeah, I did not have exactly the same setting for the tests in the different versions… so no regression

After further investigation it looks like this bug exists since quite some time.

turns out that this seems to be a timing issue/race condition and disappears if more debug output is added

Well, I could not reproduce this at any time but tested decryption with long file paths to be sure nothing broke and it worked fine.

2.2 is end-of-life

I don't see a git tag for 2.2.47 -- i think it should be on rGf27fdc0cfe4f399a0acd8a8a4268559831da5016 but if there is one, i don't see it published.

The state machine in GpgSignKeyEditInteractor expects to see GET_BOOL sign_uid.okay and it should have answered with Y.

The dialog between gpg and Kleopatra looks like this:

[GNUPG:] KEY_CONSIDERED FADC4675146CFAF3D86F137E1D3C5E6E3DB3C71D 0<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
sign
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_BOOL keyedit.sign_all.okay<LF>
N
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
uid D2C00A207DC184562E41517CBC5EF7175E8535E8
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
uid 648AC172C3EC45F85AA2E68E46D3FEFABD1F5BD7
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
sign
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] KEY_CONSIDERED FFDFEE2F0C8F278023284D90B0FBC8D8324859B9 0<LF>
[GNUPG:] GET_BOOL sign_uid.local_promote_okay<LF>
Y
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_BOOL sign_uid.okay<LF>

and then nothing else.

with VSD-Beta-3.3.90.10:

This might also be related to rGa7ec3792c5 (cf. T2982)

There is no well defined pripority for the CRL DPs. The code enumarates the DP and tries one after the other until it founds one. If you use --ignore-http_dp http DPs are skipped and with --ignore-ldap-dp LDAP DPs are ignored.

1.53 has been released this morning.

With VS-Desktop-3.3.90.6-Beta:

Note that 1.53 was released today which fixes a small regression: