I did some reworking and the outcome of the READKEY command is now (agent log):

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

Pushed to this site. Thanks for noting.

Its not used, so it can't harm.

Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.

I think we should make it explicit - this will be safer. As of now agent_write_shadow_key will do a check only in its special update mode which should be okay for now.

I can't see any explicit thing there.

That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.

I doubt that the bug is only in 2.2. The code in 2.4 is different but it may happen there anyway. It depends on the usage pattern.

(That's actually an old ticket but we still open)

Thanks for the description; this is good for documentation.

(my example cert is 0x09BB0EEE)

See T6395 for the new feature. It will be released with 2.4.1 but it will take some time that it can actually be used because the other party needs to have an OpenPG implementation which supports this.

Agreed

I think the patch is okay.

I forgot to restart Kleo after changing the contrast. Thus for the last one, we use a wrong set of icons. After restarting it looks like

FWIW:The assuan keytocard does not move the key - what you see is a side effect from unrelated code.

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.

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

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

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.

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.

Ooops: You need to put

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.

Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.

There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.

Looks similar to T6378. Can you provide the output of

Sorry, I think you have to fix the other tools. The ! suffix has virtually been supported forever and any new option to do the same complicates the code and the documentation.

Thanks. please give a few days.

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.