Page MenuHome GnuPG
Create Task
Maniphest T5991

gpgme test suite fails when local time differs from UTC time across a day boundary.
Closed, ResolvedPublic
Actions

Description

My local date is different from the UTC date right now (i'm in -0400, so this is true only 4 hours out of the day). If i run the gpgme test suite in my local TZ, i see:

********* Start testing of TestVarious *********
Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.2.0), debian unknown
PASS   : TestVarious::initTestCase()
PASS   : TestVarious::testDN()
PASS   : TestVarious::testKeyFromFile()
PASS   : TestVarious::testDataRewind()
PASS   : TestVarious::testQuickUid()
PASS   : TestVarious::testSetExpire()
PASS   : TestVarious::testSignKeyWithoutExpiration()
FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/05
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [../../../../lang/qt/tests/t-various.cpp(342)]
PASS   : TestVarious::testVersion()
PASS   : TestVarious::cleanupTestCase()
Totals: 9 passed, 1 failed, 0 skipped, 0 blacklisted, 6337ms

If i run it under TZ=UTC, i see the tests all pass.

Details

Version
1.17.1

Revisions and Commits

rKLEOPATRA Kleopatra
rKLEOPATRA8d50e6ada15c Change maximum expiration date to 2106-02-05
rM GPGME
rM7870fdbfeff4 qt: Prevent u32 overflow when calculating expiration date
rMfd813f5c3938 qt,tests: Allow 1-day-offset for expiration date
rM5ba0e454a37c tests: Avoid problems with local time across a day boundary.

Event Timeline

dkg created this task.May 21 2022, 7:10 AM
• werner added a subscriber: • werner.May 23 2022, 8:21 AM

Thanks. The solution should thus be easy.

• werner added a commit: rM5ba0e454a37c: tests: Avoid problems with local time across a day boundary..May 23 2022, 9:14 AM
dkg added a comment.May 23 2022, 7:53 PM

I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.

Presumably the test suite was written using code that external developers are likely to use to check expiration dates in other software, and that software will not be run in TZ=UTC. Is there any risk that there's an underlying bug in the gpgme library, or the engine used, or in the test suite code itself that doesn't handle timezones correctly?

If the bug is just in the test suite code, it'd still be worth fixing that to run correctly independent of the external TZ so that people looking to learn how to use the library from the test suite aren't led astray.

• ikloecker claimed this task.May 24 2022, 10:29 AM
• ikloecker triaged this task as Normal priority.
• ikloecker added a subscriber: • ikloecker.

Having written the code and the test I'm with dkg here. The code takes the expiration date, calculates the number of days from today and tells gpg to set the expiration to <number of days>d. The idea of the aforementioned is that it should work for any timezone. Maybe this assumption is wrong.

• ikloecker added a project: Restricted Project.Jun 9 2022, 4:38 PM
• ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
• ikloecker added a comment.Jun 10 2022, 11:18 AM

I couldn't reproduce the one-off problem of the original report, but running the test with time zone UTC-11

TZ='Pacific/Pago_Pago' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

resulted in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2022/06/09
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because adding 30557d (number of days in UTC-11 until 2106-02-06) to the current time resulted in a u32-overflow. I'll change the maximal expiration date to 2106-02-05 to avoid the overflow.

I don't really understand the original problem. Apparently, the code calculates one day less than expected. Hmm, could this somehow be related to daylight saving?

• ikloecker added a comment.Jun 10 2022, 11:28 AM

Yeah, seems to be related to daylight saving. Running

TZ='America/Adak' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

results in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/04
   Expected (QDate(2106, 2, 5)): 2106/02/05
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because the code adds 30555 days to the current time (2022-06-10-00:xx:xx+UTC-9) which gives us 2106-02-04-23:xx:xx+UTC-10.

I will change the test to accept the dates 2106/02/05 and 2106/02/04 as correct results.

• ikloecker added a commit: rM7870fdbfeff4: qt: Prevent u32 overflow when calculating expiration date.Jun 10 2022, 12:07 PM
• ikloecker added a commit: rMfd813f5c3938: qt,tests: Allow 1-day-offset for expiration date.
• ikloecker closed this task as Resolved.Jun 10 2022, 12:07 PM
• ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

Fixed. Thanks for the report.

• ikloecker added a commit: rKLEOPATRA8d50e6ada15c: Change maximum expiration date to 2106-02-05.Jun 10 2022, 12:10 PM