Archive value is out of time_t range

[Antonio T. sagitter]

Hi all.

rpmuncompress is failing in Rawhide i686 architecture only with:

/usr/bin/tar: Archive value 4027676192 is out of time_t range 
-2147483648..2147483647
/usr/bin/tar: 
icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js: 
implausibly old time stamp 1969-12-31 23:59:59
...
(https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)

If it was an archive issue, it should happen in all architectures.
Anyone know why this occurs?

Best,
-- 
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/

[Mamoru TASAKA]

Antonio T. sagitter wrote on 2022/06/02 23:33:
>  Hi all.
>  
>  rpmuncompress is failing in Rawhide i686 architecture only with:
>  
>  /usr/bin/tar: Archive value 4027676192 is out of time_t range -2147483648..2147483647
>  /usr/bin/tar: icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js:
> implausibly old time stamp 1969-12-31 23:59:59
>  ...
>  (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
>  
>  If it was an archive issue, it should happen in all architectures.
>  Anyone know why this occurs?
>  
>  Best,
>   
Perhaps it is 32 bit architecture. Actually:

[tasaka1@localhost icecat-91.10.0]$ ls -al
extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js
-rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29  2114
extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js

This is above year 2038. (Anyway the timestamp on this file seems strange.)

Regards,
Mamoru

[Antonio T. sagitter]

Hi Mamoru.

Could be useful changing timestamp of that file when i create the IceCat 
source archive to resolve this problem?

On 6/2/22 16:50, Mamoru TASAKA wrote:
>  Antonio T. sagitter wrote on 2022/06/02 23:33:
> > Hi all.
> >
> > rpmuncompress is failing in Rawhide i686 architecture only with:
> >
> > /usr/bin/tar: Archive value 4027676192 is out of time_t range 
> > -2147483648..2147483647
> > /usr/bin/tar: 
> > icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js: 
> > implausibly old time stamp 1969-12-31 23:59:59
> > ...
> > (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
> >
> > If it was an archive issue, it should happen in all architectures.
> > Anyone know why this occurs?
> >
> > Best,
> >
>  
>  Perhaps it is 32 bit architecture. Actually:
>  
>  [tasaka1@localhost icecat-91.10.0]$ ls -al 
>  extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js
>  -rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29  2114 
>  extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js
>  
>  This is above year 2038. (Anyway the timestamp on this file seems strange.)
>  
>  Regards,
>  Mamoru
>  _______________________________________________
>  
-- 
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/

[Stephen Smoogen]

On Thu, 2 Jun 2022 at 10:34, Antonio T. sagitter <sagitter(a)fedoraproject.org&gt;
wrote:

>  Hi all.
>
>  rpmuncompress is failing in Rawhide i686 architecture only with:
>
>  /usr/bin/tar: Archive value 4027676192 is out of time_t range
>  -2147483648..2147483647
>  /usr/bin/tar:
>  icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js:
>  implausibly old time stamp 1969-12-31 23:59:59
>  ...
>  (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
>
>  If it was an archive issue, it should happen in all architectures.
>  Anyone know why this occurs?
>
>  
So something seems odd with that file or some sort of conversion and I am
guessing it is a 64bit to 32 bit conversion of some sort.  [The other
architecture it might happen on would be arm32bit which is not in rawhide
anymore.] However those dates seem really weird to the point of a corrupt
archive or something before that part causing an overflow. Again it is
probably a 32 bit/64 bit
```
$ date --date='@4027676192'
Sun 18 Aug 10:56:32 EDT 2097
```
on a 64 bit architecture and on a 32 bit would wrap to -267291104 (?? I
think I got that right). The error I see above is that should be a time
stamp of 'Thu 13 Jul 04:28:16 EDT 1961'



>  Best,
>  --
>  ---
>  Antonio Trande
>  Fedora Project
>  mailto: sagitter(a)fedoraproject.org
>  GPG key: 0xCC1CFEF30920C8AE
>  GPG key server: https://keyserver1.pgp.com/
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Petr Pisar]

V Thu, Jun 02, 2022 at 04:33:23PM +0200, Antonio T. sagitter napsal(a):
>  Hi all.
>  
>  rpmuncompress is failing in Rawhide i686 architecture only with:
>  
>  /usr/bin/tar: Archive value 4027676192 is out of time_t range
>  -2147483648..2147483647
>  /usr/bin/tar:
>  icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js:
>  implausibly old time stamp 1969-12-31 23:59:59
>  ...
>  (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
>  
>  If it was an archive issue, it should happen in all architectures.
>  Anyone know why this occurs?
>   
I don't know tar format, so I cannot tell whether it's a broken archive
or
not. Definitely the time stamps are unreal.

tar NEWS files mentions:

  On 32-bit hosts, 'tar' now assumes that an incoming time stamp T in
  the range 2**31 <= T < 2**32 represents the negative time (T -
  2**32).  This behavior is nonstandard and is not portable to 64-bit
  time_t hosts, so 'tar' issues a warning.


I'm able to reproduce it with "tar tjf icecat-91.10.0-rh2.tar.bz2
>/dev/null"
where tar comes from tar-1.34-3.fc36.i686 and icecat-91.10.0-rh2.tar.bz2 from
currect icecat dist-git sources (SHA512 =
9b46b67d5a6206c491aa9285a361170420cc0b421acd46be8e658b39a26b75c07e89d201525fcbde7bec125699d52970f0fb3d5a7a00dad8408e2a1201ae2f9a).

tar internally stores time stamps in a variable of time_t type. That type is
by default 32-bit on i686 architecture. tar program indeed reports an error if
it cannot internally represent the values read from a tar achive headers.

A possible fix should be compile tar with -D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64 CFLAGS:

$ cat main.c
#include <stdio.h>
#include <time.h>
int main(void) {
    printf("sizeof(time_t)=%d\n", sizeof(time_t));
    return 0;
}

$ gcc -m32 main.c
$ ./a.out
sizeof(time_t)=4

$ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
$ ./a.out
sizeof(time_t)=8

I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
proposed solution would require rebuilding in the same way all libraries which
tar uses and which pass time_t and similar types in their interface. That
would probably break other packages. So maybe more realisic fix will enhancing
tar to ignore these time stamps when unpacking an archive.

-- Petr

[Antonio T. sagitter]

https://bugzilla.redhat.com/show_bug.cgi?id=2092964

On 6/2/22 17:46, Petr Pisar wrote:
>  I recommend you to file a bug against tar in Fedora's Bugzilla.
> However, this
>  proposed solution would require rebuilding in the same way all libraries which
>  tar uses and which pass time_t and similar types in their interface. That
>  would probably break other packages. So maybe more realisic fix will enhancing
>  tar to ignore these time stamps when unpacking an archive.
>  
>  -- Petr
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>  
-- 
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/

[Miroslav Lichvar]

On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
>  $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
>  $ ./a.out
>  sizeof(time_t)=8
>  
>  I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
>  proposed solution would require rebuilding in the same way all libraries which
>  tar uses and which pass time_t and similar types in their interface. That
>  would probably break other packages. 
Now that the kernel and glibc have this feature, would it make sense
to change the global CFLAGS to build everything with 64-bit time_t on
all currently supported 32-bit archs? If not now, how close to the
32-bit overflow in 2038?

It's not just about keeping current time and file timestamps. There
are applications/libraries that calculate future dates and overflows
can lead to serious issues.

Switching to 64-bit time_t may require some patching, e.g. when the
code assumes sizeof(long) == sizeof(time_t).

-- 
Miroslav Lichvar

[Petr Pisar]

V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
>  On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
>  > $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
>  > $ ./a.out
>  > sizeof(time_t)=8
>  > 
>  > I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
>  > proposed solution would require rebuilding in the same way all libraries which
>  > tar uses and which pass time_t and similar types in their interface. That
>  > would probably break other packages.
>  
>  Now that the kernel and glibc have this feature, would it make sense
>  to change the global CFLAGS to build everything with 64-bit time_t on
>  all currently supported 32-bit archs? If not now, how close to the
>  32-bit overflow in 2038?
>   
That would be ideal, but I worry that Fedora will rather drop i686 archicture
than change ABI of all packages.

Most of the uses cases for i686 is a multilib for proprietary software.
Changing ABI would break it. How much of that software will be relevant in 15
years?

We dropped 32-bit ARM because we were unable to build the software (in
a reasonable time). As software becomes hungrier (and less tested on 32 bits), we
start observing the same problem in i686.

-- Petr

[Panu Matilainen]

On 6/6/22 13:29, Petr Pisar wrote:
>  V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
> > On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
> >> $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
> >> $ ./a.out
> >> sizeof(time_t)=8
> >>
> >> I recommend you to file a bug against tar in Fedora's Bugzilla. However,
> this
> >> proposed solution would require rebuilding in the same way all libraries which
> >> tar uses and which pass time_t and similar types in their interface. That
> >> would probably break other packages.
> >
> > Now that the kernel and glibc have this feature, would it make sense
> > to change the global CFLAGS to build everything with 64-bit time_t on
> > all currently supported 32-bit archs? If not now, how close to the
> > 32-bit overflow in 2038?
> >
>  That would be ideal, but I worry that Fedora will rather drop i686 archicture
>  than change ABI of all packages.
>  
>  Most of the uses cases for i686 is a multilib for proprietary software.
>  Changing ABI would break it. How much of that software will be relevant in 15
>  years? 
The way glibc compatibility works, existing binaries will continue to 
get the ABIs they were built with once upon a time and continue to work 
like nothing ever happened. Except of course that time will wrap around 
eventually.

Or at least that's how the theory goes, IIRC the time_t transition has 
its own peculiarities that other similar transitions haven't had.

>  
>  We dropped 32-bit ARM because we were unable to build the software (in
>  a reasonable time). As software becomes hungrier (and less tested on 32 bits), we
>  start observing the same problem in i686. 
Yup, but i686 can be easily built on x86_64 which alleviates things 
quite a bit.

	- Panu -

[Petr Pisar]

V Mon, Jun 06, 2022 at 02:40:50PM +0300, Panu Matilainen napsal(a):
>  On 6/6/22 13:29, Petr Pisar wrote:
>  > V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
>  > > On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
>  > > > $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
>  > > > $ ./a.out
>  > > > sizeof(time_t)=8
>  > > > 
>  > > > I recommend you to file a bug against tar in Fedora's Bugzilla.
> However, this
>  > > > proposed solution would require rebuilding in the same way all libraries
> which
>  > > > tar uses and which pass time_t and similar types in their interface. That
>  > > > would probably break other packages.
>  > > 
>  > > Now that the kernel and glibc have this feature, would it make sense
>  > > to change the global CFLAGS to build everything with 64-bit time_t on
>  > > all currently supported 32-bit archs? If not now, how close to the
>  > > 32-bit overflow in 2038?
>  > > 
>  > That would be ideal, but I worry that Fedora will rather drop i686 archicture
>  > than change ABI of all packages.
>  > 
>  > Most of the uses cases for i686 is a multilib for proprietary software.
>  > Changing ABI would break it. How much of that software will be relevant in 15
>  > years?
>  
>  The way glibc compatibility works, existing binaries will continue to get
>  the ABIs they were built with once upon a time and continue to work like
>  nothing ever happened. Except of course that time will wrap around
>  eventually.
>   
I believe that glibc payed a special attention to provide both ABIs. But that
does not apply to other libraries. Maybe it's not so important problem.
Proprietary software tends to bundle the libraries, externally relying only on
kernel and glibc.

>  Or at least that's how the theory goes, IIRC the time_t
> transition has its
>  own peculiarities that other similar transitions haven't had.
>  
>  > 
>  > We dropped 32-bit ARM because we were unable to build the software (in
>  > a reasonable time). As software becomes hungrier (and less tested on 32 bits), we
>  > start observing the same problem in i686.
>  
>  Yup, but i686 can be easily built on x86_64 which alleviates things quite a
>  bit.
>   
Wasn't that also said about ARMv7 on AArch64?

-- Petr

[Ralf Corsépius]

Am 06.06.22 um 16:38 schrieb Petr Pisar:

>  I believe that glibc payed a special attention to provide both ABIs.
> But that
>  does not apply to other libraries. Maybe it's not so important problem.
>  Proprietary software tends to bundle the libraries, externally relying only on
>  kernel and glibc. 
How about dlopened libraries? I'd assume these can become problematic.

Ralf

[Florian Weimer]

* Ralf Corsépius:

>  Am 06.06.22 um 16:38 schrieb Petr Pisar:
>
> > I believe that glibc payed a special attention to provide both
> > ABIs. But that does not apply to other libraries. Maybe it's not so
> > important problem.  Proprietary software tends to bundle the
> > libraries, externally relying only on kernel and glibc. 
(X libraries, Motif, glib are usually not bundled, either, and there are
a couple mor examples.  It's likely that there is at least some time_t
or struct timeval/timespec exposre in all of these otherwise ABI-stable
libraries.)

>  How about dlopened libraries? I'd assume these can become
> problematic. 
dlsym calls need to be taught to use the time64 aliases.  Symbol
versioning isn't used.

Maybe we could add a time64 version of dlsym and dlvsym that knows about
the aliased symbols, but we really shouldn't be doing new development
work for 32-bit architectures.  It doesn't benefit Fedora, and most
embedded 32-bit users do not use glibc, either.  However, there was a
strong push from a few interested parties who funded the initial
development (and at least one party is still involved and addresses any
fallout from the changes).  I'm not really happy how things turned out,
but at least there is no immediate harm to Fedora's i686 compatibility
packages (beyond the occasional bug, but as I mentioned, someone is
still around to fix them).

Thanks,
Florian