This is a fidesmo privacy card with the yubikey applet installed. Therefore the second reader.

I have added this note to the description of the tsign command in the gpg man
page from master (2.1). Won't be changed for 1.4.

+ or groups. For more information please read the sections
+ `Trust Signature'' and `Regular Expression'' in RFC-4880.

(domain means the domain part of the mail address).

Please describe exactly what you did.

You are using a Yubikey token which makes me wonder why there is another reader
given.

Removed from doc with commit d877528

With GnuPG 2.1 and a recent ssh versions you can keep the private key on the
local machine but use it on the remote machine for decrytpion or signing.
Checkout --extra-socket in the gpg-agent man page. This is not possible with 2.0.

Fixed in 02cf135.

What happens is that the header length is taken from the public key in the
keyring. For the 1024 bit RSA key it happens that the public key is encoded
into an packet of length 141 bytes, a length that can be encoded in one byte.
The secret key however is significantly larger.

I see no benefit in using the stored length, and the fix is letting
write_header2 figure out the required length on its own.

am using cygwin and script cmd's

Hi Justus,
my report describing the problem, not proposing a solution.
(I think that most report should describe the issue,
so that good solution ideas can be measursed against how could they
solve this and other problems.)

If there is no technical reason to have --faked-system-time
in 2.0.x, I guess that fixing the documentation is the easier solution.

Possible causes would be SUSPEND/RESUME of usb device.
Let me see about libusb implementation differences.

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.

Instead of fixing this it is easier to use an ISO date string at the prompt -
this is what all GUIs are doing.

Probably a trigger for this, but if a hardware error is causing this it appears
to be recoverable by software otherwise why would restarting gpg-agent /
scdaemon help?

Before the changes to libusb from time to time i had to reenter my pin for
authentication although it should have been cached and in the syslog it showed
the usb disconnect / reconnect. But scdeamon recovered from that.

btw. I can't reproduce this problem if I just disconnect / reconnect the reader
that works as expected.

Hardware problem? The "usb_claim_interface failed" error seems to be ENXIO (No
such device or address).

Months do have the same problem, as it simply means multiplication with 30.

I don't understand the bug report. Do you want the feature backported or the
documentation fixed?

Hi,

please re-run the failing command ("... gpg-connect-agent ...") under strace -f
to see what actually fails. I suspect that the gpg-agent is not found (did you
do make install?).

(The command complained about the missing /root/.gnupg because the test suite
sets $GNUPGHOME and you did not. Also: please don't compile software as root.)

This is no longer an issue with gnupg master:

% socat - tcp-listen:11371
GET /pks/lookup?op=index&options=mr&search=foobr HTTP/1.0
Host: localhost:11371
Connection: close
Via: 1.0 tinyproxy (tinyproxy/1.8.3)
Pragma: no-cache
Cache-Control: no-cache

Feel free to reopen with more specific information.

As far as I can tell this is a feature and not a bug. gpgconf reads stderr and
writes that to the eighth column.

I cannot reproduce this with current master. Feel free to reopen this bug if
you manage to reproduce it.

Sorry, that second log does not show anything new. I'm attaching a verbose log
for reference that I obtained the way I described using the version you used.
For me all tests pass, so unless we get more information on the failures it is
impossible to tell what's going on.

hi, this is my new test log, my cmd is
$ make -C tests/openpgp check verbose=2

It wasn't apparent to me until I looked at tests/gpg/t-encrypt.c that
gpgme_op_encrypt_sign expects an array of keys for the second parameter. It worked
when my code was straight C with a pointer to just a single key. In C++ I started
getting segfaults so I switched to an array.

gpgme_key_t keys[1] = {NULL};
gpgErr = gpgme_get_key(gpgCtx,to.c_str(),&keys[0],0);
It still segfaulted, further review, I THINK the array of keys needs to have one
blank key at the end else it may result in a buffer overrun in GPGME? Shouldn't
sizeof be used to determine the length of the array or something similar? Otherwise
the array would have to be at least 2 elements with the last element not a key so
the GPGME doesn't seg.

Process 12727 stopped

• thread #1: tid = 0x864b5, 0x00000001000107ea

libgpgme.11.dylib`gpgme_op_encrypt_sign(ctx=0x0000000100200850,
recp=0x00007fff5fbffa50, flags=GPGME_ENCRYPT_NO_ENCRYPT_TO,
plain=0x0000000100201000, cipher=0x0000000100200dc0) + 474 at encrypt-sign.c:168,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

frame #0: 0x00000001000107ea

libgpgme.11.dylib`gpgme_op_encrypt_sign(ctx=0x0000000100200850,
recp=0x00007fff5fbffa50, flags=GPGME_ENCRYPT_NO_ENCRYPT_TO,
plain=0x0000000100201000, cipher=0x0000000100200dc0) + 474 at encrypt-sign.c:168

165 	
166 	      while (recp[i])
167 		{

-> 168 TRACE_LOG3 ("recipient[%i] = %p (%s)", i, recp[i],

169 			      (recp[i]->subkeys && recp[i]->subkeys->fpr) ?
170 			      recp[i]->subkeys->fpr : "invalid");
171 		  i++;

(lldb) bt

• thread #1: tid = 0x864b5, 0x00000001000107ea

libgpgme.11.dylib`gpgme_op_encrypt_sign(ctx=0x0000000100200850,
recp=0x00007fff5fbffa50, flags=GPGME_ENCRYPT_NO_ENCRYPT_TO,
plain=0x0000000100201000, cipher=0x0000000100200dc0) + 474 at encrypt-sign.c:168,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

• frame #0: 0x00000001000107ea

libgpgme.11.dylib`gpgme_op_encrypt_sign(ctx=0x0000000100200850,
recp=0x00007fff5fbffa50, flags=GPGME_ENCRYPT_NO_ENCRYPT_TO,
plain=0x0000000100201000, cipher=0x0000000100200dc0) + 474 at encrypt-sign.c:168

frame #1: 0x0000000100000b76

pgtalk`GPGWrapper::encryptAndSign(this=0x00007fff5fbffb30, message="This is a
test\n", to="044E9E1D78D510E4C798D3B803254F162CFF2601") + 166 at GPGWrapper.cpp:32

frame #2: 0x00000001000019c6 pgtalk`main(argc=1, argv=0x00007fff5fbffc38) + 486

at pgtalk.cpp:13

frame #3: 0x00007fff910ad5ad libdyld.dylib`start + 1
frame #4: 0x00007fff910ad5ad libdyld.dylib`start + 1

(lldb) quit

Fixed in 81797af.

(Sorry about the question about the OS - my fault)

Please also tell us what OS you are using.
Are you running in FIPS mode?
The output of "gpg --version" would also be helpful.

Fixed in 42d4c276. Thanks!

I approved you as a user, if you still cannot comment on the bug, please ping me
again.

Hello,

can you please run

$ make -C tests/openpgp check verbose=2

and attach the output?

Werner,

Thanks a lot. I will try to apply the patch.
Can you please let us know if your company is offering enterprise level
support.

Thanks
Sandeep

Can you please enter the command "where" in dbx after the fault?

No updates in 8 months, thus closing.

Thus clang is wrong here because it prints an "error" and not something like a
"performance hint". I close this bug.

Fixed on 2016-03-19 with commmit af9a4afb. Note that --quiet shall not suppress
all output.

(The commit you gave is wrong).

Thanks for the report. Probably fixed with commit e2c5781.

Actually we are working on a 64 bit version.