Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Sergei Golovan]

Hi Felix,

On Thu, Jul 2, 2020 at 2:22 AM Felix Lechner  wrote:
>
> Hi Sergei,
>
> On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:
> >
> > Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> > so I would say that this warning is spurious.
>
> I am not sure who is right, but the warning is not spurious from the
> perspective of the original requestor. Bug#243158 cited a scenario
> very much like yours as the reason for why the dynamic linker was
> confused.

As far as I can see, it's a link like /usr/lib/foo.so.1.0.0 ->
/usr/lib/somewhere/foo.so.1.0.0
was the concern for bug #243158. Here, Lintian emits a warning for the
link which
points backward (/usr/lib/ have the real file,
/usr/lib//lua have the link).

>
> Those links also never left /usr/lib.

The explanation for breakout-link says that there might be an issue
with multi-arch
(link may point to another architecture), so I'd just check and
wouldn'd show the warning
if both the link and the target are located inside one /usr/lib/.

>
> Like so many bugs in Debian, however, the feature was requested 17
> years ago. At that point, Lua had already been around for ten years
> (having arrived in 1993). Do you know when Lua adopted the current
> shared object hierarchy and resolution method?

I don't know when this layout was introduced in individual packages, I
can see that
it was implemented in dh-lua in 2012.

Cheers!
-- 
Sergei Golovan

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 9:55 PM Russ Allbery  wrote:
>
> I'm not active and don't want to second-guess how
> you're handling things.

Thank you for writing that. I have likewise been reluctant to comment
on the good work of past maintainers.

> But I guess I'll say here that I think the point
> of a linter is externalized good taste.  It's a codification of good
> judgment calls about the way to construct a package.

I actually exercise relatively little judgment, at least by Debian
standards. On the contrary, I try to accommodate every bug filer, but
it is hard. People have so many expectations and styles. And often, my
solutions are not appreciated.

> I should have, and probably the answer is that I didn't read it in any
> detail.

It's never too late. I am happy to change the check, or to drop it
entirely, if you can figure out the original problem. It may involve
tools with which I am unfamiliar.

> That said, I think the way I would have interpreted that bug would have
> been to warn about symlinks inside /usr/lib to outside of /usr/lib.

That seems to be the consensus between Sergei, Chris and myself. It's
also what the check does now.

> looking at it now, I'm not sure what problem that would cause and
> therefore what purpose would be served by warning about it.

I am not sure, either. Perhaps a future bug report will tell.

> In general, I wouldn't assume that all the old bugs are valid or
> interesting.

After some reflection, I found that the most defensible way to close
feature requests is to implement them.

On a personal note, thanks for your book reviews. I serve as a library
commissioner in a town near you, and enjoyed reading them.

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:

>> I'm puzzled by why you would have changed Lintian in response to that
>> bug, given that the reported problem was only with Lintian and was
>> fixed sixteen years ago.

> I am just working through open bugs.

I didn't reply to an earlier discussion where you said something similar
because you're doing a ton of excellent work on Lintian and making a lot
of forward progress.  I'm not active and don't want to second-guess how
you're handling things.  But I guess I'll say here that I think the point
of a linter is externalized good taste.  It's a codification of good
judgment calls about the way to construct a package.  That means judgment
calls about whether a given suggestion is good taste or important always
felt to me like a significant part of the work.

> Why did you not voice your opposition as a maintainer during the past
> seventeen years, or close the bug?

I should have, and probably the answer is that I didn't read it in any
detail.  Lintian always had between 200 and 400 bugs when I was working on
it, and my work style was generally to pick a bug and work on it until I
could close it, rather than going through all of the bugs.  I also
prioritized newer bugs over older bugs.

That said, I think the way I would have interpreted that bug would have
been to warn about symlinks inside /usr/lib to outside of /usr/lib.  On
first glance, I might have thought that might be reasonable, although
looking at it now, I'm not sure what problem that would cause and
therefore what purpose would be served by warning about it.

In general, I wouldn't assume that all the old bugs are valid or
interesting.  I don't think I ever did a great job of triage, particularly
on older stuff.

-- 
Russ Allbery (r...@debian.org)  

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:
>
> I'm puzzled by why you would have changed Lintian in response to that bug,
> given that the reported problem was only with Lintian and was fixed
> sixteen years ago.

I am just working through open bugs. Why did you not voice your
opposition as a maintainer during the past seventeen years, or close
the bug?

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:

>> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
>> so I would say that this warning is spurious.

> I am not sure who is right, but the warning is not spurious from the
> perspective of the original requestor. Bug#243158 cited a scenario very
> much like yours as the reason for why the dynamic linker was confused.

> Those links also never left /usr/lib.

I'm puzzled by why you would have changed Lintian in response to that bug,
given that the reported problem was only with Lintian and was fixed
sixteen years ago.

What problem is this tag trying to address?

-- 
Russ Allbery (r...@debian.org)  

Re: Checking vs. building packages; Lintian's relationship with Dpkg and Debhelper

[Russ Allbery]

Felix Lechner  writes:

> The best outcome would be a simple and logical rule to divide tasks
> between our tools. For example, it could be helpful if Dpkg and
> Debhelper prevent only the creation of packages that cannot be built or
> unpackaged safely.

Why?  If something is in error, preventing the package from building
entirely ensures that the error is fixed.  Linting is optional; I don't
think it makes sense to rely on linting to reject invalid packaages.

> This message was prompted by recent changes in Dpkg which, if you
> haven't noticed, encroach a little bit on Lintian's traditional area of
> expertise. Because Dpkg now fails to build some of Lintian's test
> packages, the tags can no longer be tested and will be removed from
> Lintian.

Seems like a positive development.  Less code for Lintian to maintain,
less code to check, fewer broken packages in the archive... a win all
around.

dpkg has been picking up basic sanity checks for obvious packaging bugs
from Lintian going back to when I was the primary maintainer, so quite a
long time ago now.  That has frequently invalidated some tags and some
Lintian checks, which is a good excuse to happily delete code.  I thought
of it similar to deprecation warnings in a language becoming errors in a
later release as the semantics of the language are tightened, removing
work from linters.

> Like so many things Guillem writes, that is a mischaracterization.

I'm not sure what's going on between you and Guillem (and am not sure I
want to know), but the way you keep sniping at him is uncomfortable to
read and rather off-putting.

-- 
Russ Allbery (r...@debian.org)  

Processed: Bug#964073 marked as pending in lintian

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #964073 [lintian] lintian: Possible false positives for breakout-link for 
Lua modules
Added tag(s) pending.

-- 
964073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Sergei,

On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:
>
> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

I am not sure who is right, but the warning is not spurious from the
perspective of the original requestor. Bug#243158 cited a scenario
very much like yours as the reason for why the dynamic linker was
confused.

Those links also never left /usr/lib.

Like so many bugs in Debian, however, the feature was requested 17
years ago. At that point, Lua had already been around for ten years
(having arrived in 1993). Do you know when Lua adopted the current
shared object hierarchy and resolution method?

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Chris Lamb]

