[Pkg-freeradius-maintainers] Bug#1095490: util-linux: new optional package to interrogate utmp-format files

[Andrew Bower]

Hi Chris,

Thanks for your reply about the merits of including support for reading
utmp-formatted files. An important technical correction follows below
for any observer reading this thread (mea culpa):

On Sun, Feb 09, 2025 at 07:34:07PM +0100, Chris Hofstaedtler wrote:
> On Sun, Feb 09, 2025 at 08:46:39AM +0000, Andrew Bower wrote:
> > On Sun, Feb 09, 2025 at 01:01:08AM +0100, Chris Hofstaedtler wrote:
> > > On Sat, Feb 08, 2025 at 12:47:05PM +0000, Andrew Bower wrote:
[..]
> > utmp would work past 2038 except on i386 - and for
> > 32-bit architectures that is thanks to the hard work you all did, thank
> > you! The big issue with utmp is the certainty of corruption when
> > accessed by both t64-capable and non t64-capable software.
> 
> TTBOMK the utmp format did not change on any architecture, so it is
> has the year 2038 limitation.

Sorry, I was simply wrong here, so let me correct the record from my
technical error: when I went in to look at the header (potentially with
a view to contributing an importer) I realised I had not actually
checked it and was relying on false memory of what I had inferred it to
be from skimming discussions about why it _couldn't_ be changed,
thinking it had indeed been changed (or rather, how it might have
already changed by virtue of relying on time_t). The limitation does
apply, as you say.

(This was of course a side issue anyway as I was not disputing the merit
of changing from utmp, just access to tooling.)

> > This is just using a private facility and so no one else is writing to
> > the file - it will be y2038-safe if the host is, they are just using the
> > system tool as a reader for that file because it is generally assumed to
> > be present. In fact their risk is upon upgrading the OS from
> > armhf/armel/hppa/m68k/powerpc/sh4 when this file _will_get_corrupted_ -
> 
> How so?

As discussed above, this is indeed incorrect.