Repository navigation
GMimeSignature created and expires are time_t, fail in Y2038 on platforms with 32-bit signed time_t #68
Description
g_mime_signature_{s,g}et_{created,expires} uses time_t.
They are produced from the underlying GPGME gpgme_signature_t object, which indicate that they are unsigned long values.
But time(2) from linux manpages says that time_t is 32-bit signed on some platforms:
On Linux, a call to time() with tloc specified as NULL cannot fail with
the error EOVERFLOW, even on ABIs where time_t is a signed 32-bit inte‐
ger and the clock ticks past the time 2**31 (2038-01-19 03:14:08 UTC,
ignoring leap seconds). (POSIX.1 permits, but does not require, the
EOVERFLOW error in the case where the seconds since the Epoch will not
fit in time_t.) Instead, the behavior on Linux is undefined when the
system time is out of the time_t range. Applications intended to run
after 2038 should use ABIs with time_t wider than 32 bits.
This means that on a platform where long is 32 bits (e.g. x86_64), even though GPGME can correctly report a signature with validity ranges between 2**31 and 2**32 seconds, or (2038-01-19 03:14:08 → 2106-02-07 06:28:16 UTC), GMime wraps those values around into the negative range.
I'm running into this when I use GMime to handle sample S/MIME certificates whose expiration dates are later than Y2038.
Activity
dkg commentedon Dec 4, 2019
I'm not sure the right fix for this. From a glib perspective, i'd like to see the creation and expiration dates either returned as a
GDateTimeor aguint64(microseconds since the epoch).As glib documentation says:
The advantage of
guint64is that the caller doesn't need to worry about invokingg_date_time_free.I suppose we could offer both mechanisms, though, and let the caller decide.
Expose signature creation time and expiration time as guint64
dkg commentedon Dec 4, 2019
#69 is a simple, conservative approach that should at least expose the correct information.
I haven't written a test for this yet, but simply running
g_mime_application_pkcs7_mime_verify()against the following message would probably do it (the signing certificate expires later than Y2038):(this example message is from an upcoming revision to draft-autocrypt-lamps-protected-headers)
jstedfast commentedon Dec 4, 2019
GDateTime uses gint64 seconds from epoch. I'm not sure we need higher resolution than seconds for created/expires timestamps.
https://developer.gnome.org/glib/stable/glib-GDateTime.html#g-date-time-new-from-unix-local
That said, I absolutely agree that I'd rather use a gint64 than a GDateTime - especially if someone can easily convert to a GDateTime if that's what they really want.
Added g_mime_[certificate,signature]_get_[created,expires]64()
jstedfast commentedon Dec 4, 2019
I added get_created64() and get_expires64() instead which does similar casting to get seconds since epoch.
I can't test this because on MacOS, time_t is 64bit which makes this a non-issue on this platform.
jstedfast commentedon Oct 28, 2026
This has been fixed in my local 4.0 branch