Page MenuHome GnuPG

GnuPG: quick-key-manipulation regression test FTBFS-2038
Closed, ResolvedPublic

Description

While working on reproducible builds for openSUSE, it was found that GnuPG with version 2.5.17 fails to build after 2038-01-01 because a regression test fails after that date. Here is the build ouput:

Checking quick key generation...
Checking that we can add a user ID...
Checking that we can mark an user ID as primary.
Checking that we can mark a user ID as primary by its hash...
Checking that we get an error making non-existent user ID the primary one.
Checking that we can revoke a user ID...
Checking that we can revoke a user ID by its hash...
Checking that we get an error revoking a non-existent user ID.
Checking that we get an error revoking the last valid user ID.
Checking that we can change the expiration time.
Checking that we can add subkeys...
() (- - -) (default default never) (rsa sign auth encr seconds=600) (rsa auth,encr 2) (rsa sign 2038-01-01) (".../gnupg-2.5.17/bin/gpg" --no-permission-warning --always-trust --quick-add-key "D1B6269A83A48DEBBA001B7BDF7E4BBB10AC005A" rsa "sign" "2038-01-01") failed: gpg: Key generation failed: Invalid value
gpg: Key not changed so no update needed.
0: tests.scm:114: (throw (string-append (stringify what) " failed") (:stderr result))
1: quick-key-manipulation.scm:142: (call-check `(,(at)gpg --quick-add-key ,fpr ,(at)args))
2: #<CLOSURE>
3: tests.scm:78: (apply proc args)
4: #<CLOSURE>
5: init.scm:230: (apply proc cars)
FAIL: <standard>tests/openpgp/quick-key-manipulation.scm

Introduced in rGde383837 in the context of T2988. See also the comments in the commit around the timestamp.

Details

Event Timeline

Is that on a 32 bit machine or 64? The latter would be a problem for 32 bit with 32 bit time-t I'd say: we won't fix it.

Unfortunately, this was run on x86_64 and also other 64 bit archs.

I guess the test fails because one cannot create a key with an expiration date before the current date. And the test tries to create a key which expires on 2038-01-01 which will fail if the test is run on 2038-01-01 or later. The easiest fix would be to disable the test cases if the current date is past 2038-01-01.

Additionally, it would be nice to re-add the tests with 2105-01-01 for systems with unsigned time_t and for systems with 64-bit time_t.

Hi, the test is green with rG86baca6e62b3 for both 2038-01-01 and 2105-01-01. Thanks!

werner claimed this task.