AIX required a patch for Npth library for fork.
Please test again with npth 1.3 when it will be released.
I tested with 2.1.14, all go well successfully (make check no errors) with
patched version of Npth library.

I confirmed that with patched npth, 2.1.14 with
c49c43d7e4229fd9f1bc55e17fa32fdc334dbef6 builds well and "make check" goes
successfully (on AIX 7.1 with gcc 4.8.1).

Please test again when npth 1.3 will be released.

I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.

This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.

I believe that it's fixed in 1.22. Closing.

Closing, as I confirmed that -lrt is not needed any more in Solaris Userland
project:
https://hg.java.net/hg/solaris-userland~gate

You can have a configuration file like:

.gnupg/gpg-agent.conf

enable-ssh-support
debug-level guru
debug-all

log-file /run/user/1000/gpg-agent.log

and

.gnupg/scdaemon.conf

debug-level guru
debug-all
debug-ccid-driver

log-file /run/user/1000/scd.log

so that the interactions can be recorded with debug information.

An option like --stdout-as-tty may also be needed,
for completeness, to avoid /dev/tty writes.

Fixed in 2.1.14 with the switch to Scheme-based tests.

import-clean does call the same code, but it behaves differently for the key you
mention. I created a test key that does get cleaned up upon import.

Merged in 583a464c, thanks!

Note that we prefer contributions sent to the mailinglist using git send-email.

Thanks for the report.

I see that you are using pygpgme, is that correct? If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?

Let's try to figure out which ioctl fails. Could you try to strace this process?

IMHO, it's pretty uncommon from the packaging point of view to deliver
different generic header files for different platforms (one can meet
platform related ifdefs much often). It necessarily moves the platform
decision rules into the source code of the library consumer.

Fixed in b2572b0c.

Hi Justus,

Thanks for your response. In further testing, I was able to trigger the "FAIL:
gpgtar.scm" during a make check for 2.1.13 (actually "FAIL: gpgtar.test" for
2.1.13 since it's pre-tiny-scheme). In particular, it's vanilla 2.1.13 + your
fix in 8f79c31b. So I think what may be going on is that 8f79c31b didn't
actually fully resolve that problem after all since I've now seen it occur, with
that commit included, in 2.1.13, and in 2.1.14, and in HEAD.

Tbere were two cases where a more specific error was emitted:

In one run, I saw this:

