Debian Bug report logs -
#932634
lintian: false-positive embedded-library libyaml due to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Subject: lintian: false-positive embedded-library libyaml due to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Date: Sun, 21 Jul 2019 11:04:36 -0300
Package: lintian
Version: 2.15.0
Severity: important
Dear Maintainer,
In lintian/data/binaries/embedded-libs, the criterium to detect if a
library was linked statically against libyaml is to verify the string:
libyaml ||(?m)^did not find expected <stream-start>
But this string is also found in package rust-yaml-rust.
This caused a false positive when packaging bat [1].
[1] https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-July/006335.html
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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.32.51.20190707-1
ii bzip2 1.0.6-9.2
ii diffstat 1.62-1
ii dpkg 1.19.7
ii dpkg-dev 1.19.7
ii file 1:5.35-4
ii gettext 0.19.8.1-9
ii gpg 2.2.13-2
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.36+b1
ii libarchive-zip-perl 1.64-1
ii libcapture-tiny-perl 0.48-1
ii libcgi-pm-perl 4.40-1
ii libclass-accessor-perl 0.51-1
ii libclone-perl 0.41-1+b1
pn libdigest-sha-perl <none>
ii libdpkg-perl 1.19.7
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.08-1
ii libio-async-perl 0.72-1
ii libipc-run-perl 20180523.0-1
ii liblist-moreutils-perl 0.416-1+b4
ii libparse-debianchangelog-perl 1.2.0-13
ii libpath-tiny-perl 0.108-1
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii libtry-tiny-perl 0.30-1
ii liburi-perl 1.76-1
ii libxml-simple-perl 2.25-1
ii libyaml-libyaml-perl 0.76+repack-1
ii man-db 2.8.5-2
ii patchutils 0.3.4-2
ii perl 5.28.1-6
ii t1utils 1.41-3
ii xz-utils 5.2.4-1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b5
Versions of packages lintian suggests:
pn binutils-multiarch <none>
ii libhtml-parser-perl 3.72-3+b3
ii libtext-template-perl 1.55-1
-- no debconf information
Acknowledgement sent
to "Chris Lamb" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Wed, 24 Jul 2019 17:54:04 GMT) (full text, mbox, link).
Subject: Re: Bug#932634: lintian: false-positive embedded-library libyaml due to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Date: Wed, 24 Jul 2019 14:51:08 -0300
tags 932634 + moreinfo
thanks
Hi Helen,
> In lintian/data/binaries/embedded-libs, the criterium to detect if a
> library was linked statically against libyaml is to verify the string:
>
> libyaml ||(?m)^did not find expected <stream-start>
>
> But this string is also found in package rust-yaml-rust.
Indeed. So, I not sure how Lintian is meant to "know" that this is
from the Rust version of YAML over the libyaml version. If bat was
called, say, "rust-bat" instead then we could use embedded-libs's
ability to filter via a regular expression, but that is alas not the
case. Any ideas...?
Best wishes,,
--
,''`.
: :' : Chris Lamb
`. `'` [email protected] 🍥 chris-lamb.co.uk
`-
Acknowledgement sent
to Helen Koike <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Thu, 25 Jul 2019 17:12:04 GMT) (full text, mbox, link).
Subject: Re: Bug#932634: lintian: false-positive embedded-library libyaml due
to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Date: Thu, 25 Jul 2019 14:08:52 -0300
Hi Chris,
On Wed, Jul 24, 2019 at 2:51 PM Chris Lamb <[email protected]> wrote:
>
> tags 932634 + moreinfo
> thanks
>
> Hi Helen,
>
> > In lintian/data/binaries/embedded-libs, the criterium to detect if a
> > library was linked statically against libyaml is to verify the string:
> >
> > libyaml ||(?m)^did not find expected <stream-start>
> >
> > But this string is also found in package rust-yaml-rust.
>
> Indeed. So, I not sure how Lintian is meant to "know" that this is
> from the Rust version of YAML over the libyaml version. If bat was
> called, say, "rust-bat" instead then we could use embedded-libs's
> ability to filter via a regular expression, but that is alas not the
> case. Any ideas...?
right, the binary package is not called rust-bat but the source package is [1].
Can lintian check for the source package name? (also not sure if it is
a good idea).
Do you think it would be a good idea to rename the binary package?
Or maybe we could try find another string that is present in libyaml and not
in rust-yaml-rust.
Just a question regarding how lintian works: one thing that confused me is that
bat doesn't depend on rust-yaml-rust directly, it depends on rust-syntect which
depends on rust-yaml-rust. So I was wondering why I didn't get this
error in lintian
when building rust-syntect.
[1] https://ftp-master.debian.org/new/rust-bat_0.11.0-1.html
Thanks
Helen
>
>
> Best wishes,,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` [email protected] chris-lamb.co.uk
> `-
Acknowledgement sent
to "Chris Lamb" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Fri, 26 Jul 2019 08:36:03 GMT) (full text, mbox, link).
Subject: Re: Bug#932634: lintian: false-positive embedded-library libyaml due to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Date: Fri, 26 Jul 2019 05:33:03 -0300
Hi Helen,
> right, the binary package is not called rust-bat but the source package is [1].
> Can lintian check for the source package name? (also not sure if it is
> a good idea).
It could but, alas, the I think the "package exception" mechanism
regarding the binaries/embedded-libs data file appears to use the
binary package name...
> Do you think it would be a good idea to rename the binary package?
Just to silence this Lintian warning? That would seem like extreme
overkill to me! Regarding finding another string that is present in.
libyaml and not in rust-yaml-rust, do you have any suggestion at this
point?
> Just a question regarding how lintian works: one thing that confused me is that
> bat doesn't depend on rust-yaml-rust directly, it depends on rust-syntect which
> depends on rust-yaml-rust. So I was wondering why I didn't get this
> error in lintian when building rust-syntect.
I have not checked but isn't the question/issue around Rust embedding
the code of the library in question rather separate to the chain of
Debian-level dependencies. In other words, isn't this apparent
perculiarity explained by that bat embeds the rust-yaml-rust bit of
YAML parsing/generation code whilst that bit of rust-yaml-rust isn't
used in rust-syntect and thus is not embedded?
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` [email protected] 🍥 chris-lamb.co.uk
`-
Acknowledgement sent
to Helen Koike <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Fri, 26 Jul 2019 15:51:02 GMT) (full text, mbox, link).
Subject: Re: Bug#932634: lintian: false-positive embedded-library libyaml due
to matching string (defined in data/binaries/embedded-libs) with package rust-yaml-rust
Date: Fri, 26 Jul 2019 12:48:54 -0300
Hi Chris,
On Fri, Jul 26, 2019 at 5:33 AM Chris Lamb <[email protected]> wrote:
>
> Hi Helen,
>
> > right, the binary package is not called rust-bat but the source package is [1].
> > Can lintian check for the source package name? (also not sure if it is
> > a good idea).
>
> It could but, alas, the I think the "package exception" mechanism
> regarding the binaries/embedded-libs data file appears to use the
> binary package name...
>
> > Do you think it would be a good idea to rename the binary package?
>
> Just to silence this Lintian warning? That would seem like extreme
> overkill to me! Regarding finding another string that is present in.
> libyaml and not in rust-yaml-rust, do you have any suggestion at this
> point?
This is the output of "strings libyaml-0.so.2.0.5": http://ix.io/1PAz
And this is the output of "strings bat": http://ix.io/1PAJ
Maybe we can get a string that is not present in both and long enough to not
conflict with other things? e.g.:
- "unexpected low surrogate area"
- "control characters are not allowed"
- "found a tab character where an indentation space is expected"
(I also checked that these strings are not present in rust-yaml-rust package, in
case the compiler is optimizing something when compiling bat)
What do you think?
>
> > Just a question regarding how lintian works: one thing that confused me is that
> > bat doesn't depend on rust-yaml-rust directly, it depends on rust-syntect which
> > depends on rust-yaml-rust. So I was wondering why I didn't get this
> > error in lintian when building rust-syntect.
>
> I have not checked but isn't the question/issue around Rust embedding
> the code of the library in question rather separate to the chain of
> Debian-level dependencies. In other words, isn't this apparent
> perculiarity explained by that bat embeds the rust-yaml-rust bit of
> YAML parsing/generation code whilst that bit of rust-yaml-rust isn't
> used in rust-syntect and thus is not embedded?
I just noticed that librust*.deb packages just provides source code in
rust, I think
that is why the same lintian warning wasn't fired on rust-syntec (as
librust-syntect-dev*.deb just
provides source code).
So when compiling in a final binary (bat in this case), lintian
detects the embedded-binary.
Thanks
Helen
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` [email protected] chris-lamb.co.uk
> `-
Control: tag -1 pending
Hello,
Bug #932634 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/lintian/lintian/-/commit/4c091cd2d2433e434e3b4326e094ed14534cd3cf
------------------------------------------------------------------------
Turn embedded-library into a classification tag. (Closes: #932634)
Linking statically may no longer be a packaging error in 2022. Many ostensibly
modern languages such as Golang, Rust or Haskell link most or all libraries
statically into the binaries they produce.
For some time, I tried to find other identifying characteristics that would
distinguish the C library libyaml, when linked in statically, from binaries in
other statically linked languages.
Vexingly for this purpose, the newer YAML implementations seem to mirror the
strings found in the C version with amazing accuracy. The sole exception was the
string "found a tab character that violate indentation" (missing an S) but it
seemed unwise to rely on a misspelling that might be corrected, even while the
defective string was still present in the latest libyaml version in unstable.
Of course, the security considerations stated in the tag description still
apply, but those issues reach nowadays far beyond static linking. My desperate
searches on codesearch.d.n were furter befuddled by many vendored sources that
should perhaps not be there. [1]
After some reflection, the Security Team likely has to examine all embedded
versions of affected libraries even when the mode of linking is not actionable
by the Debian distributor because a language works that way.
As a compromise, this commit hides the tag from everyday users but keeps the
information accessible via our website's JSON interface [2] for anyone
researching security matters.
Thanks to Helen Koike for bringning the matter to our attention!
[1] For an example, see yaml.v2 here: https://sources.debian.org/src/golang-github-coreos-discovery-etcd-io/2.0.0+git2019.04.19.git.78fb45d3c9-4/Gopkg.lock/#L543-L549
[2] https://lintian.debian.org/query
------------------------------------------------------------------------
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/932634
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/.