Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems

2023-04-21 Thread Uwe Kleine-König

Hello Russ,

On 4/20/23 19:40, Russ Allbery wrote:

Uwe Kleine-König  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



Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems

2023-04-20 Thread Uwe Kleine-König
Package: lintian
Version: 2.116.3
Severity: normal
Tags: patch
X-Debbugs-Cc: uklei...@debian.org

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



Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

2021-03-25 Thread Uwe Kleine-König
Hello,

On Wed, Mar 24, 2021 at 09:59:59AM +0100, Christoph Biedl wrote:
> Felix Lechner wrote...
> 
> > By the way, the suggestion behind this bug may not be implemented
> > anytime soon. It would cause Lintian's output to change over time
> > (same Lintian version on same package). Such tags are hard to test in
> > Lintian's test suite.
> 
> That argument seems fairly weird to me: Abandon or deny features because
> they are difficult to test. By the way, to test behaviour over time,
> faketime(1) serves me good enough. But that's your design decision.

Just to make this suggestion more obvious as I got (and needed) this
hint:

A sensible date to fake (or compare to) would probably be the changelog
date. Then the output doesn't vary over time and we also don't get bad
positives for old packages.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Bug#970106: lintian-info.1.gz is a dangling symlink

2020-09-12 Thread Uwe Kleine-König
Hello Felix,

thanks for looking into my bug (even before I reported it :-)

On 9/11/20 9:46 PM, Felix Lechner wrote:
> On Fri, Sep 11, 2020 at 12:15 PM Uwe Kleine-König  wrote:
>>
>> man: warning: /usr/share/man/man1/lintian-info.1.gz is a dangling symlink
> 
> Thanks for reporting this. It was fixed earlier this morning:
> 
> https://salsa.debian.org/lintian/lintian/-/commit/0cb2170036d65a28afd669ea894b319709a12e6f
> 
> Closing this bug.

I'm a bit surprised. In my bubble bugs are closed once the fix is in an
apt installable package. Setting the pending flag seems appropriate to
me instead (and I'm a bit annoyed about myself to not have set it with
my report).

Best regards
Uwe



Bug#970106: lintian-info.1.gz is a dangling symlink

2020-09-11 Thread Uwe Kleine-König
Package: lintian
Version: 2.94.0
Severity: normal

Hello,

$ man lintian-info
man: warning: /usr/share/man/man1/lintian-info.1.gz is a dangling symlink
No manual entry for lintian-info
See 'man 7 undocumented' for help when manual pages are not available.

I see this is already fixed in git[1], so just report this bug for
others who hit this problem to locate it quicker.

Best regards
Uwe

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/0cb2170036d65a28afd669ea894b319709a12e6f

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 
'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35-2
ii  bzip2   1.0.6-9.2~deb10u1
ii  diffstat1.62-1
ii  dpkg1.19.7
ii  dpkg-dev1.19.7
ii  file1:5.35-4+deb10u1
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.64-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.23-1
ii  libcpanel-json-xs-perl  4.19-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.19.7
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004000-1
ii  liblist-compare-perl0.53-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.003004-2
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.017+ds-1
ii  libsereal-encoder-perl  4.017+ds-1
ii  libtext-glob-perl   0.10-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.03-4+b1
ii  man-db  2.8.5-2
ii  patchutils  0.3.4-2
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-3
ii  unzip   6.0-23+deb10u1
ii  xz-utils5.2.4-1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-2
ii  libtext-template-perl  1.55-1

-- no debconf information



Bug#970105: lintian-info -t stopped working

2020-09-11 Thread Uwe Kleine-König
Package: lintian
Version: 2.93.0
Severity: normal

Hello,

I just updated to lintian 2.93.0 (from 2.82.0) and found that
lintian-info isn't working any more as before:

$ lintian-info -t systemd-service-file-missing-install-key
Unknown option: t
error parsing options

The changelog for 2.92.0 has:

* Split bin/lintian-info into separate annotate-lintian-hints and 
explain-lintian-tags.

Obviously this was an API-changer. :-\

Maybe lintian-info can be made a wrapper around the two new commands
with a compatible API or if this isn't considered sensible it can better
be removed.

