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.

Here is the output of gpg --full-timestrings --check-sigs:

pub   rsa3072 2019-05-09 12:08:21 [C] [expired: 2022-05-05 12:08:21]
      ABC96B3B4BAFB57DC45D81B56A48221A903A158B
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
uid           [ expired] Linda Mary Patricia Deborah Barbara Susan Maria Nancy <linda@example.org>
sig!3        6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [E] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [S] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]

Indeed. The called function dates back to 2004. We really need to rework this and cache the value - it might be required to take the file_name into account.

I had the same suspicion andIchecked the code. afaics all values are taken from a cache (see dirinfo.c). Thus no real overhead.

If you got a limited list of, say, fingerprints, you should put them into an array and use gpgme_op_keylist_ext_start tolist only those keys. This will be much faster.

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

These are USTAR types:

I have some doubts that signed-only archives are very useful. The only use case is that this allows to sign stuff without saving it first. You would need to do this in my generally preferred detach signature case.

Good catch. The translation of the option descriptions is done as part of the option parser (libgpg-error/src/argparse.c) and thus we need to have gettext support over there. Also for some other error messages.

Gpg4win 4.1.0 comes a slighly newer gpgol which should be tried before we continue. Set to low prioprity because this seems not to be easily reproducible.

I have no idea about Homebrew - can you figure out the maintainer and point him to here?

With 2.4.1 you will get a runtime error

sendmail tool '%s' is not correctly installed\n

It does not matter what you have in you keyring. It does not harm to have arbitrary keys there.

No idea what happens. I can't replicate that on a Linux box using GNU gettext and neither in Windows using gnupg's own gettext implementation. It seems that strings without any line feed don't get translated.

Thanks. Looks pretty standard. I will have a closer look.

Can you please provide the output of

Frankly, I don't understand the problem. Without the pinetry-program option you have a ./configure option to set the name of the pinentry. If you don't use that gpg-agent looks for $bindir/pinentry and if not found for $bindir/pinentry-basic.

Use a symlink or the alternatives systems. The --pinentry-program option was introduced for debugging.

The gpgme part has been done. Some minor changes in Kleopatra regarding the VERSION file checking would be useful.

See the the commit for a description of the changes.

Thanks. I fixed the documentation. Will go into 1.19