Fixed in 4ba11251.

How did you create the key? I tried to reproduce it, and my numbers are even funnier:

% gpg2 --list-packets key2
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!

off=0 ctb=95 tag=5 hlen=3 plen=919

:secret key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2046 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1016 bits]
checksum: 4197
keyid: 576109131A46786C

off=922 ctb=b4 tag=13 hlen=2 plen=29

:user ID packet: "Test Keyyy <test@example.org>"

off=953 ctb=89 tag=2 hlen=3 plen=311

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x13
digest algo 8, begin of digest 79 38
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 9 10 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2045 bits]

off=1267 ctb=9d tag=7 hlen=3 plen=920

:secret sub key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2047 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1024 bits]
checksum: 4233
keyid: 2D1354FDD1343C83

off=2190 ctb=89 tag=2 hlen=3 plen=287

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x18
digest algo 8, begin of digest 49 47
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2047 bits]

% GNUPGHOME=$(mktemp -d) gpg2 --import key2
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!
gpg: keybox '/tmp/tmp.vt2HmFYk11/pubring.kbx' created
gpg: /tmp/tmp.vt2HmFYk11/trustdb.gpg: trustdb created
gpg: key 576109131A46786C: public key "Test Keyyy <test@example.org>" imported
gpg: key 576109131A46786C: secret key imported
gpg: Total number processed: 3
gpg: imported: 1
gpg: secret keys read: 3
gpg: secret keys imported: 2

I'd say 'Total number processed' and 'secret keys read' is off by one even if one counts the
subkeys.

Ah, I misunderstood your problem. In the future, please paste all program interactions in one chunk
in the right order. We did merge some changes related to exporting of secret keys, so it may very
well be solved by that.

Thanks for caring :)

I have a possible solution pushed to branch justus/issue1955. The idea is to try
to parse the message with PINENTRY_MODE_CANCEL first, and should that fail, we
retry with the configured pinentry mode. Not sure if that is too hacky, or what
side-effects parsing the message may have that we must not do twice. Werner,
what do you think?

I think the problem is that your key export fails, because you pointed
--homedir at the (presumably) empty directory "%tmp%\_tempKeyring".

The export did not use any filter and tried to export a key as can be seen in
Msg8313 "error receiving key from agent"
The import itself also stated no errors as it can be seen in T2355 (dranft on May 12 2016, 03:00 PM / Roundup), but this
imported secret key cannot be used (or exported) anymore.
Also important: This is no longer reproducible in 2.1.14 (which might be enough
to set the bug to fixed)

I don't believe this demonstrates a bug.

I think the problem is that your key export fails, because you pointed --homedir at the (presumably)
empty directory "%tmp%\_tempKeyring". This leads to the not very helpful error message about the
eof. If the export were successful, gpg would have written the key to stdout.

For reference, here is what I tried. First GNUPGHOME points to a home with the key I want to export:

    $ echo $GNUPGHOME
    /tmp/tmp.T7I4M9RIc3
    $ g10/gpg --list-keys alpha
    gpg: please do a --check-trustdb
    pub   dsa1024 1999-03-08 [SCA]
          A0FF4590BB6122EDEF6E3C542D727CC768697734
    uid           [ unknown] Alfa Test (demo key) <alfa@example.net>
    uid           [ unknown] Alpha Test (demo key) <alpha@example.net>
    uid           [ unknown] Alice (demo key)
    sub   elg1024 1999-03-08 [E]

You need some kind of pinentry program, because you may be asked for the current passphrase or an
export passphrase:

    $ cat $GNUPGHOME/gpg-agent.conf
    pinentry-program /usr/bin/pinentry-x11

Now export the key:

    $ g10/gpg --export-secret-keys alpha >/tmp/alpha.gpg

Now I create an empty home, and import the key in batch mode:

    $ export GNUPGHOME=$(mktemp -d)
    $ g10/gpg --batch --import /tmp/alpha.gpg
    gpg: keybox '/tmp/tmp.bL2caQmZri/pubring.kbx' created
    gpg: /tmp/tmp.bL2caQmZri/trustdb.gpg: trustdb created
    gpg: key 2D727CC768697734: public key "Alfa Test (demo key) <alfa@example.net>" imported
    gpg: key 2D727CC768697734: secret key imported
    gpg: Total number processed: 3
    gpg:               imported: 1
    gpg:       secret keys read: 3
    gpg:   secret keys imported: 2

Could you please check if that works for you?

Fixed in d9839c9d.

On 2016-07-19, Justus Winter via BTS wrote:

