Re: On time64 and Large File Support

[Richard W.M. Jones]

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