((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet
(ctb=2d)
gpgtar: gpg: [don't know]: invalid packet (ctb=2a)
gpgtar: error running
'/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

and in another run I saw this

Checking gpgtar with signature 
((/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-0U4bUB/archive) failed: gpgtar: gpg: Fatal: zlib inflate problem:
invalid block type
gpgtar: error running
'/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

It's also worth noting that I've only been able to trigger the problem on
Jenkins during CI, not locally, so I don't know if the lack of TTY is relevant
or something like that.

I will do the ssh check you requested.

Thanks for letting us know. Unfortunately, we do not test on MacOS yet, but we are working
on that.

I have neither experience with debugging on MacOS, nor do I have access to such a machine.
I'm afraid you are on your own for now.

The ssh test is new, so we need to figure out why it does not work. Please do

  make -C tests/openpgp check TESTS="setup.scm ssh.scm" verbose=2

This lets us see what ssh-add prints to stderr. It might be related to the version of
OpenSSH shipped with the OS.

That is not a bad commit, that is Werner evolving our software. pygpgme is unmaintained since

2013. My guess is that it cannot cope with the new status code being emitted by GnuPG.

I ran the testsuite myself, and I can reproduce the issue, among many other failures: 24 if I'm
using the GnuPG components from Debian/unstable, 9 if I am using more recent components.

One of them is test_encrypt_to_signonly, which tries to encrypt a mail to a key only usable for
signing, and expects a general error, which all recent versions of GPGME return in this case, but
this was a bug, fixed in GPGME master, which returns the correct error.

Updating pygpgme is out of scope for us. If you merely need any binding, consider using the pyme3
bindings that we merged into GPGME proper, and will release with 1.7. You can also find it on
pypi, it requires GPGME 1.6.x to build.

The way I see it is that the pygpgme bindings and its test suite are way too unmaintained and the
test suite too noisy to demonstrate a bug in GnuPG or GPGME. Feel free to reopen this bug if you
have compelling evidence that we broke something, preferably a small test case not using pygpgme.

I have now tested HEAD at revision 4ba11251aff578394000bf480f47160f0879c763 and
2.1.13 (including this patch
https://raw.githubusercontent.com/Homebrew/formula-patches/7b2211b/gnupg21/spawned_child_8f79c31b.diff)

The results are

1. The "FAIL: gpgtar.scm" does *not* affect the patched 2.1.13, so it appears to

be a regression.

2. The "FAIL: gpgtar.scm" is not fixed in HEAD at

4ba11251aff578394000bf480f47160f0879c763.

3. There is a further regression in HEAD at

4ba11251aff578394000bf480f47160f0879c763, which seems not to be found in 2.1.14:

PASS: default-key.scm
Checking key export 
    > D74C5F22 C40FDECF ECABF51D <  
PASS: export.scm
Importing ssh keys... 
    > dsa key not added 
FAIL: ssh.scm
Checking passphrase cache (issue2015)... 
PASS: T2015.scm
Checking import statistics (issue2346)... 
PASS: T2346.scm

Here's the relevant snippet:

PASS: tofu.scm
Checking gpgtar without encryption 
Checking gpgtar without encryption with nicer actions 
Checking gpgtar with asymmetric encryption 
Checking gpgtar with asymmetric encryption and signature 
Checking gpgtar with signature 
((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet
(ctb=2d)
gpgtar: gpg: [don't know]: invalid packet (ctb=2a)
gpgtar: error running
'/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm
Importing public key. 
Checking that the most recent, valid signing subkey is used by default 
    > 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 <  
Checking that we can select a specific signing key 
    > 8BC90111 F5F77B83 1EA97479 <  
PASS: use-exact-key.scm
Importing public key.

Yeah, unfortunately this is still happening even with my attempt to fix it with
deparallelization, so that's not the issue.

macOS 10.9 build bot has failed in the same place again.

The document you cite also states that UID/UAT lines only use field 10.

Also, neither UID nor UAT packets encode an expiration date [0], the way an UID/UAT can expire
is that the self-signature expires [1].

0: https://tools.ietf.org/html/rfc4880#section-5.11
1: https://tools.ietf.org/html/rfc4880#section-5.2.3.3

I do no longer agree with your first problem. Key expiration is different from signature
expiration, the way to quickly generate a key that expires in one year is:

    $ g10/gpg --quick-gen-key quick_test - - 1y

I guess one could argue that if one specifies --default-cert-expire=X when adding an uid, that
the self-signature for the new uid should expire. But to be honest, I doubt that this matches
user expectations.

What would be the use case really? I know that I'll lose access to that mail address in X years
and hence want my uid to expire then.

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

ff71521d9698c7c5df94831a1398e948213af433 is the first bad commit
commit ff71521d9698c7c5df94831a1398e948213af433
Author: Werner Koch <wk@gnupg.org>
Date: Fri May 13 16:24:59 2016 +0200

    gpg: Emit new status line KEY_CONSIDERED.
    
    * common/status.h (STATUS_KEY_CONSIDERED): New.
    * g10/getkey.c: Include status.h.
    (LOOKUP_NOT_SELECTED, LOOKUP_ALL_SUBKEYS_EXPIRED): New.
    (finish_lookup): Add arg R_FLAGS.  Count expired and revoked keys and
    set flag.  Check a requested usage before checking for expiraion or
    revocation.
    (print_status_key_considered): New.
    (lookup): Print new status.
    
    Signed-off-by: Werner Koch <wk@gnupg.org>

:040000 040000 33853092f4376553defb24e39a31bdcbc13c51d2
7da8083e3f39b2fabfe0c3beab0b9f43a2a2cc32 M common
:040000 040000 468469de2419e59efddd718b7b24d5a8cead3005
d2c77b1e1bbab29cd506b29dc359d44c841dbc99 M doc
:040000 040000 044148a54b854a31a0f6ad6605a50a57cc46dfcd
e229f5d63dc27377a7fa1d50ff512a040a389f1f M g10

D378: 864_0001-configure.ac-restore-user-CFLAGS-before-checking-fun.patch

Update patch to cover libraries search (e.g. iconv).

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:

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.

Looks like other folks are experiencing same issues:
https://lists.gnupg.org/pipermail/gnupg-users/2016-March/055421.html

My problems are resolved. I have not encountered a problem since your last
fixes. Although I sometimes have to reenter pin so I think the errors still
occur occassionally but gnupg recovers.

Thanks.

It is handled in scdaemon (not in g10/keyedit.c).

When the keysize is different, it changes key attribute automatically.
For 2.1, it was fixed by f10b427d0e2be333776fee2df8150145da36e587 on 2015-09-07
which is in 2.1.8.

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.