Page MenuHome GnuPG
Create Task
Maniphest T3393

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

Description

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?

Revisions and Commits

rG GnuPG
rGa172759b5088 tests: Fix a test which specifies expiration date.
rG17f764dd4972 tests: Fix a test which specifies expiration date.

Related Objects

Event Timeline

dkg created this task.Sep 8 2017, 2:15 AM
dkg created this object in space S1 Public.
• gniibe added a subscriber: • gniibe.Sep 8 2017, 4:04 AM

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 https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/gnupg2_2.1.23-2.rbuild.log, 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).

• gniibe added a comment.Sep 8 2017, 4:18 AM

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.

dkg added a comment.Sep 8 2017, 5:46 AM

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?

• gniibe claimed this task.Sep 8 2017, 6:10 AM

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

dkg added a comment.Sep 8 2017, 6:11 AM

Is it possible that this is related to T3278 ?

• gniibe added a comment.EditedSep 8 2017, 6:23 AM

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 added a commit: rG17f764dd4972: tests: Fix a test which specifies expiration date..Sep 8 2017, 7:37 AM
• gniibe triaged this task as Normal priority.Sep 8 2017, 9:20 AM
• werner added a commit: rGa172759b5088: tests: Fix a test which specifies expiration date..Sep 12 2017, 2:39 PM
• gniibe closed this task as Resolved.Sep 14 2017, 2:50 AM

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