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.

We need more information how to reproduce the bug.

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

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

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".

Hi,

I can still see that qt[1] is using the simplified pkg macros[2], while the
configure.ac is using proprietary method[3].

We are still missing PKG_PROG_PKG_CONFIG macro in configure.ac to make pkg
macros happy, this can remove all AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
executions, see pinentry-0.9.5-build.patch, as you have PKG_CONFIG set.

The other changes to use PKG_CHECK_MODULES are optional but is there any reason
why not to use this macro instead of executing the pkg-config manually? This
macro has the advantage of allowing override via environment, and append proper
help.

If you like I can rebase this old patch set.

[1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/qt.m4;hb=HEAD
[2]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/pkg.m4;hb=HEAD
[3]
http:
//git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=configure.ac;hb=HEAD#l431

links removed as I got "Edit Error: not allowed (too many links).

Is that the gnome3 pinentry? if so please try the gtk-2 pinentry to see whether
it is the same problem.

Someone please check whether this is still the case and come up with a fix?

The Debian report is waiting since October for a reply from the orig. submitter.

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.

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.

I have now learnt how GCC uses 'undefined behavior' for aggressive optimization
and that this could break code doing unaligned accesses even on x86. So this
needs to be fixed after all.