Page MenuHome GnuPG

quick-key-manipulation.scm tests fail on reproducible-builds infrastructure.
Closed, ResolvedPublic


2.1.23 and 2.2.0 are failing to build on the reproducible-builds continuous integration infrastructure:

You can see a sidebar with a bunch of other failed builds if you want to look at other examples.

All of these examples fail only on quick-key-manipulation.scm, but i don't think i understand why.

The error logs are quite verbose, but the error message appears to be:

/build/1st/gnupg2-2.2.0/build/../tests/openpgp/quick-key-manipulation.scm:181: Assertion failed: : ((time-matches? 2145916800 (string->number (:expire subkey)) (days->seconds 1)))

It's not clear to me why this is happening on the build infrastructure for r-b, but not on the debian build daemons.

Any suggestions on how to debug?

Event Timeline

dkg created this object in space S1 Public.

Possibly, timezone (of build machine) matters.

In the test, it executes gpg command as:

gpg --no-permission-warning --always-trust --quick-add-key 0315A6C821F057D9B1D739D89893BD38973FEAA4 rsa sign 2038-01-01

and check the resulted subkey's expiration value with 2145916800, allowing 24 hours difference.

In the log of, it is 2146003200, which exactly differs 86400 sec (= 24 hours).

I think that 2145916800 is 2038-01-01 of UTC timezone.
When gpg is asked to generate key/subkey by date, it means the date of its local timezone + 12 hours (gnupg/g10/keygen: parse_expire_string).

I think that if the machine's timezone is UTC-12, the expiration will be 2146003200 (= 2145916800+86400).

In the log, I found:

I: pbuilder: network access will be disabled during build
I: Current time: Sat Oct  6 20:00:09 -12 2018
I: pbuilder-time-stamp: 1538899209

It seems "-12" means UTC-12.

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

Is it possible that this is related to T3278 ?

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

gniibe triaged this task as Normal priority.Sep 8 2017, 9:20 AM

Committed to both branches (master and 2.2), so, closing.