Re: On time64 and Large File Support

"Richard W.M. Jones via Libc-alpha" <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha,gmane.comp.sysutils.autoconf.general
Message-ID <[email protected]>
On Wed, Mar 01, 2023 at 04:38:59PM -0600, 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):
> 
> <danpb> rjones (IRC): oh wow, the certificates created on i696 are not quite right .....
> <danpb>         Validity:
> <danpb>                 Not Before: Sat Sep 05 00:23:57 UTC 2703
> <danpb>                 Not After: Sun Sep 06 00:23:57 UTC 2703
> <danpb> just a few years too early
> <danpb> i think this is looking like a gnutls regression,   downgrading gnutls makes it work
> ...
> <danpb> rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc
> <danpb> gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage
> <danpb> but the very same call done from a demo program returns the right answer
> ...
> <danpb> OMG, gnulib-- has silently changed gnutls to use 64-bit time_t
> <danpb> ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters
> <danpb> so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t
> <danpb> this is utterly insane

For context, we first noticed that qemu tests were failing on i686
with lots of TLS-related errors.  qemu uses GnuTLS.  eg:

Summary of Failures:
124/658 qemu:unit / test-crypto-tlscredsx509                                      ERROR           2.42s   killed by signal 6 SIGABRT
202/658 qemu:unit / test-io-channel-tls                                           ERROR           1.47s   killed by signal 6 SIGABRT
125/658 qemu:unit / test-crypto-tlssession                                        ERROR           8.74s   killed by signal 6 SIGABRT
 32/658 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test                   ERROR          92.96s   killed by signal 6 SIGABRT
 34/658 qemu:qtest+qtest-i386 / qtest-i386/migration-test                         ERROR          96.63s   killed by signal 6 SIGABRT
 37/658 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test                     ERROR          104.25s   killed by signal 6 SIGABRT

Dan Berrange investigated and found the ABI change in GnuTLS causing
this, since GnuTLS headers export public interfaces using time_t.
Which in turn is caused by a change in gnulib enabling _TIME_BITS=64

This seems to have started in GnuTLS 3.8.0.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.