Ok, so there are two problems:

1. gpg --batch should not use the pinentry mechanism at all.
2. gpg --export-secret-key should export unprotected keys that are stored w/o a

passphrase.

Werner, I started patching gpg-agent to allow 2., but gpg does only accept
protected keys from gpg-agent in export.c's transfer_format_to_openpgp. Is that
by design or simply not yet implemented?

I don't have a test setup for that. Kleopatra currently polls gpg-agent if a
smartcard is available.

According to Gniibe this might be causing this problem. I'm planning to change
that to switch to looking for readerstatus files that are created when a
smartcard becomes known. But this still might cause the smartcard to be locked
by scdaemon? I'm not sure.

HKPS won't be the reason, we use plain HKP

as of gpg.conf
keyserver hkp://keyserver.int.myCompany.com:11371

BTW. The versions in the previous post should have been 2.0.28 and 2.0.30 vs.
2.1.11, of course.

Hello. If you are using https to talk to your keyserver, your problem might be
Issue 1950 which we fixed in GnuPG 2.1.10.

I don't think the bugs are necessarily related. Your issue looks like you build
your own libgpg-error and linked fdpassing against that, but your runtime linker
uses your system-supplied libgpg-error. Try running 'ldd tests/fdpassing' to
see which libgpg-error is used at run-time. Feel free to ask if you need more
assistance.

Hello,

please run:

  strace -f -E srcdir=tests -o fdpassing.strace tests/fdpassing

and attach fdpassing.strace to this bug report.

I've now also mentioned that the current one is used since April 2016 and listed
the previous certificates.

Andre, we probably should also list the old certificate, because we still have
files out there with it.

Like, until 2.3.0 the codesigning certificate was: ..

For completeness, this are the pages:
https://www.gpg4win.de/package-integrity-de.html
https://www.gpg4win.de/package-integrity.html

Indeed, thanks for the report, I've updated the information for our new
certificate that we've used for 2.3.1

Sorry for the confusion caused by missing that in the first place.

System is Linux 3.2.0-23-generic.

GnstheGrain,

hmmm. :/

Thanks for the report.

A collegue of mine now has a similar problem with GnuPG on MacOS during gpg
--refesh-keys from an in-house SKS keyserver (set in gpg.conf)

Happens with GnuPG 2.2.28 and GnuPG 2.2.30. Problem disappeared with GnuPG 2.1.11.
Hence changed category back to gnupg as it's no Windows-only problem anymore.
Still assume that it is somewhat related to larger key rings.

gpg: Total number processed: 392
gpg: unchanged: 392
gpg: keyserver communications error: Not found
gpg: keyserver communications error: Bad public key
gpg: keyserver refresh failed: Bad public key

Duplicate of T2318

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?