timestamps in gpgme.h are typed with long int. On OpenBSD this may lead to
unpredictable behavior when they are used in time functions like localtime(),
shouldn't they explicitly be cast to time_t first. This has been adressed in
mutt-gpgme here:
https://marc.info/?l=mutt-dev&m=144123628113114&w=2
I have built a patched gpgme-1.6.0 successfully. When linking mutt to that, the
segfault was gone.
Description
Description
Details
Details
- Version
- 1.6.0
Event Timeline
Comment Actions
Sorry, we can't change the type because that would be an ABI break. Well, on
platforms with sizeof(time_t) == sizeof(long) we could use time_t there but for
the application programmer that does not help because assigning to a time_t var
first will still be required for portability.
You are right that this is a bug because internally we use time_t and at least
for Windows we will evntually run into problems.
Back in 2003 we went with long int because that is on all 32 bit platforms
sufficient to express OpenPGP timestamps which are 32 bit. Fortunately on
almost all 64 bit Unix platforms a long int is 64 bit and would also allow us to
express timestamps after 2106 and avoid ABI problems due to different time_t
like we have with off_t. Later, when we came up with gpgsm we gave up our hope
for a 64 bit time_t on 32 bit glibc systems and started to use a string instead
of a scalar. With 64 bit Windows things got even more complicated becuase tehre
a long is still 32 bit. Thus there is no clear way forward even if we decide to
break the ABI: Use time_t or a string?