Hi Sergei,

> Since it points to a higher location in the file system, lintian shows a
> warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

Thanks for your report and it sounds like you are right. (Mostly
replying so you don't make changes to your package while you wait for
a fix to land.)


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

dpkg-source: False positive 'points outside source root'

[Felix Lechner]

Control: retitle -1 dpkg-source: False positive 'points outside source root'
Control: severity -1 serious

Hi,

The initial filing said the three packages contained link targets
outside of the package root, but that is not so. This is not right:

dpkg-source: error: pathname
'testsuite-general-1.0/debian/tests/self1' points outside source root

One of the affected test packages is attached to this message.

When issuing the false positive, dpkg-source also exits with status
25. Everything goes away when the patch is applied, but in the
meantime this bug breaks the Lintian testsuite.

Accordingly, I upgraded the severity to prevent migration until the
bug is fixed.

Kind regards
Felix Lechner


testsuite-general_1.0.dsc
Description: Binary data


testsuite-general_1.0.tar.xz
Description: Binary data

Bug#964111: dpkg-source: Uninitialized value $canon_pathname

[Felix Lechner]

Package: dpkg-source
Severity: minor
Tags: patch
X-Debbugs-CC: debian-lint-maint@lists.debian.org

Hi,

The new version of dpkg-source recently caused the failures of three
Lintian tests. All had link targets pointing outside the source root,
which caused the failures, but there was an additional warning:

