Subject: lintian: Warn for 32bit time_t / Y2038 problems

From: Uwe Kleine-König <[email-masked]>
Date: Thu, 20 Apr 2023 10:23:33 +0200

Package: lintian
Version: 2.116.3
Severity: normal
Tags: patch
X-Debbugs-Cc: [email-masked]

Hello,

to help making package maintainers aware of the Y2038 problem I
implemented a lintian check that triggers if a symbol from glibc is used
that uses a 32bit time_t type.

The code is available in a MR on the lintian packaging repository at
https://salsa.debian.org/lintian/lintian/-/merge_requests/463

Thanks for considering
Uwe

---

From: Russ Allbery <[email-masked]>
Date: Thu, 20 Apr 2023 10:40:03 -0700

> https://salsa.debian.org/lintian/lintian/-/merge_requests/463

I have no objections to adding this as an experimental tag.  The detection
component to determine the size of the problem is certainly useful.

However, more generally, do we know yet how Debian intends to handle this
transition?  Changing to 64-bit time_t will change the ABI of shared
libraries and thus is not a safe change to make without an SONAME
transition unless we're going to do something architecture-wide, such as
introducing a new version of the i386 architecture where everything is
built with 64-bit time_t.

I know there's a caution in there already about this, but I'm concerned
about maintainers acting on this tag by blindly adding the Autoconf flags
or macros to switch to 64-bit time_t and thus creating numerous
uncoordinated shared library transitions, possibly without knowing they
need to change the SONAME.  And it's not clear to me that we want to do
the migration by changing the SONAME of every shared library in Debian
that uses time_t has part of its public API (which is a lot of them).

I know of at least one package (and I am certain that there will be more)
where this change will also change on-disk data formats in a way that is
not backward-compatible, which is even less safe.

The current caution should probably be stronger: it's only safe to do this
transition for leaf packages that do not call any shared library functions
with time_t parameters and that do not use time_t in any binary data
structures stored on disk (possibly including caches, depending on the
situation).  In other situations, this is something that's going to
require some distribution-wide coordination that I don't think we've
started yet.

-- 
Russ Allbery ([email-masked])              <https://www.eyrie.org/~eagle/>

---

From: Uwe Kleine-König <[email-masked]>
Date: Fri, 21 Apr 2023 15:17:23 +0200

Hello Russ,

On 4/20/23 19:40, Russ Allbery wrote:
> component to determine the size of the problem is certainly useful. >

I'm not aware of a decision how this should be handled. The lintian tag 
is a step to measure the actual problem by identifying the packages that 
need some love. Also independent of a global effort I expect that a big 
number of leaf packages can simply be converted. Further it probably 
helps to spread awareness and maintainers might tackle the update if a 
soname bump has to be done for other reasons anyhow.

> that uses time_t has part of its public API (which is a lot of them).

I wonder if there is a list already of such libs.

> require some distribution-wide coordination that I don't think we've

I expanded the tag's description to point out that converting to time64 
probably needs some care. If you have a concrete proposal to improve it 
further, I'm open for feedback.

Best regards
Uwe

---

From: Paul Wise <[email-masked]>
Date: Sat, 22 Apr 2023 09:10:10 +0800

On Fri, 2023-04-21 at 15:17 +0200, Uwe Kleine-König wrote:

> I'm not aware of a decision how this should be handled.

There was some discussion on debian-arm about this. Initially the plan
was new architectures, but more analysis has lead towards renaming
affected library packages instead. I think the folks involved intend to
bring the plan to debian-devel at some point.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise