I have closed T4699 as a duplicate of this, even though T4699 was about simplification but IMO this is the same underlying problem.

I am downgrading this to wishlist. Even though I had worked on this a lot the regression risk is probably too high to fix this before GpgOL becomes obsolete.

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

We don't want to compile one gnupg for each desktop environment to have it hardcoded relative to gnupg but make it configurable depending on the DE used. As a fallback we could just symlink together gpg and the right gpg-agent which is rather cheap.

gpg-agent (I tested 2.4.something) looks at /etc/gnupg/gpg-agent.conf according to strace. I'm not sure why you think it doesn't, but maybe your older version really doesn't.

Thus the public key differs on wether the raw secret key or the masked (bit255 set, bit0..2 clear) has been used. And at what point in the code this was done. Shall we collect a list describing the differences of applications and on whether they have some mitigation for compatibility.

The code has meanwhile been reworked and the mentioned test server is not anymore available

Good catch. A similar problem might arise with SHA384 according to section D.R which states

One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:

These look good to me.

Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:

This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.

CV25519 private key secret part:

• Standard MPI (big-endian) of 255-bit
• The value should have zeros for least significant three bits, its most significant bit (255th bit) should be set.
  • the value should be the one after decodeScalar25519 function in RFC7748

CV25519 public part from secret part:

• Simply calculated by [secret-part]G

Thanks for the report; the regression happened due to fixing T6135.

Added curses-repeat branch which needs testing for wide chars and other stuff in case i missed something

Please use

gpgtar -C /home/matt/data ....

instead of using an absolute name. This makes things much easier to implement in a secure way: You don't want to have absolute file names in the tarball and mapping them to relative names is not easy or even impossible in case of, say "/home/foo/x.data /home/bar/x.data". Keep in mind that gpgtar does also not handle symlinks and other special files.

I guess this is fixed with this commit for 2.2. and 2.4. Given that the report is quite old with not new infos since 2019, I'll close it.

I should probably add that Kleopatra calls this command when reading a smart card to create the key stubs if necessary. Kleopatra does this since gpg4win-3.1.24 (according to the tags) and the KDE Gear 22.04 release (see T5782: Kleopatra: Smartcard unusable secret key until used via command line).

Your report lacks any useful information starting with the version of gpg you are using. Did this ever work? What did you change? Did you probably upgrade the system and have previously been using gpg1, but are now using gpg2?

I have analyzed the problem. It is caused by a serious regression in gpg 2.2: https://dev.gnupg.org/T6386

Thanks

The reason why gpg does not encrypt to multiple subkeys is that the older subkeys are viewed as deprecated. You could write a tool which does a heuristic to check when the time is reached that no more messages are encrypted to an older subkey (or are used to decrypt archived mails). At that point you can take the private part of the old subkey offline.

Debian's wiki also speaks a lot about the advantages & dream of subkeys, but also mentions the caveat:

I've read many articles mentioning the improved key handling when different devices just have different subkeys, thus allowing a semantic connection to a primary identity (instead of different "Identities" on different devices)

Ooops: You need to put

Well it makes sense to me in that KEYTOCARD explicitly is not documented but the semantics between keytocard in edit key and KEYTOCARD in agent should be the same IMO. As you can imagine I am also not a fan of the fact that GnuPG changed behavior here, but the "keep / delete" is even with GnuPG 2.3 not really an option as GnuPG might replace the real key with the stub depending on how it is called anyhow. So this is dangerous for us to "suggest" from the UI that the key will be kept and then it might be removed without actions by Kleopatra. So this must be changed.

Arguing with the documentation of a functionality Kleopatra doesn't make use of makes no sense. Kleopatra uses gpg-agent's "KEYTOCARD" command which, unfortunately, lacks a good documentation.

works if you use a valid IP address

In T6383#167887, @werner wrote:

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.

Oh sorry I only saw this now. We have "gpgme_set_offline" for this use case which disables CRL checks in the S/MIME case. It is more general because it also disables OCSP for example and might disable more online actions like fetching chain certificates etc.

So as I understand this:

Okay, gpg2 --card-status is accessible using sudo/su.
But I still don't know why bumping from 2.2.41 to 2.4.0 the use of pcsc-lite + ccid stopped work.

I can't access even trying using root.
pcsc-lite was already installed. I tried using disable-ccid-driver as advised but didn't help, scd.log don't even get written using this option.

Ready for testing. In case of a file name conflict the users are now offered to Overwrite the existing file or to Rename the new file (i.e. save it with a different name). If multiple output files are created (e.g. when encrypting multiple files separately), then the users are additionally offered the options "Overwrite All", "Rename All", "Skip", "Skip All".

What do you want to achieve by using multiple encryption subkeys? Do you realize that gpg will always encrypt to one subkey (unless you explicitely specify multiple subkeys), i.e. you won't be able to decrypt on device 1 what you have encrypted for device 2 and vice-versa. Usually, this makes little sense because it seems you want to be able to decrypt anything on your main machine.

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.