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

Ok, I pushed a fix related to this problem 45bb9a2a, this had the amusing effect of
reversing the behavior:

% rm -f $GNUPGHOME/tofu.db ; ( g10/gpg --verify --status-fd=1 /tmp/testmsg
)2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key)
<alpha@example.net>"%0Ain the past 0~seconds.
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the
past 0~seconds.

The difference stems from tofu_register setting already_verified to 0 for the first
uid, and to 1 for the second. In the former case, show_statistics is asked to ignore
the current message.

I guess the intention was to handle the very first message differently, but now we
are handling the first *uid* upon receiving the first message differently instead.
I'm not sure how to proceed, hence reassigning to Neal.

This is a GnuPG problem:

teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg && gpg2 --verify --with-colons --status-fd=1 /tmp/testmsg && sleep 1 && gpg2 -
-verify --with-colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alfa Test (demo key) <alfa@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key) <alpha@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the past 1~second.

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.

I agree, these are problems we should address, they might be the symptoms of a
race somewhere. I bet they are in GnuPG though.

Fixed in 774dbffe.

So the key listing is enclosed in tofu_{begin,end}_batch_update:

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

at ../../g10/gpg.c:4153

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

Then an transaction is started on the email and key db:

#0 begin_transaction (db=0x733bc0, only_batch=0) at ../../g10/tofu.c:278
#1 0x0000000000497365 in record_binding (dbs=0x71cf40,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", policy=TOFU_POLICY_AUTO, 
show_old=0) at ../../g10/tofu.c:1202

#2 0x0000000000498e36 in get_trust (dbs=0x71cf40, pk=0x71a8a0,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2182

#3 0x000000000049a44d in tofu_get_validity (ctrl=0x715870, pk=0x71a8a0,

user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2946

#4 0x000000000048f4b2 in tdb_get_validity_core (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, main_pk=0x71a8a0, sig=0x0, may_ask=0)
at ../../g10/trustdb.c:1074

#5 0x000000000048cd9d in get_validity (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, sig=0x0, may_ask=0) at ../../g10/trust.c:338

#6 0x000000000048caeb in uid_trust_string_fixed (ctrl=0x715870, key=0x71a8a0,

uid=0x71aac0) at ../../g10/trust.c:154

#7 0x00000000004544bc in list_keyblock_print (ctrl=0x715870,

keyblock=0x71a9c0, secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:950

#8 0x00000000004567aa in list_keyblock (ctrl=0x715870, keyblock=0x71a9c0,
---Type <return> to continue, or q <return> to quit---

secret=0, has_secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:1604

#9 0x00000000004533bc in list_all (ctrl=0x715870, secret=0, mark_secret=0)

at ../../g10/keylist.c:556

#10 0x000000000045254e in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:143

#11 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

... and later ended, but since !! batch_update, it is not actually committed.

Now when tofu_end_batch_update is called and batch_update drops to zero, it iterates
over db_cache and commits all transactions using end_transaction, but db_cache is
empty. This is actually not that surprising, because the only place I see db_cache
being populated is in tofu_closedbs, a few lines after the failing assertion.

Fixed in f4742493.

Fixed in e584d646. Includes a fix for the old test for those who need to
backport it.

I did not work on this other than what I merged. What I did is to enhance our
fake pinentry program to allow it to supply different passphrases, make it write
a log so that we can quantify the pinentry interaction in test cases, and to add
an export test documenting the status quo.

Fixed in 4711a1e1.

Quoting Ben McGinnes (2016-05-11 19:54:21)

On Wed, May 11, 2016 at 12:44:00PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

No, simply because other (abandoned) attempts at writing wrappers for
GPGME already exist in the Python ecosystem. If we rename a module to
match the name of an existing one this will break things somewhere.
It also makes us no different from poor Isis Lovecruft who selected
the name gnupg for her fork of python-gnupg, but the original was
always imported as just gnupg so when she increased the version number
of her fork she broke a *lot* of things in other people's code.

That's also why the entirely new thing I've called GPyGME, not just to
play word games with Pygmy, but also because the name is not used by
any existing Python module.

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

• (API) One has to hand 'bytes' objects to pyme where 'char *' is expected. We

should make SWIG magically encode strings as utf-8 instead.

• Documentation. Needs to be build, likely updated, and installed. Ben was

thinking about using another tool for this. Needs investigation.

• No test suite.
• 'lang/python/examples/simple.py' segfaults.

Hmm, it is not about the maintainer mode...

Thanks for the output. That indeed confirms my suspicion. Let's read it together:

[...]
libassuan.so.0 =>
/home/ann/gnupg-2.1.11/libassuan-2.4.2/src/.libs/libassuan.so.0 (0x002e4000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0x0066d000)

ldd says which library is used to satisfy a dependency at load time. You see
here that for libassuan.so.0 your newly built library is used. That is good.
However, for libgpg-error.so.0 the library from your system is used which does
not have gpgrt_asprintf, hence the error message in your first log.

What you need to do is to make sure the runtime linker finds your gpg-error
library. Since this kind of problem will occur for each library, it is best to
install all the libraries you built to a common prefix, say /home/ann/local or
/usr/local by specifying --prefix=/my/prefix at configure time, and then to set
LD_LIBRARY_PATH to /my/prefix/lib and include /my/prefix/bin in PATH, so that
gpg-error-config and libassuan-config and co are found at compile time. Feel
free to ask questions if you get stuck.

(If you don't want to do all this by hand, and merely want a working modern
GnuPG, you can also use the 'speedo' framework. See the README in the GnuPG
repository for some hints.)

Fixed in f8adf1a.

Related T2324.

Werner: Yes please.

*See also T2070

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?

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.

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.

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 []

Fixed in 9354293.

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.