No, I am not aware. I can't remember whether PGP once had such a bug because @dshaw did most cross-testing and fixing for PGP bugs. I would suggest to remove any such checks. IIRC, this was introduced by PGP 2 to speed up signature checking. 30 years ago RSA operations were quite expensive.

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

In master, I applied changes for include files which don't harm current target of MinGW-64.

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

I think we can close this issue. Ikloecker explained why. The hint comes from the help files and I think at the time I opened the issue I did not use the help messages.

Ingo, I concede it might be considered a bug on Request Tracker that it does not allow to specify the key as a fingerprint (or calculates it automatically from the email instead of relying on gpg doing it), but you generally want to keep expired keys around for decryption.

Quite frankly, if a third party application calls gpg with anything other than fingerprints to specify keys it's asking for trouble. I have changed KMail from using user IDs to using fingerprints when calling gpg more than 20 years ago.

Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

Instead of tweaking this and risk a regression for some users I added a suggested to the man page to use a fingerprint.

Unfortunately there are real world applications which make use of this option in special environments. Thus we can't remove it. I improved the warning in the man page.

There will be a 2.2.43 soonish. Thanks for the patch.

Thanks. Applied to 2.4 will eventually be merged into master.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

Thanks! We will try this out and update you with the results.

Since 2.2.20 we had these items in the NEWS

Fixed in GnuPG 2.4.4.

I upgraded to gnupg 1.4.4 now, the problem is gone. Thanks for working.

Thanks @gniibe and everybody!

Fixed in GnuPG 2.4.4.

In T6481#181779, @gniibe wrote:

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

I don't see the patch is applied. Please wait for GnuPG release 2.4.4.

Indeed, openSUSE has applied the patch: https://build.opensuse.org/package/show/openSUSE%3AFactory/gpg2

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

Works as expected on openSUSE Tumbleweed with gpg2-2.4.3-4.2.x86_64:

$ gpg2 --version
gpg (GnuPG) 2.4.3
libgcrypt 1.10.3
[...]

In T6481#181724, @gniibe wrote:

i still observe the same behavior:

What do you mean? I can't replicate the behavior described by you, using the GnuPG from the repo, or the one of Debian 2.4.3-2.

i still observe the same behavior:

In T6481#171399, @gniibe wrote:

• It is also possible for GnuPG to keep the behavior of 2.4.0, so that it doesn't confuse EasyPG.
  • This is a possible solution #2: change in master: rG2f872fa68c65: gpg: Report BEGIN_* status before examining the input.
  • But... it is difficult for implementation of GnuPG to guarantee this kind of behavior.

For a while, distributions can apply rG2f872fa68c65 for 2.4 series.

I do not think this is a very common usecase. For me regarding CMS file operations it would be more important to implement T2435: gpgsm combined sign and encrypt which I find the most annyoing issue regarding CMS file encryption.

Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.

This either requires an updated libassuan which allows "INPUT FILE=foo" in addition to INPUT FD=n" or using custom handlers in for INPUT et al. in gpgsm. I'd prefer the former. Anoter option would be to open and close the file in ggpgme and pass the fd.

Already done with rG89c7eccba51554 which will be in the next VSD release.

Note that we now have also an option instead of the workaround from 2015

It would be good to apply this to 2.2, so adding "backport" tag.

One use case that seems sensible to me is to try to convince a long-running operation (e.g. a sequence of key generations) to all use a single timestamp. In this scenario, there's no interest in setting the clock to be some variant of the current time, just an interest in it remaining fixed across all the operations.

GnuPG 2.2 and 2.4 now have --pcsc-shared option for a user who can control his action in detail.
So, closing this bug report.

Thank you for the bug report. Although it's a corner case, it is a discrepancy in the implementation which results unrecoverable situation of the device.

That was my fault in commit rG8fc9de8d6bf663f7c8419b42dab01f590a694d59 obviously I assumed that the macros were always used.

@aheinecke as promised, attached some test vectors:

This has always worked on the client site since we implemented keyserver access.

I see no problem to return only revocation packets. Clients must verify them anyway against their public keys and the fingerprint makes this easy. Verification against a primary key delivered along the revocation is more or less useless because that primary key must anyway been looked up in the client's keyring and th local existance of a primary key is anyway required to ask a keyserver for a revocation.

The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys.

Appended. Yes, it is considered an invalid signature and ignored. Anyone can insert an invalid signature. The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys. The use case here is this:

If you need the fingerprint, why don't you take it from the revocation certificate - for many years it is in subpacket 33.

In T6900#180549, @andrewgdotcom wrote:

Hi, Andre.
...

Thanks for the explanation. To me this sounds very reasonable and I think that I am starting to better understand your use case in Hockeypuck.
Having a test example key + the intended revocation update would help at least me to dig into it a bit and see how this might conflict with RFC4880.

I'm curious about the parsing implications of this bit:

Well, the quoted paragraph ended with a

Individual UID revocation sigs are not particularly useful, because they cannot be validated without the original UID. Such things are out of scope.

Hi,
so I talked to werner about this, and of course GnuPG accepts minimal revocations.
A revocation certificate. So that was my point. As he understood you, you wanted to revoke not the whole key but only a single user id but without the user id packet? Sorry I am not really the protocol expert. But for me a revoked key without any user ids sounds to me just like a "standard" revocation certificate revoking the whole key. And as said, that is well within the the Standard and accepted, and even used by GnuPG. E.g. in case of a keyrollover we attach such a minimal revocation certificate to WKD keys when we deliver key updates.

From a technical standpoint I think the most minimal revocations which are technically possible should be accepted and thus I endorse the feature request.

In any case this is technically required

Actually the public key is personalized data as much as a mail address. In any case this is technically required and users take an informed decisions when they distribute their public key to a site not controlled by them.

Just to clarify, above ticket does not reflect my Opinion. It is a direct quote from a different ticket. It is my expert opinion that a combination of "Name <email> + Cryptographic Data" is not a personalised dataset since anyone can create it. But let us please not argue about that.

Should be fixed for the next release.

Checking if the key is not otherwise used is unrelated and should be a diifferent Task since this also relates to OpenPGP. For me this Task is about creating a similar API for gpgsm (--delete-secret-key) that we have for OpenPGP.

As it is so complicated to check all possibilities:

Searching by keygrip is actually fast with keyboxd.

Actually prio is rather low or even Wontfix. Since it has been this way forever and no one really complained. I think deleting secret keys esp. for S/MIME where you can't just create a testing key but need to have it signed by a CA is not really there.

I know I discussed this with werner several times and never really understood it because it makes for an inconsistent user interface / user experience. You delete an OpenPGP Secret key and then the keyfile is gone, you delete an S/MIME secret key and then the keyfile still exists. But it has been so forever T960
Maybe kleopatra should for the very rare cases where a key is used by multiple certificates do a search for the keygrip and warn if this also deletes the secret portion of another secret key? But that would then be also true for OpenPGP.

For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.

What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

Why couldn't gpg-agent just fake these homedirs on its own?

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

I create 1000 empty files, and sign then using GNU parallel+gpg and trying various parallelization factors. (CPU used is AMD 3700X with 16 threads.)

I'm quite happy with that now. The only thing left to do would be to benchmark this, but to keep this as a an open task for that seems wrong.