On 3/1/23 17:38, Eric Blake wrote: > [replying to the original post, because I'm not sure where else in the > more recent activity on this thread would be more appropriate] > > On Fri, Nov 11, 2022 at 08:38:18AM +0000, Sam James wrote: >> Hi all, >> >> In Gentoo, we've been planning out what we should do for time64 on glibc [0] >> and concluded that we need some support in glibc for a newer option. I'll outline >> why below. >> > ... >> >> Indeed, the gnulib version of change #2 is exactly how we ended up with >> wget/gnutls breaking [1]. I feel this shows that the only approach >> "supported" by glibc right now is untenable. > >> [1] https://bugs.gentoo.org/828001 > > Now Fedora is also being hit by the gnutls ABI change due to time_t in > public interfaces being silently changed. From an IRC conversation I > had with Dan Berrange and Rich Jones (I think Rich mean i686 below): > > rjones (IRC): oh wow, the certificates created on i696 are not quite right ..... > Validity: > Not Before: Sat Sep 05 00:23:57 UTC 2703 > Not After: Sun Sep 06 00:23:57 UTC 2703 > just a few years too early > i think this is looking like a gnutls regression, downgrading gnutls makes it work > ... > rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc > gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage > but the very same call done from a demo program returns the right answer > ... > OMG, gnulib-- has silently changed gnutls to use 64-bit time_t > ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters > so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t > this is utterly insane Time to do a mass rebuild and mass SONAME bump of everything shipped as 32-bits? -- Sincerely, Demi Marie Obenour (she/her/hers)