[packages/ca-certificates] Rel 6; make sure we don't include expired certs

[Jan Palus]

On 03.10.2021 08:49, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> W dniu 01.10.2021 o 20:27, Jakub Bogusz pisze:
> > On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote:
> >> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69
> >> Author: Arkadiusz Miśkiewicz <arekm at maven.pl>
> >> Date:   Fri Oct 1 12:36:07 2021 +0200
> >>
> >>     Rel 6; make sure we don't include expired certs
> > 
> > Unfortunately ix86 `date` doesn't know y2038+...
> > 
> > | date: invalid date 'Oct 25 08:25:55 2043 GMT'
> > 
> > 
> 
> Jan, what was the reason behind  --disable-year2038 in coreutils?
> 
> Enabling that and date on ix86 parses such date correctly (with
> coreutils 9.0).

The primary effect of y2038 handling is change of time_t from 32bit to
64bit which breaks abi compatibility with external libraries that were
not compiled with y2038. If there's any library call that involves
time_t either directly (argument/return value) or indirectly (member of
publicly defined struct) then it will cause incorrect results if caller
and callee use different time_t size. That's exactly what happened in
wget interacting with libmetalink:

https://savannah.gnu.org/bugs/index.php?61140

whether any such situation is possible in coreutils -- don't know, but
to be on the safe side I prefer to disable it for the time being.
Especially that y2038 handling is still a moving target. ie even if you
don't use y2038 glibc requires you to be aware of internal mechanisms to
handle it in order to use api correctly:

https://github.com/systemd/systemd/issues/20564

I would say y2038 is either all or nothing. At some point we'd need
rebuild everything with 64bit time_t (and keep our fingers crossed that
abi breakages do not happen too often on builders during the process of
transition).