Subject: lintian: Warn for 32bit time_t / Y2038 problems
Date: Thu, 20 Apr 2023 10:23:33 +0200
Package: lintian
Version: 2.116.3
Severity: normal
Tags: patch
X-Debbugs-Cc: [email protected]
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
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Thu, 20 Apr 2023 17:42:03 GMT) (full text, mbox, link).
Uwe Kleine-König <[email protected]> writes:
> 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
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 protected]) <https://www.eyrie.org/~eagle/>
Acknowledgement sent
to Uwe Kleine-König <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Fri, 21 Apr 2023 13:21:06 GMT) (full text, mbox, link).
Hello Russ,
On 4/20/23 19:40, Russ Allbery wrote:
> Uwe Kleine-König <[email protected]> writes:
>
>> 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
>
> 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'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.
> 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 wonder if there is a list already of such libs.
> 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.
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
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
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.