Page MenuHome GnuPG

Fix time API in gpgme
Open, NormalPublic

Description

gpgme mostly uses signed long int and time_t internally. This is of course a problem on 32 bit platforms and not only on Jan 19, 2038. gpg and in particular gpgsm takes great care to avoid this problem and gpgme parses this correctly. However, errors are sometime indicated by -1 and the question is whether this is needed at all.

We could simply change to unsigned long int and map errors to 0 or add an extra error flag. In most cases this will simply work but it would be an ABI break of course. Or we provide that new time API (tm) which we have in the work s for 15 years.

Event Timeline

what does "not only on Jan 19, 2038" mean here?

That it will not be a problem on that or near that date but already now because some use expiration times of 20 years.

werner lowered the priority of this task from Normal to Low.Jul 16 2020, 2:38 PM
werner raised the priority of this task from Low to High.Aug 23 2023, 2:29 PM
werner added projects: gnupg22, Restricted Project, kleopatra.

It turned out that we need to fix this for use by Kleopatra on Windows.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

We have not once shipped the 32bit MSI package. The only thing we occasionally see is 32 bit office on a 64 bit windows.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

A quick test shows that the latest patches allow to set and show an expiration date beyond 2038. A new VSD beta will soon be available to customers. And we should also think about getting a gpg4win bug fix release out.

This is a generic parent task and does not require workboards for specific branches.

werner lowered the priority of this task from High to Normal.Nov 17 2023, 11:01 AM