bug#64937: closed ("who" reports funny dates)

[GNU bug Tracking System]

Your message dated Sat, 29 Jul 2023 17:30:27 -0700
with message-id <25d7fdc0-bed9-154d-0828-a1578ab0eb7e@cs.ucla.edu>
and subject line Re: bug#64937: "who" reports funny dates
has caused the debbugs.gnu.org bug report #64937,
regarding "who" reports funny dates
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
64937: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64937
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> "who" reports funny dates
>
>
>
>
> Date: 
>
> Sat, 29 Jul 2023 18:41:14 +0200
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13)
>
>
>
>
> A 32-bit "who" program reports funny login dates:
>
> ,----
> | $ file src/who
> | src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), 
> dynamically linked, interpreter /lib/ld-linux.so.2, 
> BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0, 
> with debug_info, not stripped
> | $ src/who
> | sven     tty1         133589088-06-27 20:29
> | sven     pts/0        121346977-03-14 05:00 (:0)
> | sven     tty2         50067723-10-30 01:10
> | sven     pts/1        3442548-06-12 17:26 (:0)
> `----
>
> This is with current coreutils git (commit 3cb862ce5f1) configured with
> "CC=gcc -m32" on Debian sid/amd64, but the same issue can also be seen
> on plain i386.  Originally reported by Jakub Wilk in
> https://bugs.debian.org/1027135, and I noticed it myself after upgrading
> an ancient machine to Debian 12 today.
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#64937: "who" reports funny dates Date: Sat, 29 Jul 2023 17:30:27 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 2023-07-29 12:44, Pádraig Brady wrote:

I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
which is what glibc uses to force the smaller time types.
However that didn't fix the issue, so I'll need to look a bit more,
and how to get only utmp access restricted to 32 bit types.

I looked into that, and installed the attached patches into Gnulib and Coreutils respectively; these should work around the problem so I'll boldly close the bug report.

These patches are quite a hack, though, and (obviously) stop working after the year 2038.

What's Debian's and/or Fedora's plan for fixing <utmp.h>/<utmpx.h>'s Y2038 bugs? (Or is the idea to remove the <utmp.h></utmpx.h> API before 2038? :-)

See:

https://lwn.net/Articles/925068/

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs

0001-readutmp-work-around-glibc-utmpx-bug.patch
Description: Text Data

0001-build-update-gnulib-submodule-to-latest.patch
Description: Text Data

--- End Message ---