Best regards
Uwe

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 
'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35-2
ii  bzip2   1.0.6-9.2~deb10u1
ii  diffstat1.62-1
ii  dpkg1.19.7
ii  dpkg-dev1.19.7
ii  file1:5.35-4+deb10u1
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.64-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.23-1
ii  libcpanel-json-xs-perl  4.19-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.19.7
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004000-1
ii  liblist-compare-perl0.53-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.003004-2
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.017+ds-1
ii  libsereal-encoder-perl  4.017+ds-1
ii  libtext-glob-perl   0.10-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.03-4+b1
ii  man-db  2.8.5-2
ii  patchutils  0.3.4-2
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-3
ii  unzip   6.0-23+deb10u1
ii  xz-utils5.2.4-1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-2
ii  libtext-template-perl  1.55-1

-- no debconf information



Bug#892255: lintian: orig-tarball-missing-upstream-signature with signed .tar

2018-03-08 Thread Uwe Kleine-König
Hello Chris,

thanks for your quick action

On Thu, Mar 08, 2018 at 06:10:15AM +, Chris Lamb wrote:
> tags 892255 + pending
> thanks
> 
> Fixed in Git, pending upload:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d951d71b164f99c287c4e244eaa15f306e7cb703

Note there are some dragons (from #debian-devel):

1520499444 < Viiru> ukleinek: So upstream is providing multiple
different compressed files and only one signature or some such?
1520499454 < ukleinek> Viiru: ack
1520499460 < Viiru> ukleinek: Do note that this scheme assumes that your
decompressor is not an attack vector.
1520499484 < Viiru> (gpg itself is also obviously an attack vector, but
that is unavoidable)
1520499494 < jcristau> (and sigs for uncompressed tarballs seem like a
bad idea regardless)
1520499567 < Viiru> I'd suggest educating upstream instead of trying to
make this scheme work.

And with my addition of the .tar.asc I broke the upload processing.
(It's not yet entirely clear to me if I added the .tar.asc in a wrong
way or if it's mere presence was the problem.)

Best regards
Uwe


signature.asc
Description: PGP signature


Bug#892255: lintian: orig-tarball-missing-upstream-signature with signed .tar

2018-03-07 Thread Uwe Kleine-König
Package: lintian
Version: 2.5.78
Severity: normal

Hello,

uwe@taurus:~/debpkg/microcom$ xzcat microcom_2017.03.0.orig.tar.xz | gpg 
--verify microcom_2017.03.0.orig.tar.asc -
gpg: Signature made Tue 06 Mar 2018 02:21:38 PM CET
gpg:using RSA key 7E722A169018ACFF3E74A40BC1FC1478ADCAEC09
gpg: Good signature from "Uwe Kleine-König <u...@kleine-koenig.org>" [ultimate]
gpg:         aka "Uwe Kleine-König <uklei...@strlen.de>" [ultimate]
gpg:     aka "Uwe Kleine-König <uklei...@debian.org>" [ultimate]
gpg: aka "Uwe Kleine-König <uwe@kleine-könig.de>" [ultimate]
gpg: aka "Uwe Kleine-König <uklei...@lug-freiburg.de>" 
[ultimate]
gpg: aka "Uwe Kleine-König <u.kleine-koe...@pengutronix.de>" 
[ultimate]
Primary key fingerprint: 0D25 11F3 22BF AB1C 1580  266B E2DC DD91 3266 9BD6
 Subkey fingerprint: 7E72 2A16 9018 ACFF 3E74  A40B C1FC 1478 ADCA EC09
uwe@taurus:~/debpkg/microcom$ grep microcom_2017.03.0.orig.tar.asc 
microcom_2017.03.0-1_source.changes
 f26feeaf212c5be8fa203f2102ac68024ab4cda0010f0b84c8a4415fd9c6471d 310 
microcom_2017.03.0.orig.tar.asc
 bea45ee0c144df466f1340ea45771353e6aa5e49 310 microcom_2017.03.0.orig.tar.asc
 918dc12abfcb768c5563351a21b144f6 310 - - microcom_2017.03.0.orig.tar.asc
uwe@taurus:~/debpkg/microcom$ lintian microcom_2017.03.0-1_source.changes
W: microcom changes: orig-tarball-missing-upstream-signature 
microcom_2017.03.0.orig.tar.xz

It would be great if lintian considered a signature on the extracted
orig.tar that is shipped in the changes file.

This is (slightly) related to https://bugs.debian.org/882694 .

Best regards
Uwe

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), 
(500, 'stable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils  2.30-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.2-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-5
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information