Re: Bug#1068017: util-linux: please ship liblastlog2 packages

[Colin Watson <cjwatson@debian.org>]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.
> > 
> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.
> > 
> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.
> > 
> > Does this seem right?
> 
> Answering my own question, not quite.
> 
> Apparently, traditionally we have:
> 
> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 
> 
> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.
> 
> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.

I think I'm OK with configuring openssh with --disable-lastlog, although
I haven't tested it.  I think we should at least roughly coordinate this
so that there isn't a long period when testing users have no last login
information at all, though, so let me know when you'd like me to do
that.

It might be a good idea to wait until the main bulk of the 64-bit time_t
transition is over so that we have a little more reasonable expectation
of changes migrating to testing somewhat promptly.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]