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.