I added my script to find icons, used in our packaging file. It is extremely stupid as it just greps the source for each icon and takes quite a while but it works for me and I can simply run it in the background. This was just a hacky "worksforme" solution, and we probably want to do it differently. Using a single expression for all the icons would already be a large improvement but I just did not care about that. It also does not really generate the -inst files and requires manual work. But since we probably will do it differently in the future anyway I just commited what I have right now. It does not take care of icon removals and so on. So we might need something with a bit more development put into it.

On a related note in T6645 it was raised that it is currently impossible for the user to see if an exported group only contains local signatures which might decrease the value of the export and not be the intention of the person doing the export. Maybe we should combine a check for that with this feature so that you are asked when exporting a group if you really want to confirm all these identities.

Thinking about this, I don't think offering the information exportable or not will help users much. The concept of "exportable or local signatures" should be a technical details that we should not require our users to understand. The intention of defaulting to local signatures and hiding the export under "Advanced" was to give users a way to basically use "Trust on first use" to certify a key for their personal use and honestly without checking the fingerprint. Even though they "should" not do that. If this makes sense for GnuPG VSD is arguable since we have now better spelled it out what "certification trust (ownertrust)" means. So maybe exportable signatures should become the default for GnuPG VS-D? With the classical SKS style keyservers in Gpg4win I tend to keep local signatures the default.

Well better to wishlist this. As a user might still import a bulk of S/MIME certificates.

Yes this is no longer required since we use a script now.

The changes have been merged and will be part of KDE Gear 23.12.

I thought about adding support for deleting multiple attachments via the Message Structure view, but as Ingo said, it's marked as an "Expert" tool and it is not enabled by default so most users are not even aware of it, and it would actually be difficult to do it with a proper UX so I decided against it, unless it's explicitly requested by someone again.

Closing. For now, all that's needed has been added to GpgME. Additional changes in Kleopatra are tracked in T5903: Kleopatra: Add refresh button in certificatedetails . If further changes in GpgME are needed, then a new task will be opened.

We have no dedicated error to tell that the verification failed due to an non-compliant algorithm. Thus we return invalid public key algorithms as best approximation. You could use --override-compliance-check, though. We discussed things thing once at the Gutenbergweg.

In T5903#157763, @ikloecker wrote:

Please add a separate task for an automatic refresh.

Mmh, ok this does not seem like a regression, at least if I go back to one of my oldest appimages with 3.1.21 I still get ERRSIG.

Since I am not sure if this was really a problem in the first place I resolve it directly.

Yes, I remembered that too when I encountered it in a different place.

KDECompilerSettings now sets -DQT_NO_CAST_FROM_ASCII (and others) also on Windows because we increased the required KF5 version to 5.104.

The data is indeed corrupt. Check with the sender of that key.
IF you look at the data you will soon notice that one line is longer than the others.

Not really, the GnuPG System configuration settings are generated from gpgconf output and there is no tooltip mechanism for that.

Yes I agree, that might be nice to have.

Yes I think that can be safely backported to gpg4win/23.07

Yes I think that can be safely backported to gpg4win/23.07

we could include the "better explanation" part, though. The options in "GnuPG system (technical)" do not have a tooltip, we could add one there, at least.

This won't go into the next release it is too invasive and needs to be very thought through and announced to users. This also needs to be deployed in a Gpg4win first to get user feedback. GpgOL is pretty much done for the summer release of GnuPG VS-Desktop.

I caught gpg-agent.exe hanging again and managed to attach WinDbg for live kernel debugging. Alas, the result is underwhelming, but I can now confirm with certainty, that the WOW64 loader lock and the fast PEB lock are not being held:

Please ask on the gnupg mailing list for support. In case that turns out to be a real bug, please re-open this bug.

Here is an example from my QES cert:

That does not mean that this is a good idea. And well, I heard that Poppler does not have a stable API.

Thank you. that worked. A pitty gpgv can't read from fd using process substitution

7b7e16ae923d:/data/loglib# gpgv --keyring <(gpg -o - --dearmor ../ecs.keys) jul-ecs-formatter-1.5.0.jar.as
c jul-ecs-formatter-1.5.0.jar
gpg: WARNING: unsafe permissions on homedir '/root/.gnupg'
gpgv: Signature made Sun Aug 21 07:52:24 2022 UTC
gpgv:                using RSA key 46095ACC8548582C1A2699A9D27D666CD88E42B4
gpgv: Can't check signature: No public key

But I had two steps even before, so this could work.

7b7e16ae923d:/data/loglib# gpgv --keyring ../ecs.keys.gpg jul-ecs-formatter-1.5.0.jar.asc jul-ecs-formatte
r-1.5.0.jar
gpgv: Signature made Sun Aug 21 07:52:24 2022 UTC
gpgv:                using RSA key 46095ACC8548582C1A2699A9D27D666CD88E42B4
gpgv: Good signature from "Elasticsearch (Elasticsearch Signing Key) <dev_ops@elasticsearch.org>"

gpgv might not support ASCII armored key files. Try with a binary key file.

The poppler api exposes it. Has done it since more or less the incarnation of pdf signing in poppler I think.

Don't do that. The key usage extensions rarely useful. This is the usual X.509 DbC (design by commitee) mess. See for example https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt . Let's not try to follow this path.

Hi, thanks for prompt response. I have just bunch of public keys I want to verify against. They have form of
-----BEGIN PGP PUBLIC KEY BLOCK-----. If I try using the key file as a keyring I get error.