Use of uninitialized value $canon_pathname in pattern match (m//)
at /usr/share/perl5/Dpkg/Source/Package.pm line 555.

Here are the tests:

checks/files/encoding/testsuite-in-western-encoding
checks/testsuite/national-encoding
checks/testsuite/testsuite-general

The patch below caused the warning to disappear. Thank you for your
hard work on Dpkg.

Kind regards
Felix Lechner

* * *

--- Package.pm2020-07-01 21:35:04.978251308 +
+++ /usr/share/perl5/Dpkg/Source/Package.pm2020-07-01
21:35:42.846687621 +
@@ -552,6 +552,7 @@
 my $canon_newdir = realpath($newdirectory);
 my $check_symlinks = sub {
 my $canon_pathname = realpath($_);
+return unless length $canon_pathname;
 return if $canon_pathname =~ m/^\Q$canon_newdir\E/;

 error(g_("pathname '%s' points outside source root"), $_);

Checking vs. building packages; Lintian's relationship with Dpkg and Debhelper

[Felix Lechner]

Hi,

Lintian's task of checking packages is often affected by the tools
building them. There is an interaction between Dpkg, Debhelper, and
Lintian that can at times be complex. I would like to initiate a
discussion among the Lintian maintainers about the proper boundaries
for each tool.

The best outcome would be a simple and logical rule to divide tasks
between our tools. For example, it could be helpful if Dpkg and
Debhelper prevent only the creation of packages that cannot be built
or unpackaged safely.

This message was prompted by recent changes in Dpkg which, if you
haven't noticed, encroach a little bit on Lintian's traditional area
of expertise. Because Dpkg now fails to build some of Lintian's test
packages, the tags can no longer be tested and will be removed from
Lintian.

As an example, I will pick the way Dpkg started to examine autopkgtest
files. On the surface, it seems like I may be responsible for it. The
Dpkg changelog states:

  * dpkg-source: Check that debian/tests/control has the required fields.
Prompted by Felix Lechner .

Like so many things Guillem writes, that is a mischaracterization. I
asked him on IRC whether Dpkg examines those files, and he promptly
implemented the check in Dpkg even though, after some consideration, I
asked him not to. That conversation is also why I have not yet filed a
wishlist bug to revert the change in Dpkg.

To the extent they relate to autopktest, our current Gitlab CI
failures in unstable are emblematic of the efforts to duplicate
Lintian tasks in Dpkg. The issue for us is testability, as I will
remove those tags from Lintian. I think everyone would be much better
served if Dpkg simply limited itself to building packages.

Some checking is certainly appropriate for Dpkg, to facilitate safe
handling, but I do not presently understand why faulty definitions in
an autopkgtest suite should make a package unbuildable. Here are the
relevant log messages from Salsa CI:

Cannot parse line Non-zero status 25 from dpkg-source:
 at /builds/lintian/lintian/lib/Test/Lintian/Run.pm line 398.
[The output from dpkg-source is stored in a log file.]

Please let me know your thoughts.

Kind regards
Felix Lechner

Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Felix Lechner]

Hi,

On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton  wrote:
>
> the relevant sentence of Policy ...  was intended to be
> informative, not normative.

Just a brief post scriptum: I had to disable a test in Lintian due to
new restrictions on version strings in Dpkg. The commit message has
more documentation:


https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0

Kind regards

Felix Lechner

Processed: Bug#964013 marked as pending in lintian

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #964013 [lintian] lintian: embedded-javascript-library should flag sphinx 
files too
Added tag(s) pending.

-- 
964013: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964013
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Sergei Golovan]

Package: lintian
Version: 2.82.0
Severity: normal

Dear Maintainer,

Recently, lintian started to emit the breakout-link warning for a bunch of Lua
related packages. A typical structure of a Lua package with a C library is the
following:

The C library with a symlink (to allow someone to link a program in C to it):

/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0
/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1 -> liblua5.1-sec.so.1.0.0

The symlink which lets Lua find the library (by require "ssl")

/usr/lib/x86_64-linux-gnu/lua/5.1/ssl.so -> ../../liblua5.1-sec.so.1.0.0

Since it points to a higher location in the file system, lintian shows a
warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
so I would say that this warning is spurious.

Can it be fixed in Lintian?

I can think of another way of fixing it by reverting the linkage (make
/usr/lib/x86_64-linux-gnu/lua/5.3/ssl.so a real file and point the symlink
/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0 to it), but I'm not sure
it's worth the effort.

Cheers!
-- 
Sergei Golovan