I'm having trouble decrypting some mails. I use an encryption sub-key with a
unusual length of 3104 bits. I described my problem in the gnupg-users mailing
list and there the following problem was identified:
<quote>
I think that it is deterministic; The cause is that the RSA keysize is
not the one in the set of: 1024, 1536, 2048, 3072, 4096. When data to
be decrypted is padded, scdaemon can't decrypt, I suppose.

I am not sure the exact reason why scdaemon only supports limited set of
keysize for encryption. But we have this handling of padding in the
current code:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=scd/app-openpgp.c;h=71c9e1b83003af07b0984688ba1ec5e9013b877c;hb=refs/heads/master#l4334

       /* We might encounter a couple of leading zeroes in the
          cryptogram.  Due to internal use of MPIs these leading zeroes
          are stripped.  However the OpenPGP card expects exactly 128
          bytes for the cryptogram (for a 1k key).  Thus we need to fix
          it up.  We do this for up to 16 leading zero bytes; a
          cryptogram with more than this is with a very high
          probability anyway broken.  If a signed conversion was used
          we may also encounter one leading zero followed by the correct
          length.  We fix that as well.  */
       if (indatalen >= (128-16) && indatalen < 128)      /* 1024 bit key.  */
         fixuplen = 128 - indatalen;
       else if (indatalen >= (192-16) && indatalen < 192) /* 1536 bit key.  */
         fixuplen = 192 - indatalen;
       else if (indatalen >= (256-16) && indatalen < 256) /* 2048 bit key.  */
         fixuplen = 256 - indatalen;
       else if (indatalen >= (384-16) && indatalen < 384) /* 3072 bit key.  */
         fixuplen = 384 - indatalen;
       else if (indatalen >= (512-16) && indatalen < 512) /* 4096 bit key.  */
         fixuplen = 512 - indatalen;
       else if (!*(const char *)indata && (indatalen == 129
                                           || indatalen == 193
                                           || indatalen == 257
                                           || indatalen == 385
                                           || indatalen == 513))
         fixuplen = -1;
       else
         fixuplen = 0;

Perhaps, it was due to support all existing OpenPGP card
implementations, I mean, somehow historical, and it was easier to list
up specific keysizes.

This should be fixed.
</quote>

I also attached to log-files of the scdaemon. One for a successful and one for a
failed decryption attempt.

Please let me know if you need any additional information.

The unnecessary PTR lookup is causing problems for other people too, over on
https://bugs.debian.org/854359

I agree about that race condition being an important thing to consider, but i
think it's orthogonal to whether the process is self-terminating.

That is: we need to consider that race condition even in the case of deliberate
shutdown too, right?

Do we have a test case that involves two concurrent processes, one that tries to
stop the agent, and the other that tries to access it?

So I believe that if we have a test that demonstrates this problem, then it is
safe to set the status to resolved.

Fixed in 6823ed46584e753de3aba48a00ab738ab009a860.

I can reproduce this. Our test indeed feeds a passphrase to the agent.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

Here's the make check verbose=2 log for 2.1.18 on macOS 10.10.5 Yosemite:
https://gist.github.com/ilovezfs/d9de58955697858a1eb3c6d3a5e48bea

And ssh -V:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

I feel that this is the very same issue as T2847

I assumed they were different issues since this is ssh-import.scm and that was
ssh.scm.

I asked what version of ssh you were using over there, and sadly you

did not react.

Sorry

One thing to look out for is a race condition between the agent deciding to shut
down, and a client trying to connect at that time, and that might lead to
intermittent failures. It may be doable correctly, but it is something to look
out for.

The other point being raised in the bug report about older daemons hanging
around over package upgrades should be discussed in a different bug. Yes,
shutting down the daemon when idle may work around this issue sometimes, but
clearly this is not a robust solution.

Yes, your version of OpenSSH does not seem support elliptic curve cryptography.
I feel that this is the very same issue as T2847, could you please revisit
that bug? I asked what version of ssh you were using over there, and sadly you
did not react.

I guess we need to figure out what kind of algorithms are supported, and skip
the ones that are not.

Additional findings. If I depend on homebrew/dupes/openssh (which is not
actually permissible in homebrew/core, but just for the sake of testing this
here), then the test passes. The homebrew/dupes/openssh formula is 7.4p1, so
this bug appears to be specific to 6.2p2 (possible all of 6.2 or all of 6.x?)

Note this is

yosemitevm:brew brew$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

Sorry: to clarify my previous remark: i don't think gpg should change from its
current behavior during *encryption*. I do think it should be more constrained
in its output during *decryption*.

I don't think it's a problem that the files created during encryption simply
obey the umask.

I do think that when gpg creates sensitive data, though, it should limit the
mode of its output to the mode of its input (filtered by the umask, of course)

if the mode of the input is INMODE, and the umask is UMASK, during decryption,
when gpg creates an output file, it should set the mode to (INMODE & ~UMASK).

(if gpg is decrypting and sending output to stdout, perhaps it wants to try
fchmod (1, INMODE & ~UMASK) as well?)

well, it looks like i stand corrected: the problem happens both in encryption
and decryption. i *meant* to post about decryption, but i only pasted the setup
part... :p

[1012]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1013]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1014]anarcat@curie:~$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw-r--r-- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg
[1015]anarcat@curie:~$ chmod 600 foo.gpg
[1016]anarcat@curie:~$ ls -al foo*^C
[1016]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1017]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1018]anarcat@curie:~$ =k^C
[1018]anarcat@curie:~130$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw------- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg

I've tested Simon's patch against 2.1.18, and i think it's the right thing. I
posted it to the mailing list in git-format-patch form here:

https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032547.html

Any progress on this?

