gpgme(qt) testsuite error on 32bit archs with 64bit time_t
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	ametzler1
	Sat, Apr 26, 1:56 PM

Description

gpgme throws a testsuite error on 32bit archs with 64bit time-t (i.e. with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 in CPPFLAGS):

********* Start testing of AddExistingSubkeyJobTest *********
Config: Using QtTest library 5.15.15, Qt 5.15.15 (arm-little_endian-ilp32-eabi-hardfloat shared (dynamic) release build; by GCC 14.2.0), debian unknown
PASS   : AddExistingSubkeyJobTest::initTestCase()
PASS   : AddExistingSubkeyJobTest::testAddExistingSubkeyAsync()
PASS   : AddExistingSubkeyJobTest::testAddExistingSubkeySync()
FAIL!  : AddExistingSubkeyJobTest::testAddExistingSubkeyWithExpiration() Compared values are not the same
   Actual   (result.code())                     : 0
   Expected (static_cast<int>(GPG_ERR_INV_TIME)): 161
   Loc: [../../../../lang/qt/tests/t-addexistingsubkey.cpp(238)]
PASS   : AddExistingSubkeyJobTest::cleanupTestCase()
Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 3564ms
********* Finished testing of AddExistingSubkeyJobTest *********

Adding

printf("DEBUG1 sourceSubkey.expirationTime=%lli\n",
		       sourceSubkey.expirationTime());

to lang/qt/tests/t-addexistingsubkey.cpp L268 after
const auto result = job->exec(key, sourceSubkey);
shows this output:
DEBUG1 sourceSubkey.expirationTime=-192479296
whereas amd64 shows
DEBUG1 sourceSubkey.expirationTime=4102488000

Looking at respective key we find
sub cv25519 2022-01-13 [E] [expires: 2100-01-01]
which matches

ametzler@amdahl:~$ LANG=C date -d @4102488000
Fri Jan  1 12:00:00 UTC 2100

The "-192479296" looks like an overflow. armhf has ULONG_MAX[4294967295] and LONG_MAX[2147483647] and 4294967295-4102488000+1=192479296 (ULONG_MAX minus correct time_t +1 = wrong negative date value).

Details

External Link: https://bugs.debian.org/1103787
Version: 1.24.2

Revisions and Commits

rM GPGME
	rMf23cef6f66a4 cpp: Ensure correct expiration time on 32-bit arch with 64-bit time_t

Related Objects

Mentioned In: T7659: Release GPGME 1.24.3
Mentioned Here: rMf2d40473b522: Change timestamp fields from signed to unsigned long.

Event Timeline

ametzler1 created this task.Sat, Apr 26, 1:56 PM

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

• werner added a project: gpgmeqt.Mon, Apr 28, 9:22 AM

This looks like a problem in gpgme. struct _gpgme_subkey stores the expiration date as long int expires which is a signed 32-bit value on all 32-bit architectures. gpgmepp casts this to time_t, but that doesn't help if the 32-bit value is already negative. The same problem exists with all other timestamps in gpgme (i.e. key creation date, signature expiration date, etc.).

It looks like the entirety of gpgme timestamping was missed when the 64bit time transition happened in Debian and Ubuntu.

I did a local change (on amdahl.d.o) changing _gpgme_subkey.expires to long long (ABI-break) and all tests succeeded.

The following patch for gpgme 1.24 should fix the test.

diff --git a/lang/cpp/src/key.cpp b/lang/cpp/src/key.cpp
index 42046aa..2b14d90 100644
--- a/src/key.cpp
+++ b/src/key.cpp
@@ -633,7 +633,7 @@ time_t Subkey::creationTime() const
 
 time_t Subkey::expirationTime() const
 {
-    return static_cast<time_t>(subkey ? subkey->expires : 0);
+    return static_cast<time_t>(static_cast<unsigned long int>(subkey ? subkey->expires : 0));
 }
 
 bool Subkey::neverExpires() const

tested @ikloecker's patch succesful on amdahl.

• werner triaged this task as Normal priority.Mon, May 5, 4:41 PM

• ikloecker added a commit: rMf23cef6f66a4: cpp: Ensure correct expiration time on 32-bit arch with 64-bit time_t.Mon, May 5, 5:22 PM

For gpgme 2 we changed the data types of the time fields to unsigned: rMf2d40473b522e348d96a70c089d2191d0b978098 . Since this change breaks the ABI we use the above change for the 1.24 branch.

Should be fixed.

• ikloecker moved this task from Backlog to QA for next release on the gpgme board.Mon, May 5, 5:42 PM

works for me, thanks

In T7627#200387, @werner wrote:

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

Well, I have to retract this statement. For fixing bugs in the stable gpg4win-4 we actually need the 1.24 branch and thus there will be a release with two fixes for the cpp part.

• werner mentioned this in T7659: Release GPGME 1.24.3.Mon, May 19, 4:43 PM