Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.

OK. Thank you for that.

Thanks for asking. We may need to put this into the FAQ, so here is my answer:

Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.

The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.

I've added a note about this in the wiki: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

Thanks you very much for your quick reply. I added your code to my invocations for decryption and signing and all is well now. You probably saved me many hours of searching with your kind reply!

However you can tell gpg-agent to let gpg ask for the passphrase. Add

@werner I request re-consideration. I *have* read the discussion, and remain convinced that a parameter that allows shared access is necessary.

That issue is best taken up with the enigmail maintainers. If you report it there, feel free to add a link here. Thanks!

This is on purpose. Please read the discussions. Use card-timeout in scdaemon.conf or "gpgconf --kill scdaemon"

--with-fingerprint is an option to modify the output of --list-keys and not a command. There are other --with-xxxx options for other purposes. There is no command to list a keyring. This is why gpg meanwhile prints a warning when used without a command.

I don't think anyone is suggesting the use of gpg without a command. However, use WITH the --with-fingerprint command seems to be broken. Thank you for providing a correct way of doing what we want, but please either explain why the use of the --with-fingerprint command isn't working, or put this back as a bug.

The use of gpg without a command is simply wrong. This has never been specified and could actually lead to surprises.
You need to import the key first and then look at it with -k (--list-keys) or --fingerprint.

T1967: GnuPG should select a key for signing without trying to use missing subkeys and T1983: gpg2 prefers missing secret key to available key on card is related, possibly.

Sorry, merging/closing is not good. This should be a subtask of T2291.

We need to change how to access scdaemon from gpg frontend. Thus, I merge this to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)), setting its priority to High. Please continue at T2291.

Little update with latest 1.0.0 release:

– nothing new regarding pinentry-gnome3, still working nicely;
– nothing new regarding pinentry-gtk-2, but I know why it doesn’t take into
account my dead keys anymore and it’s not an issue on pinentry side;
– thanks to the new “show passphrase” button, I’ve been able to figure where the
issue lies with pinentry-qt: while invoked in the terminal, it does take into
account my dead keys, but while invoked via Thunderbird/Enigmail, it does not
(altought pinentry-gnome3 does).

So I suppose this is in fact an issue with Enigmail… Any hints on what they
could be doing wrong so that I can report this to them?

