If someone comes up with a brief description on how to use it, we can add it.

I'm not convinced that the +-prefixed lines address clint's concern.

In particular, the parenthetical remark "(domain means the domain part of the
mail address)" is the important bit -- will this be documented somewhere?

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

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.

I am sorry, but this is a bug tracker and not a help line.
Please ask on the gnupg-users mailing lists:
https://lists.gnupg.org/mailman/listinfo/gnupg-users

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.

And there is also the new

  $ gpg --quick-gen-key "Otto Normalverbraucher <otto@example.invalid>"
  About to create a key for:
      "Otto Normalverbraucher <otto@example.invalid>"

  Continue? (Y/n)

which avoids almost all questions. Whether to set an expiration date by default
is a different question and is connected on how a key can be revoked.

Although the patch is not very intrusive to other parts of GnuPG,
I do not like it for several reasons:

• Armored is detected by the file's suffix. That is not the Unix way.

• open and close is used - we should avoid that in new code. Always use es_ functions for better portability.

• There is new function to create some temp dir despite that we already have such functions elsewhere. I have not seen the immediate reason for it.

My suggestion was to read the file into an estream object and change
the dearmor and keydb_add_resources to be able to work with it. There
is a unarmor_pump_new function which could be a starting point.
Granted, this would be a much more intrusive change and thus I doubt
that it is useful to spend too resources on it.

Can you please back out that commit.

BTW, please do not put a "cleanup" label in the mid of a function and
according to GNU standards initialized variables deserve separate
lines and statements.

Thanks for your suggestions. We have simplified the key generation process, do
you mind to re-evaluate it?

% gpg2 --gen-key
gpg: WARNING: unsafe permissions on homedir
'/home/teythoon/repos/g10/local/gnupghome'
gpg (GnuPG) 2.1.12-beta119; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Otto Normalverbraucher
Email address: otto@example.invalid
You selected this USER-ID:

    "Otto Normalverbraucher <otto@example.invalid>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 81F88C88 marked as ultimately trusted
gpg: revocation certificate stored as
'/home/teythoon/repos/g10/local/gnupghome/openpgp-revocs.d/5FB9D2A5255C94E3D06B5B563C8167E481F88C88.rev'
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key 909DD699 not found
gpg: public key of ultimately trusted key 5F2FA2F6 not found
gpg: public key of ultimately trusted key 5B81A1FD not found
gpg: marginals needed: 3 completes needed: 1 trust model: PGP
gpg: depth: 0 valid: 5 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 5u
pub rsa2048/81F88C88 2016-04-05 [S]

Key fingerprint = 5FB9 D2A5 255C 94E3 D06B  5B56 3C81 67E4 81F8 8C88

uid [ultimate] Otto Normalverbraucher <otto@example.invalid>
sub rsa2048/3E5BDFAF 2016-04-05 []

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

Fixed in 9354293.

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

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

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.

Fixed in abb352d.

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

Ok, if you agree that this is a useful feature then I will implement it.

Adding an API to the --quick-* commands of gpg 2.1 is no my shortlist for GPGME.
This will make things much easier - including key signing.

I can understand the reason to avoid binary data in a repo.

I have not checked but iff we use estream to access a plain old keyring it would
be possible to use the existing unarmor code and feed that to an es_fopenmem
object.

(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!

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

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

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)

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

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.