A reproducer, even without smartcards (please ensure that GNUPGHOME is
explicitly set):

ARGS="--pinentry-mode loopback --passphrase abc123"
ARGS="$ARGS --batch --with-colons --with-keygrip --status-fd 3"

gpg $ARGS --quick-gen test@example.org rsa cert 3>genkey.status
FPR=$(awk '/KEY_CREATED/{ print $4 }' < genkey.status)
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-1.status
sleep 5
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-2.status
GRIP=$(gpg $ARGS --list-keys | grep ^grp: | cut -f10 -d: | tail -n1)
mv $GNUPGHOME/private-keys-v1.d/$GRIP.,bak
gpg-connect-agent killagent /bye
echo test | gpg $ARGS -u "$FPR" --clear-sign

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Any thoughts or progress on this?

By the way, I've noticed that communication with the card will only be broken
upon reinsertion if some software has attempted to access the card while it is
detached.
In other words:
access card -> remove -> insert -> access card
is fine.
access card -> remove -> access card -> insert -> access card
will cause all accesses to fail after insertion until gpg-agent is killed (and
restarted obviously).

the reason "no public key" is confusing is because gpgv already knows that there
can be no public key. So the message that the naive user needs to see in this
case is "no keyring available".

If there is at least one keyring available, then saying something like "no
public key found in keyrings X and Y and Z" is reasonable. but if there are no
keyrings at all, the message should just be something like "no keyring found to
validate signature against".

Thanks for this work (and sorry to have just blindly/wrongly assumed that
--no-use-tor already existed without checking it).

On modern debian systems, the default tor daemon will always be listening on
unix domain socket /run/tor/socks. So a simple attempt to connect to that
socket should be sufficient -- it should fail immediately if the socket isn't
present or if no one is listening on it.

This seems cheap and fast enough to be able to do it on every query to me,
rather than introducing additional runtime state to dirmngr. just try to
connect, and if it doesn't work, fall back to a normal connection (you'd want to
do that anyway in case the tor daemon goes away after dirmngr had been launched).

That doesn't seem all that large in the modern era, but okay. In any
case, after moving it to the backup file, don't the same number of bytes
need to be written into the new file anyway? And, regardless, how can
something be done to facilitate pubring.kbx sometimes being a symlink then?
Perhaps an option so the choice of move vs. copy can be left to the user?

--Kyle

I'm curious. So what was it about this particular key and signed text that caused this
to expose this error while others did not?

Here is the output from the program you attached running on OS X Sierra and compiled
with gcc. Is it what you expected?

$ ./a.out
0 => 0; tail = ''; errno = Undefined error: 0 (0)
1 => 1; tail = ''; errno = Undefined error: 0 (0)
=> 0; tail = ''; errno = Invalid argument (22)

Sorry, forgot the reference for [1] previously:

https://bbs.archlinux.org/viewtopic.php?id=222401

I can also confirm that adding the line "disable-ccid" to scdaemon.conf appears
to revert to the previous system, which then works fine (but doesn't really fix
the issue).

Having read [1], I double checked my scdaemon.conf (which apparently already
featured debug-all) and made sure it to read as follows:

log-file /home/mike/.gnupg/scdaemon.log
debug-all

I got the following from attempting to run gpg --card-status:

2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 <- GETINFO version
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 -> D 2.1.18
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 -> OK
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 <- SERIALNO openpgp
2017-02-02 18:00:58 scdaemon[32091] DBG: apdu_open_reader: BAI=10a02
2017-02-02 18:00:58 scdaemon[32091] DBG: apdu_open_reader: new device=10a02
2017-02-02 18:00:58 scdaemon[32091] ccid open error: skip
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 -> ERR 100696144 No such device
<SCD>
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 <- RESTART
2017-02-02 18:00:58 scdaemon[32091] DBG: chan_5 -> OK

Please let me know what further information I can provide to help debug this?

This should be fixed by 407f5f9baea5591f148974240a87dfb43e5efef3 .

Thanks for reporting this!

According to SUSv3:

If the subject sequence is empty or does not have the expected form, no

conversion is performed

...
If no conversion could be performed, 0 is returned  and errno may be set to

[EINVAL].

  http://pubs.opengroup.org/onlinepubs/007908799/xsh/strtol.html

It appears that MacOS X sets errno to EINVAL, but glibc doesn't.
(The attached program should expose the behavior; I haven't run it yet on Max OS
X, but I'd be interested in the result.)

The underlying problem is that bindings for ultimately trusted keys were not
registered with the TOFU data.

Fixed in 769272ba87f282a69e8d5f9bb27c86e6bec4496b

This should be fixed in 027b81b35fe36692005b8dba22d9eb2db05e8c80.

Copying pubring.kbx to the backup file is not an option because keyrings tend to
get very large. Several dozen megabytes are quite common.

Okay, that first part has been pushed. Now need to figure out how to test for
Tor in a clean way.

I will do some rework to make testing for tor easier ....

I think this is a good idea. If Tor is already running we can expect that the
user wants to use Tor as much as possible and thus tehre should be no need for
any configuration.

I do not think that we need a new option (except for making --no-use-tor). To
avoid checking for tor with every new connection to Dirmngr, I would do a test
at startup and after each reload.

To be clear the initial output is not wrong. At the time the information is
initially requested, the message has not yet been processed.

Anyway, I think I'm working on a fix so this is a non-issue.

D407: 947_gpgsm.c.diff

thanks for the quick fix, Justus. I can confirm that this fixes the problem for me.

Fixed in 3f4f20ee6eff052c88647b820d9ecfdbd8df0f40.

That is no regression, that never worked well. It only works if one uses a uid
like 'test <test@example.org>'. I'll fix this.

That is a regression - it used to work since every early gpg versions.