asn1_string_to_time_t: Use timegm on FreeBSD.

[bsdjhb]

FreeBSD does not provide a global timezone variable containing the
offset to UTC. Instead, FreeBSD's libc includes a legacy timezone
function dating back to Version 7 AT&T UNIX. As a result,
asn1_string_to_time_t currently fails to compile on FreeBSD as it
subtracts a function from a time_t value:

../crypto/asn1/a_time.c:625:37: error: invalid operands to binary expression ('time_t' (aka 'long') and 'char *(int, int)')
timestamp_utc = timestamp_local - timezone;
~~~~~~~~~~~~~~~ ^ ~~~~~~~~
1 error generated.

However, FreeBSD's libc does include a non-standard (but widely
available) timegm function which converts a struct tm directly to a
UTC time_t value. Use this on FreeBSD instead of mktime.

Checklist

• documentation is added or updated
• tests are added or updated

[paulidale]

Question: should 1.1.1 get this fix too?

[kaduk]

AFAICT the function was only added by #17645 and is not present on 1.1.1 or even 3.0.

[bsdjhb]

BTW, I had a thought this morning: even though timegm isn't standardized, you might consider using it when it is available (which it should be on BSD's, Linux, and macOS at least). The existing logic of using mktime + subtraction against timezone has some edge cases with DST transitions that are correctly handled by timegm (e.g. if the time in tm is in a different part of the year as far as DST rules as when tzset was last called then the result can be incorrect). This can occur even for requests for the current time in a long-running daemon whose runtime spans DST transitions. A portable alternative to using timegm is to use tzset to temporarily override TZ while calling mktime. That alternative has other issues though (not thread-safe and some systems leak memory in setenv due to the fact that pointers returned from getenv are supposed to be valid "forever").

[mattcaswell]

If you can suggest a more encompassing "ifdef" for the USE_TIMEGM define then I'd be open to include it, i.e. basically use mktime on a platform if we don't know for sure that timegm is supported. Probably want to include a comment briefly explaining why timegm is preferred where available. I'd do that in a separate PR though since this one has already achieved approval.

[openssl-machine]

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

[bsdjhb]

I think a separate PR makes sense. I will see if I can come up with a compile-time configure test for timegm.

[t8m]

I will see if I can come up with a compile-time configure test for timegm.

We do not do compile-time configure tests currently. I'd suggest instead just enabling this on glibc and macos.

[mattcaswell]

Pushed. Thanks.