So, regarding Qt, the issue has been acknowledged
(https://bugreports.qt.io/browse/QTBUG-56452). Using IBus as suggested in
https://bugreports.qt.io/browse/QTBUG-49438, I know have dead keys working
properly in most apps. But…

Previously, the situation was as following:

— pinentry-qt4 was working everywhere.
– pinentry-qt was not working properly for me because I wasn’t able to input
some characters.
– pinentry-gnome3 wasn’t showing up in Thunderbird/Enigmail, but worked OK in a
terminal (GETPIN).
– pinentry-gtk-2 was working properly in a terminal (GETPIN), but not in
Thunderbird/Enigmail (deciphering failed, with the right passphrase obviously).

And now:

– pinentry-qt4 doesn’t exist anymore.
– pinentry-qt is as pinentry-gtk-2 was before: works OK in a terminal (GETPIN),
but not in Thunderbird (fails to decipher). Sighs…
– pinentry-gnome3 does show up in Thunderbird/Enigmail, and works correctly. I’m
currently using this one, even if that’s not totally satisfying.
– pinentry-gtk-2 doesn’t take my dead keys into account anymore.

For the last one, honestly I don’t care, gtk2 is being phased out, and it’s
probably not an issue on pinentry side.

However, the fact pinentry-qt doesn’t work correctly in Thunderbird/Enigmail is
strange. Do you think this is an issue with pinentry-qt or these programs?

In reference to that last part about having a dedicated subkey for git, I
realized that I should probably just make a separate master key. Please ignore that.

To add, why not also enable forcing a certain subkey without use of the "!"? I
figure that the only reason it's written that way would be in compliance with
the default behavior.

That way, you could make git work better with different subkeys if you wanted to
use a separate subkey dedicated to only signing git commits and tags. Both the
current and the behavior of "newest AND present" wouldn't help if you wanted to
do that, but if you could force a subkey without the "!" then you could easily
have more flexibility in choosing subkeys for git.

I personally am affected by this as well in a couple cases.

This is the topology of my keys:
sec# rsa4096/0x703E78EA22A5ABAB 2015-12-30 [SC] [expires: 2016-12-29]
uid [ultimate] JD Friedrikson (Personal Mail Server)
<me@jdfriedrikson.me>
uid [ultimate] JD Friedrikson (Gmail Address)
<jdfriedrikson@gmail.com>
uid [ultimate] JD Friedrikson (Linode Address)
<jdfriedrikson@linode.com>
uid [ultimate] [jpeg image of size 5874]
ssb rsa4096/0x60E6AFFEEC378639 2015-12-30 [E] [expires: 2016-12-29]
ssb rsa4096/0xC6C7A50DF6FC94C4 2015-12-30 [S] [expires: 2016-12-29]
ssb# rsa4096/0xC5197712F5411047 2015-12-30 [S] [expires: 2016-12-29]
ssb# rsa4096/0x4989B27BD7E45F52 2015-12-30 [S] [expires: 2016-12-29]
ssb# rsa4096/0x04B3529A021FB930 2015-12-30 [S] [expires: 2016-12-29]

I have detached signing subkeys for each device. While I do understand that I
can explicitly force subkey selection with "-u <subkeyid>!" on the commandline
with gpg2, I do not have the option when using programs that are either built as
a front-end for gpg2 (enigmail) or implement gpg in some way (git).

For example, when I try signing a commit with git this is what I get:
λ ~/test/ master* git config --global user.signingkey "0xC6C7A50DF6FC94C4"
λ ~/test/ master* git commit -a -S -m "test"
gpg: signing failed: No secret key
gpg: signing failed: No secret key
error: gpg failed to sign the data
fatal: failed to write commit object

Alright, sure we can try adding the "!" to see if we can force it:
λ ~/test/ master* git config --global user.signingkey '0xC6C7A50DF6FC94C4!'
λ ~/test/ master* git commit -a -S -m "test"
gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
error: gpg failed to sign the data
fatal: failed to write commit object

I'm relatively sure that git is having trouble parsing the attempt to force the
subkey.

And if anything else, it does not make sense to me why the default behavior
would be to reach for subkeys that aren't even in the private keyring. I get
that it's going for the newest subkey first, but maybe the behavior should be
newest AND present instead.

I'm changing this from "nobug" to "bug", because it is clearly causing problems
for people with separate per-device signing keys, or with multiple smartcards
(e.g. work and home)

I don't think this is a doc or FAQ issue, i think it's an actual bug that has a
significant effect on usability.

If gpg has an available key that would work, it should use it, rather than
preferring the unavailable key.

If the user explicitly specifies an unavailable subkey then sure, gpg should
fail. But if they've only specified their primary (or their UID) then gpg
should be willing to use any available active (non-revoked, non-expired) subkey
with the right usage flags instead of failing if an unavailable one has a newer
date.

Actually there is something more.

While using pinentry-gtk-2 in a terminal does work, it still fails in
Thunderbird/Enigmail (passphrase not recognized).

And pinentry-gnome3, that works in the terminal too, doesn’t work in
Thunderbird/Enigmail as stated before (it fails just like if set to pinentry-tty
or pinentry-curses).

So, found it why trying what you asked me for.

It has to do with Input Method. GTK3 is working because it’s the only toolkit
that properly recognize all the dead keys on my setup (some of the characters I
use are only available through dead keys). QT4 was working because of this line
in my .xprofile:

export QT4_IM_MODULE=xim

Replacing QT4 with GTK makes pinentry-gtk-2 work too. However, this seems not
supported by QT5 (the correct var is QT_IM_MODULE), because xim seems to be
obsolete so they don’t support it. But some of my dead keys are not working, so
this is most likely a bug on QT/KDE side…

And since I run a QT5 terminal, -curses and -tty don’t work.

So, I think this can be closed, and that it’s time to open/search a bug
regarding this on QT/KDE side.

if there is a behavioral change regarding the encoding a difference between qt4
and qt5 this would be a bug. Both convert the input to UTF-8, I think GTK does
too. I've just tested it and it worked.

So they should be the same. Can you provide an example test case by starting
pinentry from the command line and using "getpin"?