furthermore, if the user enters an empty password, gpg-agent says "please
confirm that you do not want to have any protection on your key".

If the user chooses "yes, protection is not needed" in this followup prompt, gpg
*still* refuses to export the secret key, producing this error message:

---------------

gpg: key 0CA2C754F8DF3194EC1F1C7EF88AEA8D20BAFB0F: error receiving key from
agent: No passphrase given - skipped

gpg: WARNING: nothing exported

If I understand correctly, we cannot compile latest libgcrypt because:

• the installed libgpg-error is a beta release
• it has been installed in /usr instead of /usr/local

That's unusual.
So I rebuilt libgcrypt with libgpg-error stable 1.21 installed in /usr, and it
passed.

It is true that I have built & installed libgpg-error from git master into
/usr:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

But what do you mean by "properly install the library"?

Your system is misconfigured. You are using the gpg-error.h header
file from an unreleased version of libgpg-error but you are linking to
an older library.

  checking for gpg-error-config... /usr/bin/gpg-error-config
  checking for GPG Error - version >= 1.13... yes (1.22-beta14)

It seems you installed a libgpg-error version from git master
(.1.22-beta14) into the system directories instead of using
/usr/local. And you forgot to properly install the library.

Configured with:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

Thank you! All set.

I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.

my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.

So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.

The manual states:

     RECP must be a ‘NULL’-terminated array of keys.  The user must keep
     references for all keys during the whole duration of the call (but
     see ‘gpgme_op_encrypt_start’ for the requirements with the
     asynchronous variant).

What you call a blank key is a NULL stored in the array. A common way to
allocate such an array is by using

  gpgme_key_t *keys = calloc(nkeys+1, sizeof *keys);

and then fill the array with the keys: If you don't put keys into the array
(i.e.NULL as first item) the fucntion retruns GPG_ERR_INV_VALUE.

Regarding your problem with gpgme_get_key: You need to pass a variabale of type
gpgme_key_t to that function. The fucntion allocates a new key objects and
_stores_ it at that variable:

  gpgme_key_t akey;
  err = gpgme_get_key (ctx, fingerprint, &akey, 0);
  .. processing goes here ...
  gpgme_key_unref (akey);

Note that on error NULL is stored at AKEY and thus gpgme_key_unref can be called
in any case.

gpg-agent should fix the permission of private-keys-v1.d/.

The reason for prompting for the passphrase is that gpg/gpg-agent needs to
re-encrypt the key to the format used by gpg-agent. Although the format is
currently very similar it is not a 1-to-1 mappring and thus it needs to be
re-encrypted. Further the S2K "iteration" parameter used by gpg-agent is to be
adjusted to the speed of the new machine.

The kludge we use with --batch is to allow fast migration of keys from older gpg
versions to to 2.1. This works by storing the secret key directly in the
gpg-agent store in a special format. As soon as gpg-agent needs to use that key
and thus requires a passphrase anyway, the key will be re-encrypted on the fly.

We can change the interfactive import to continue processing with the next
keyblock if a passphrase was not given.

Thank you for your patch. Yes, we already located the issue is the alignment.
I think that it were good if the MTX were placed at the head. While your patch
works, it changes ABI of the lock object for existing archs, unfortunately.

I fixed the detection of Solaris in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=f7a77c5c236ecec846de9be46703026f9b01008f

And I believe that the bug reported here had gone.
Please test current development master.

Oh well, I see the problem. Needs to be fixed.

The problem is that using an entire uid that is a substring of another
uid selects both uids. This makes it impossible to select a uid that is
a substring of another.

The attached is an analysis from the Solaris/SPARC point of view.

One of the possible SPARC specific fixes:

• ./src/posix-lock-obj.h.orig Wed Apr 13 08:24:20 2016

+++ ./src/posix-lock-obj.h Wed Apr 13 08:24:25 2016
@@ -29,7 +29,7 @@

typedef struct
{

• long vers;

+ long long vers;
#if USE_POSIX_THREADS

union {
  pthread_mutex_t mtx;

• ./src/gen-posix-lock-obj.c.orig Wed Apr 13 08:23:59 2016

+++ ./src/gen-posix-lock-obj.c Wed Apr 13 08:24:29 2016
@@ -66,7 +66,7 @@

int i;

#endif

struct {

• long vers;

+ long long vers;
#ifdef USE_POSIX_THREADS

pthread_mutex_t mtx;

#endif
@@ -105,7 +105,7 @@

   union and include a long and a pointer to a long.  */
printf ("typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

"  union {\n"
"    volatile char _priv[%d];\n"
"%s"

@@ -138,7 +138,7 @@

printf ("/* Dummy object - no locking available.  */\n"
        "typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

           "} gpgrt_lock_t;\n"
           "\n"
           "#define GPGRT_LOCK_INITIALIZER {%d}\n",

Note, that this was not fully tested on other platforms and might need
additional changes in the header files. I did some minor tests on
Solaris amd64/SPARCv9/SPARCv7, Linux amd64/SPARCv9.

Please do not refer to another web site - write your report here.

Why don't you use the entire user id? This quarantees that you select the right
one (match is case insensitive). Note that this matching is different from the
key selection mechanism becuase it is inteded to be used by other tools.

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

I would not consider this a bug. sshcontrol is used to enable certain keys for
use with ssh. Updating keys is useless if they are already available.

If you remove the keys from sshcontrol you disable them. I would suggest to put
a '!' in front of the keygrip instead of deleting the line in sshcontrol. This
allows to re-enable a key w/o problems.

What distribution are you using? You are probably better off using their
supplied binaries, which are hopefully tested.

The solution is to remove the key in private-keys-v1.d before running ssh-add.

http://superuser.com/a/1064269/216912

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

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?