This has nothing to do with faking time one way or another.

You are reporting two problems. In the future, please create two issues.

I agree with your first problem, even though there is additional syntax for specifying the
expiration date with --quick-gen-key. This is easy to fix.

Your second problem is less clear. First of all, your command line makes no sense. --
default-sig-expire only affects signatures over data. Furthermore, user ids do not
expire, merely the (self-)signatures may do so. Do you want that?

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

Yes, that is very likely the same bug. Feel free to reopen this report if yuo
can still reproduce it, in which case a backtrace would be very handy.

Fixed in 28fd0ab.

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

I forgot to apply Daiki's patch. Done now with commit 82b90ee.

I won't work on the other mentioned change now and this commit is actually about
a regression. Thus bumping to testing.

fwiw, the documentation says:

       --try-all-secrets
              Don't look at the key ID as stored in the message  but  try  all
              secret  keys  in  turn  to  find  the right decryption key. This
              option forces the behaviour  as  used  by  anonymous  recipients
              (created  by  using  --throw-keyids  or  --hidden-recipient) and
              might come handy in case where an encrypted message  contains  a
              bogus key ID.

but that behavior is in fact not the default when used with anonymous
recipients, either:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --no-skip-hidden-recipients --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$

I can confirm that this is still a problem on 2.1.13: --try-all-secrets does not
work as documented:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-all-secrets --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-secret-key test --decrypt test.asc
gpg: anonymous recipient; trying secret key 82A22A9306735B0C ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
test test
0 dkg@alice:/tmp/cdtemp.hphmpn$

Talked to werner about it. The way something like trust-model should be
switchable would be best to handle with profiles.

There is at least one profile planned for EasyGPG. Something like "Silent" or
automated. Riseup and VSNFD will probably also want to create profiles.

I think apply-defaults could be extended for this with a defaults file for each
profile.
Then something like:

gpgconf --list-defaults

    List all available default files.

Where the output format could be similar to list-components.
name:description:filename:

filename is the path to the config file.

Then --apply-defaults could be extended to take an optional filename as an
argument. (Like --list-config, --check-config)

With --dry-run it should only check if all the settings marked as no-change are
set correctly and indicate it through the return code.

For EasyGPG I think a config file could be:

• gpg-agent max-cache-ttl [change] 30758400 gpg-agent default-cache-ttl [change] 30758400 gpg trust-model [no-change] tofu+pgp gpg auto-key-retrieve [change] gpg auto-key-locate [change] local,wkd,dane,pka,cert,keyserver

@aheincke an myself observed different behaviour on two ldap server versions
(openldap).
Our new openldap server fails for old dirmngr 1.1.0 Version: 1.1.0+r347-0kk2
and 2.1.11 and master.

Internall we can still access the old ldap server for testing purposes.

Next step see on the wire what the differences could be.

Sorry for going AWOL on this, Werner. Do you still need a backtrace from me, or is the
one from 2371 enough?

related: T1143

How do you plan to handle the case that "local" lookup only yields expired or
revoked keys. Will GnuPG then automatically fall back to other locate-keys methods?
This would be my wish so that a MUA / User of that command does not have to care
about that case :-)

Ok,
Let me summarize how I understand the workflow is supposed to be:

• Generate a Key with the limited batch keygen.
• After key creation add subkeys as wanted with --quick-addkey
• Add additional UID's with --quick-adduid

I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.

But yeah thats icing on the cake.

Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..

We now have gpg --quick-addkey fpr algo usage expire
(for2.1.13)

Bernhard: Please do not assign bugs to me without my consent.

Duplicate of T2374

Hi, I consider it a regular defect if unexplained, because the API somehow changed.

I ran into it while testing python3-gpgme on Debian Jessie.
Two testcases fail because of the changed gpgme behaviour to count more processed
"keys" than before.

pygpgme-0.3$ python3 -m unittest tests.test_import

F..F..

