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.

This is a generic parent task and does not require workboards for specific branches.

Applied to 2.4, too.

To align the documentation of GnuPG, we should not use GNUPGHOME in FILES section.
It may be controlled by --homedir as well as GNUPGHOME.
GNUPGHOME is addressed in the ENVIRONMENT section, so, I don't think it makes sense using $GNUPGHOME}/trustedkeys.kbx.

Thank you. Applied and pushed in: rG260004747016: gpgv: Update used keyrings in doc FILES section

Same as with T6344 this is already in beta-277

That's right: -K is merely a -k which prints only keys which have at least one secret key or a stub key (for smartcards) available.

So as a replacement for what we have in Kleopatra this would work.

So with my ryzen 9 on tumbleweed:

thanks for your reply
gpg -K
gpg: enabled debug flags: memstat
/home/usernet/.gnupg/pubring.kbx
uid [ absoluta ]
uid [ absoluta ]
ssb cv25519 2022-02-13 [E]
gpg -h
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

It is a bit hard for us to decipher the Spanish diagnostics. Before we can try to help you please update to a deent version of gpg and libgcrypt. At least the version for Ubuntu is way too old; Libgcrypt is 5 years old, the current version of the lTS branch is 1.8.10. GnuPG is also 10 years old and in the mean time we have fixed several critical bugs; the current version of this legacy branch is 2.2.41! Note that Ubuntu might have fixed some bugs despit ethe version number - we just can't know.

For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

The tobias/gpgsum branch in gnupg now contains my implementation of this. Together with the attached patches to kleopatra and libkleo, it can properly handle unicode filenames on windows. I'll put those patches up for review at KDE in the next days.

Looking at sign_file I can see several places though where it does goto leave before gcry_md_open is called on md. So the fix seems obvious to initalize md to NULL so that the gcry_md_close in the leave part does not work on an uninitialized variable.

gpg (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
gpg -z0 --yes --batch -esu ldata-test -r ldata-test 10gb-random.dat > 10gb.gp 13,37s user 22,54s system 95% cpu 37,421 total

If you tested it yourself I would say this is enough to move such a task to resolved. If someone else should test it you should remove yourself as the assignee. I will test this by comparing 2.4 performance to master. We need to clean up the WIP tasks in our workboard.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

Ah nevermind missing icons were related because I also removed the highcolor icons for testing.

Mmh, on further checking I notice that some icons are missing though. Need to investigate where they went. I basically just took the inst-breeze.nsi file, and removed all the NSIS things and did a sort -u on it to create the list of icons.

So, I smashed this all together. The icon subset and the cross compile patch, and my time for first startup was 5 seconds then once with procmon enabled 7 seconds and now with a reduced set of icons I am down to Kleopatra to 1.7seconds. The icon subset is just 1.4mb. With all the icons we would have installed for Okular and Kleopatra. I don't have enough time to clean this up today to push it but this looks very good.
Although I am thinking to add a way to kicontheme maybe as a global variable to provide the name for the resource file so that we can properly switch between breeze-dark and breeze.

I am wondering a bit about the gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> which is not the string I expected for this error:

Changing debug options unfortunately didn't change much.

works

Here's another data point.

Lot's of things changed in the meantime.