FAIL: test_import_concat (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 105, in

test_import_concat

self.assertEqual(result.considered, 3)

AssertionError: 5 != 3

FAIL: test_import_secret_file (tests.test_import.ImportTestCase)

Traceback (most recent call last):

File "/home/bernhard/werkbank/2auto/pygpgme-0.3/tests/test_import.py", line 58, in

test_import_secret_file

self.assertEqual(result.considered, 1)

AssertionError: 3 != 1

How to see the difference without pygpgme installed in Jessie with
Package: libgpgme11
Version: 1.6.0-99intevation1

Package: gnupg2
Version: 2.1.11-99intevation2

pygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg3 gpg2 --with-colons --import
key1.pub key1.sec key2.pub
gpg: Total number processed: 5

The same on wheezy:
Package: libgpgme11
Version: 1.3.1-0kk3

Package: gnupg2
Version: 2.0.25-99intevation2
ygpgme-0.3/tests/keys$ LANG=C GNUPGHOME=~/tmp/dot.gnupg gpg2 --with-colons --import
key1.pub key1.sec key2.pub

gpg: Total number processed: 3

See bug 2371, which has a backtrace attached.

Duplicate of T2371

Thanks. I need a stack backtrace to find the location of the cause.
Please start gpg-agent using:

  gpg-connect-agent /bye

The figure out the PID of the gpg-agent process and run

  gdb /usr/local/bin/gpg-agent PID

At the gdb prompt enter

  handle SIGPIPE nostop noprint pass
  c

The "c" continues operation of gpg-agent. In another terminal run

  gpg2 --sign

as done in your example. GDB in the first terminal will eventually
stop due to the assert. Enter at the gdb prompt:

  bt

and post the output. I would also like to know which version of
libgpg-error you are using:

  gpg-error --version

should show this (or use gpg-error-config --version).

The algorithm I'm using now to detect the best key from a locate-keys result is
(Q_FOREACH just means "iterate over all elements in this list"):

Key keyC; /* The key candidate */
UserID uidC; /* The uid candidate */
Q_FOREACH (const Key k, keys) {

if (canEncrypt && !k.canEncrypt()) {
    continue;
}
/* First get the uid that matches the mailbox */
Q_FOREACH (const UserID u, k.userIDs()) {
    if (QString::fromUtf8(u.email()).toLower() == mailbox.toLower()) {
        if (uidC.isNull()) {
            keyC = k;
            uidC = u;
        } else if ((!uidIsOk(uidC) && uidIsOk(u)) || uidC.validity() <

u.validity()) {

            /* Validity of the new key is better. */
            uidC = u;
            keyC = k;
        } else if (uidC.validity() == u.validity() && uidIsOk(u)) {
            /* Both are the same check which one is newer. */
            time_t oldTime = 0;
            Q_FOREACH (const Subkey s, keyC.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    oldTime = s.creationTime();
                }
            }
            time_t newTime = 0;
            Q_FOREACH (const Subkey s, k.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    newTime = s.creationTime();
                }
            }
            if (newTime > oldTime) {
                uidC = u;
                keyC = k;
            }
        }
    }
}

}

The helper functions to check if a key / subkey / uid is ok are just:

static bool keyIsOk(const Key k)
{

return !k.isExpired() && !k.isRevoked() && !k.isInvalid() && !k.isDisabled();

}

static bool uidIsOk(const UserID uid)
{

return keyIsOk(uid.parent()) && !uid.isRevoked() && !uid.isInvalid();

}

static bool subkeyIsOk(const Subkey s)
{

return !s.isRevoked() && !s.isInvalid() && !s.isDisabled();

}

We had the same effect here and it was caused by a V3 public key in the
keyring.
This key does not show up while listing the public keys with GnuPG 2.1.12. We
could only identify and remove it by accessing the keyring with a GnuPG 1.4.x
installation.
It should be considered to either

• display the key also during the list-keys command (to help the user to track

down the problem)
or

• ignore it silently while building the trust db.

PS: forget the --homedir thing, it is even reprodicable in the default folder in
%appdata%.

Sorry, forgot my import cmdline:

C:\Program Files (x86)\GNU\GnuPG\2.1.12\bin>gpg --batch --homedir
%tmp%\_tempKeyring --import "P:\2EEC2B65A2B4B3EF.sec.asc"
gpg: Die "Keybox" `C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/pubring.kbx'
wurde erstellt
gpg: C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel A2B4B3EF: Öffentlicher Schlüssel "Daniel Ranft (Giegerich &
Partner GmbH)" importiert
gpg: Schlüssel A2B4B3EF: "Daniel Ranft (Giegerich & Partner GmbH)" nicht geändert
gpg: Schlüssel A2B4B3EF: geheimer Schlüssel importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 4
gpg: importiert: 1
gpg: unverändert: 1
gpg: gelesene geheime Schlüssel: 3
gpg: unveränderte geh. Schl.: 2
gpg: keine ultimativ vertrauenswürdigen Schlüssel gefunden

Fixed in 2.1.12

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.

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

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

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.

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.

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

(The commit you gave is wrong).