Debian Bug report logs - #650536
[new check] test for missing hardening build flags

version graph

Package: lintian; Maintainer for lintian is Debian Lintian Maintainers <lintian-maint@debian.org>; Source for lintian is src:lintian.

Reported by: Moritz Muehlenhoff <jmm@debian.org>

Date: Wed, 30 Nov 2011 18:24:01 UTC

Severity: wishlist

Tags: patch

Found in versions lintian/2.5.3, lintian/2.5.4

Fixed in version lintian/2.5.7

Done: Niels Thykier <niels@thykier.net>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Wed, 30 Nov 2011 18:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Moritz Muehlenhoff <jmm@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Wed, 30 Nov 2011 18:24:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Please add a lintian test for missing hardened build flags
Date: Wed, 30 Nov 2011 19:21:51 +0100
Package: lintian
Version: 2.5.3
Severity: wishlist

As you're most likely well-aware hardened build flags are a release
goal for Wheezy:
http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags 

Please create a lintian test for packages, which don't enable
hardened build flags yet. Otherwise we'll lack some momentum
in converting to hardened build flags.

I lack the time and lintian know-how to write a test myself, but 
I'll try to outline the requirements as good as possible. Please
let me know if you need any additional information!

- It only needs to apply to packages implemented in C or C++
  (a dep on libc6 is likely the best way to detect this?)

- Most of the work is already done by the script hardening-check
  shipped in the hardening-includes package. Maybe you can simply
  depend on it, since it's really tiny. Here's an example run for
  exim4:

jmm@pisco:~$ hardening-check /usr/sbin/exim4
/usr/sbin/exim4:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: yes

The options, which are satisfied by dpkg-buildflags are "Stack protected",
"Fortify Source functions" and "Read-only relocations".

- Note, there's a chance of mis-detections for -fstack-protector
  and D_FORTIFY_SOURCE in the case of programs, which don't use any 
  of the protected functions. I don't have numbers on this, but this
  is a good use for a lintian override, I suppose.

Cheers,
        Moritz








-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils                       2.21.90.20111025-1
ii  bzip2                          1.0.5-7           
ii  diffstat                       1.54-1            
ii  file                           5.09-2            
ii  gettext                        0.18.1.1-5        
ii  intltool-debian                0.35.0+20060710.1 
ii  libapt-pkg-perl                0.1.25            
ii  libclass-accessor-perl         0.34-1            
ii  libdpkg-perl                   1.16.1.1          
ii  libemail-valid-perl            0.185-1           
ii  libipc-run-perl                0.90-1            
ii  libparse-debianchangelog-perl  1.2.0-1           
ii  libtimedate-perl               1.2000-1          
ii  liburi-perl                    1.59-1            
ii  locales                        2.13-21           
ii  man-db                         2.6.0.2-3         
ii  patchutils                     0.3.2-1           
ii  perl [libdigest-sha-perl]      5.12.4-6          
ii  unzip                          6.0-5             

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch     <none>               
ii  dpkg-dev               1.16.1.1             
ii  libhtml-parser-perl    3.69-1               
ii  libtext-template-perl  <none>               
ii  man-db                 2.6.0.2-3            
ii  xz-utils               5.1.1alpha+20110809-3

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Fri, 02 Dec 2011 00:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Fri, 02 Dec 2011 00:42:03 GMT) Full text and rfc822 format available.

Message #10 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 650536@bugs.debian.org
Subject: first pass
Date: Thu, 1 Dec 2011 16:33:01 -0800
[Message part 1 (text/plain, inline)]
Hi!

Attached is a first-pass at the lintian support for "hardening-check".

There are two more things to do, which I'd like some direction on:

1) With these build tests added, all the other internal lintian tests
   need to either:
        a) add the new warnings to their "tags" file, or
        b) have all their builds adjusted to bring in the dpkg-buildflag
           defaults.
   It looks like a pretty large change, but it should be relatively
   mechanical to accomplish. I would think that "b" above is the better
   of the two options.

2) In reality, the tests are arch-dependent. For example, "relro" doesn't
   exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on
   ia64 alpha mips mipsel hppa arm. I think this expectation needs to be
   built into lintian's invocation of "hardening-check", but that means
   that the "tags" file in the internal lintian tests suddenly needs to
   be generated instead of being static. (i.e. on ia64 and hppa, "no-relro"
   shouldn't show up because it can never happen.)

Thoughts?

-Kees

-- 
Kees Cook                                            @debian.org
[0001-Add-initial-lintian-checks-for-ELF-hardening.patch (text/x-diff, attachment)]

Added tag(s) patch. Request was from Kees Cook <kees@debian.org> to control@bugs.debian.org. (Fri, 02 Dec 2011 02:21:02 GMT) Full text and rfc822 format available.

Changed Bug title to '[new check] test for missing hardening build flags' from 'Please add a lintian test for missing hardened build flags' Request was from Kees Cook <kees@debian.org> to control@bugs.debian.org. (Fri, 02 Dec 2011 02:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sat, 03 Dec 2011 10:21:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sat, 03 Dec 2011 10:21:25 GMT) Full text and rfc822 format available.

Message #19 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>, 650536@bugs.debian.org, Alexander Reichle-Schmehl <tolimar@debian.org>
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Sat, 03 Dec 2011 11:20:05 +0100
On 2011-12-02 01:33, Kees Cook wrote:
> Hi!
> 

Hey,

Kees, Jakub and I had a chat about this yesterday in #d-devel.  Also, I
have CC'ed Alexander due to your/his role as our backporter and as ftp
team member (Alexander, you may want to fast-foward to "Backporting
concerns" below).

> Attached is a first-pass at the lintian support for "hardening-check".
> 
> There are two more things to do, which I'd like some direction on:
> 
> 1) With these build tests added, all the other internal lintian tests
>    need to either:
>         a) add the new warnings to their "tags" file, or
>         b) have all their builds adjusted to bring in the dpkg-buildflag
>            defaults.
>    It looks like a pretty large change, but it should be relatively
>    mechanical to accomplish. I would think that "b" above is the better
>    of the two options.
> 

I suspect this is mostly about updating the template rules file +
correct a few extra tests.  As an added benefit it should be fairly
trivial (if we ignore architecture specificness for a moment).

> 2) In reality, the tests are arch-dependent. For example, "relro" doesn't
>    exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on
>    ia64 alpha mips mipsel hppa arm. I think this expectation needs to be
>    built into lintian's invocation of "hardening-check", but that means
>    that the "tags" file in the internal lintian tests suddenly needs to
>    be generated instead of being static. (i.e. on ia64 and hppa, "no-relro"
>    shouldn't show up because it can never happen.)
> 

I proposed the use of the "post_test" sed script here, which hopefully
should do for the actual test.
  The question is if we will need it only for the hardening test or we
need it for all the tests with C-binaries.  The latter would be very
inconvient.

Alternatively we can mark the tests architecture dependent.  Though in
that case I would prefer being able to determine the architecture list
at test time.  If we have to manually update the architecture list of
these tests, they will most likely end up being outdated and even
inconsistent.

> Thoughts?
> 
> -Kees
> 

Accuracy of the checks:
=======================

In the previous versions of hardening-check, the hardening function
check were prone to false-positives.  If a binary was not using
protectable-functions at all it would have been tagged as unproected
(because there no protected functions in the binary).  I am very pleased
to see that appears to have been fixed in the new version.
  As I understand the code, this check should no longer have
false-positives.  However it may have some false-negatives - particuarly
if protected and unprotected functions are mixed, it will assume the
binary is protected (in its Lintian output at least).
  This check is not architecture dependent and should be fairly trivial
to include.


The stack-protector is architecture dependent (as mentioned above).
Protected binaries will have a certain symbol (__stack_chk_fail), but
not all binaries need it[1].  In this case the symbol will be absent
without the binary is vulnerable, which currently leads to false-positives.
  As I understand [1], the protection is only needed if the binaries
have an array on the stack.  Can we detect the presence (or absence) of
stack arrays (beyond relying on __stack_chk_fail or analysing the binary
code)?  If we can, we should be able to reduce the false-positives.


Finally the relro.  This is also architecture dependent, but I do not
know anything about false-positives or false-negatives here.  Kees, your
patch marks it "certain" so I presume we have a low false-positive
rating here (if we ignore architecture for a moment)?


There was some talk about including an filter (either in Lintian or in
hardening-check) based on architecture to avoid false-positives in relro
and stack-protector for architectures that do not support them.


Backporting concerns and output stability:
==========================================

Both the FTP-masters and Lintian.d.o needs everything in stable (or
stable-backports).  The hardening-wrapper package appears to be small
and trivial enough to backport in itself.  But there might be a concern
in terms of the hardening-includes that (if changed) may affect backport
builds.
  If we can get a reliable backporter for hardening-wrapper as well,
most of my concerns here covered.  On the lintian.d.o side, it means we
may have to nag DSA for an upgrade of hardening-wrapper every now and then.

Jakub Wilk also expressed some concerns with the output of Lintian
would/could (?) vary with the version of hardening-wrapper.  Personally
I am not too concerned here and I do not believe we have a conflict with
our "deterministic-output"-clause[2].
  Aside from possible regressions in hardening-check, I suspect the
accuracy of it will only increase if anything.  My greatest concern in
this area is more that it may break our test-suite (i.e. make Lintian
FTBFS).



I /think/ this should more or less cover the chat we had, plus my view
of the situation.  Kees or Jakub, did I miss something?

~Niels

[1] https://wiki.debian.org/Hardening#Validation

[2] My understanding of this clause is that Lintian must produce the
same output on the same (set of) packages(s) if (but only if):

 1. Lintian nor its dependencies have not been modified/upgraded/etc..
 2. The packages that are tested have not been modified.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 09:15:28 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alexander Reichle-Schmehl <tolimar@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 09:15:33 GMT) Full text and rfc822 format available.

Message #24 received at 650536@bugs.debian.org (full text, mbox):

From: Alexander Reichle-Schmehl <tolimar@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: Kees Cook <kees@debian.org>, 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Thu, 08 Dec 2011 10:13:35 +0100
Hi!

As you fellow backporter I took a quick glance at the hardening-wrapper
package, and didn't spotted any problems so far (as in:  I could create
a backport, install it, and can still compile stuff).  However, as I'm
not very familiar with it, I'll ping the maintainers for their opinion.

Also note that for Lenny there has already been a backport by Ulises
Vitulli <dererk@debian.org>, whom I'll have to ping before hijacking his
former backport, too.


Best regards,
  Alexander

Am 03.12.2011 11:20, schrieb Niels Thykier:
> On 2011-12-02 01:33, Kees Cook wrote:
>> Hi!
>>
> 
> Hey,
> 
> Kees, Jakub and I had a chat about this yesterday in #d-devel.  Also, I
> have CC'ed Alexander due to your/his role as our backporter and as ftp
> team member (Alexander, you may want to fast-foward to "Backporting
> concerns" below).
> 
>> Attached is a first-pass at the lintian support for "hardening-check".
>>
>> There are two more things to do, which I'd like some direction on:
>>
>> 1) With these build tests added, all the other internal lintian tests
>>    need to either:
>>         a) add the new warnings to their "tags" file, or
>>         b) have all their builds adjusted to bring in the dpkg-buildflag
>>            defaults.
>>    It looks like a pretty large change, but it should be relatively
>>    mechanical to accomplish. I would think that "b" above is the better
>>    of the two options.
>>
> 
> I suspect this is mostly about updating the template rules file +
> correct a few extra tests.  As an added benefit it should be fairly
> trivial (if we ignore architecture specificness for a moment).
> 
>> 2) In reality, the tests are arch-dependent. For example, "relro" doesn't
>>    exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on
>>    ia64 alpha mips mipsel hppa arm. I think this expectation needs to be
>>    built into lintian's invocation of "hardening-check", but that means
>>    that the "tags" file in the internal lintian tests suddenly needs to
>>    be generated instead of being static. (i.e. on ia64 and hppa, "no-relro"
>>    shouldn't show up because it can never happen.)
>>
> 
> I proposed the use of the "post_test" sed script here, which hopefully
> should do for the actual test.
>   The question is if we will need it only for the hardening test or we
> need it for all the tests with C-binaries.  The latter would be very
> inconvient.
> 
> Alternatively we can mark the tests architecture dependent.  Though in
> that case I would prefer being able to determine the architecture list
> at test time.  If we have to manually update the architecture list of
> these tests, they will most likely end up being outdated and even
> inconsistent.
> 
>> Thoughts?
>>
>> -Kees
>>
> 
> Accuracy of the checks:
> =======================
> 
> In the previous versions of hardening-check, the hardening function
> check were prone to false-positives.  If a binary was not using
> protectable-functions at all it would have been tagged as unproected
> (because there no protected functions in the binary).  I am very pleased
> to see that appears to have been fixed in the new version.
>   As I understand the code, this check should no longer have
> false-positives.  However it may have some false-negatives - particuarly
> if protected and unprotected functions are mixed, it will assume the
> binary is protected (in its Lintian output at least).
>   This check is not architecture dependent and should be fairly trivial
> to include.
> 
> 
> The stack-protector is architecture dependent (as mentioned above).
> Protected binaries will have a certain symbol (__stack_chk_fail), but
> not all binaries need it[1].  In this case the symbol will be absent
> without the binary is vulnerable, which currently leads to false-positives.
>   As I understand [1], the protection is only needed if the binaries
> have an array on the stack.  Can we detect the presence (or absence) of
> stack arrays (beyond relying on __stack_chk_fail or analysing the binary
> code)?  If we can, we should be able to reduce the false-positives.
> 
> 
> Finally the relro.  This is also architecture dependent, but I do not
> know anything about false-positives or false-negatives here.  Kees, your
> patch marks it "certain" so I presume we have a low false-positive
> rating here (if we ignore architecture for a moment)?
> 
> 
> There was some talk about including an filter (either in Lintian or in
> hardening-check) based on architecture to avoid false-positives in relro
> and stack-protector for architectures that do not support them.
> 
> 
> Backporting concerns and output stability:
> ==========================================
> 
> Both the FTP-masters and Lintian.d.o needs everything in stable (or
> stable-backports).  The hardening-wrapper package appears to be small
> and trivial enough to backport in itself.  But there might be a concern
> in terms of the hardening-includes that (if changed) may affect backport
> builds.
>   If we can get a reliable backporter for hardening-wrapper as well,
> most of my concerns here covered.  On the lintian.d.o side, it means we
> may have to nag DSA for an upgrade of hardening-wrapper every now and then.
> 
> Jakub Wilk also expressed some concerns with the output of Lintian
> would/could (?) vary with the version of hardening-wrapper.  Personally
> I am not too concerned here and I do not believe we have a conflict with
> our "deterministic-output"-clause[2].
>   Aside from possible regressions in hardening-check, I suspect the
> accuracy of it will only increase if anything.  My greatest concern in
> this area is more that it may break our test-suite (i.e. make Lintian
> FTBFS).
> 
> 
> 
> I /think/ this should more or less cover the chat we had, plus my view
> of the situation.  Kees or Jakub, did I miss something?
> 
> ~Niels
> 
> [1] https://wiki.debian.org/Hardening#Validation
> 
> [2] My understanding of this clause is that Lintian must produce the
> same output on the same (set of) packages(s) if (but only if):
> 
>  1. Lintian nor its dependencies have not been modified/upgraded/etc..
>  2. The packages that are tested have not been modified.
> 





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 09:21:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alexander Reichle-Schmehl <tolimar@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 09:21:15 GMT) Full text and rfc822 format available.

Message #29 received at 650536@bugs.debian.org (full text, mbox):

From: Alexander Reichle-Schmehl <tolimar@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: Kees Cook <kees@debian.org>, 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Thu, 08 Dec 2011 10:16:25 +0100
Hi!

Am 08.12.2011 10:13, schrieb Alexander Reichle-Schmehl:

> As you fellow backporter I took a quick glance at the hardening-wrapper
> package, and didn't spotted any problems so far (as in:  I could create
> a backport, install it, and can still compile stuff).  However, as I'm
> not very familiar with it, I'll ping the maintainers for their opinion.

... or I read the bug log first, and notice that the maintainers of said
package are already aware of it ;)


Best regards,
  Alexander, who's going to get some coffee before writing more mails




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 10:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 10:09:15 GMT) Full text and rfc822 format available.

Message #34 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Debian Bug Tracking System <650536@bugs.debian.org>, Alexander Reichle-Schmehl <tolimar@debian.org>, Kees Cook <kees@debian.org>
Subject: Re: [new check] test for missing hardening build flags
Date: Thu, 8 Dec 2011 12:06:37 +0100 (CET)
Package: lintian
Version: 2.5.4
Followup-For: Bug #650536

Hi,

I was informed (and have verified) that hardening-check uses "ldd(1)".
Unfortunately, ldd(1) appears to be (semi-)executing the binaries it
is run on[1].  This smells like a CVE in the making, so would it be
possible for you to update hardening-check to use readelf instead[2]?

~Niels


[1] Quote /usr/bin/ldd:
"""
# This is the `ldd' command, which lists what shared libraries are
# used by given dynamically-linked executables.  It works by invoking the
# run-time dynamic linker as a command and setting the environment
# variable LD_TRACE_LOADED_OBJECTS to a non-empty value.
"""

Also take a look at #514408.

[2] objdump might work as well, but we are slowly migrating away from
it due to issues like #604047.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 10:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jakub Wilk <jwilk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 10:54:06 GMT) Full text and rfc822 format available.

Message #39 received at 650536@bugs.debian.org (full text, mbox):

From: Jakub Wilk <jwilk@debian.org>
To: 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Thu, 8 Dec 2011 11:50:19 +0100
* Niels Thykier <niels@thykier.net>, 2011-12-08, 12:06:
>I was informed (and have verified) that hardening-check uses "ldd(1)". 
>Unfortunately, ldd(1) appears to be (semi-)executing the binaries it is 
>run on[1].  This smells like a CVE in the making,

AFAIUI, ldd in our libc is not vulnerable to arbitrary code execution 
since 2.10.1-7.

The other problem with using ldd is that it won't work for binaries of 
foreign architecture.

>so would it be possible for you to update hardening-check to use 
>readelf instead[2]?

Currently ldd is used to discover which libc the binaries is linked to, 
in order to read symbol from the libc library. But this won't work, even 
when using readelf, for foreign architecture binaries, for the simple 
reason that such libc might not exist on the user's system.

-- 
Jakub Wilk




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 22:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 22:45:06 GMT) Full text and rfc822 format available.

Message #44 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org, Alexander Reichle-Schmehl <tolimar@debian.org>
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Thu, 8 Dec 2011 14:40:02 -0800
On Sat, Dec 03, 2011 at 11:20:05AM +0100, Niels Thykier wrote:
> On 2011-12-02 01:33, Kees Cook wrote:
> > 1) With these build tests added, all the other internal lintian tests
> >    need to either:
> >         a) add the new warnings to their "tags" file, or
> >         b) have all their builds adjusted to bring in the dpkg-buildflag
> >            defaults.
> >    It looks like a pretty large change, but it should be relatively
> >    mechanical to accomplish. I would think that "b" above is the better
> >    of the two options.
> > 
> 
> I suspect this is mostly about updating the template rules file +
> correct a few extra tests.  As an added benefit it should be fairly
> trivial (if we ignore architecture specificness for a moment).

Okay, sounds good. I'll look at what it'll take to clear all the tests from
these warnings, though I suspect this may come after solving the #2 problem
below...

> > 2) In reality, the tests are arch-dependent. For example, "relro" doesn't
> >    exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on
> >    ia64 alpha mips mipsel hppa arm. I think this expectation needs to be
> >    built into lintian's invocation of "hardening-check", but that means
> >    that the "tags" file in the internal lintian tests suddenly needs to
> >    be generated instead of being static. (i.e. on ia64 and hppa, "no-relro"
> >    shouldn't show up because it can never happen.)
> > 
> 
> I proposed the use of the "post_test" sed script here, which hopefully
> should do for the actual test.
>   The question is if we will need it only for the hardening test or we
> need it for all the tests with C-binaries.  The latter would be very
> inconvient.
> 
> Alternatively we can mark the tests architecture dependent.  Though in
> that case I would prefer being able to determine the architecture list
> at test time.  If we have to manually update the architecture list of
> these tests, they will most likely end up being outdated and even
> inconsistent.

Right, a manual list is exactly what I want to avoid. I think what is
needed is a new feature added to dpkg-buildflags to be able to query the
list of hardening features. Both lintian and hardening-check could use it.

> Accuracy of the checks:
> =======================
> 
> In the previous versions of hardening-check, the hardening function
> check were prone to false-positives.  If a binary was not using
> protectable-functions at all it would have been tagged as unproected
> (because there no protected functions in the binary).  I am very pleased
> to see that appears to have been fixed in the new version.
>   As I understand the code, this check should no longer have
> false-positives.  However it may have some false-negatives - particuarly
> if protected and unprotected functions are mixed, it will assume the
> binary is protected (in its Lintian output at least).
>   This check is not architecture dependent and should be fairly trivial
> to include.

Right. It's better than it was, but it can still produce false-positives.
For example, if the only function used was gethostname(), it's possible to
do compile-time verification to see that the _chk() version isn't needed,
so even though the source was built with -D_FORTIFY_SOURCE=2, the
unprotected function will be used. Not all functions are compile-time
checkable, and trying to figure out which are which seems a bit out of
scope at the moment. And because of this, we're forced into the
false-negatives problem. This is why I left it as "possible".

> The stack-protector is architecture dependent (as mentioned above).
> Protected binaries will have a certain symbol (__stack_chk_fail), but
> not all binaries need it[1].  In this case the symbol will be absent
> without the binary is vulnerable, which currently leads to false-positives.
>   As I understand [1], the protection is only needed if the binaries
> have an array on the stack.  Can we detect the presence (or absence) of
> stack arrays (beyond relying on __stack_chk_fail or analysing the binary
> code)?  If we can, we should be able to reduce the false-positives.

We cannot, unfortunately. Or rather, it requires heavy static analysis
of arch-dep assembly for the function preamble (which may change between
compiler versions, optimizations, etc) and use of alloca(), effectively
reverse engineering the asm back to its C form. Additionally, at that
level it may be very hard to distinguish between a character array and
other kinds of arrays (which would not trigger stack-protector).  I'm open
to ideas on this, but am currently coming up empty on easy solutions. This
is, again, why I left it as "possible".

> Finally the relro.  This is also architecture dependent, but I do not
> know anything about false-positives or false-negatives here.  Kees, your
> patch marks it "certain" so I presume we have a low false-positive
> rating here (if we ignore architecture for a moment)?

Correct, relro is a program header on the ELF binary (GNU_RELRO) that
helps direct the dynamic linker. It's either there or it isn't, and if
it isn't, the build flags were not applied. However, it is arch-specific,
so really it's certain if the feature is enabled. This gets me back to
adding some logic to dpkg-buildflags. I'll link to that bug once I've
gotten that written.

> Backporting concerns and output stability:
> ==========================================
> 
> Both the FTP-masters and Lintian.d.o needs everything in stable (or
> stable-backports).  The hardening-wrapper package appears to be small
> and trivial enough to backport in itself.  But there might be a concern
> in terms of the hardening-includes that (if changed) may affect backport
> builds.
>   If we can get a reliable backporter for hardening-wrapper as well,
> most of my concerns here covered.  On the lintian.d.o side, it means we
> may have to nag DSA for an upgrade of hardening-wrapper every now and then.

Given that dpkg-buildflags won't be backported, perhaps just having lintian
detect the lack of the "what are the hardening features?" query ability in
dpkg-buildflags would be enough to disable the hardening tests in the
backport?

> Jakub Wilk also expressed some concerns with the output of Lintian
> would/could (?) vary with the version of hardening-wrapper.  Personally
> I am not too concerned here and I do not believe we have a conflict with
> our "deterministic-output"-clause[2].
>   Aside from possible regressions in hardening-check, I suspect the
> accuracy of it will only increase if anything.  My greatest concern in
> this area is more that it may break our test-suite (i.e. make Lintian
> FTBFS).

That is my feeling as well. The tests in hardening-check should only
improve.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 22:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 22:54:04 GMT) Full text and rfc822 format available.

Message #49 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: Debian Bug Tracking System <650536@bugs.debian.org>, Alexander Reichle-Schmehl <tolimar@debian.org>
Subject: Re: [new check] test for missing hardening build flags
Date: Thu, 8 Dec 2011 14:51:07 -0800
On Thu, Dec 08, 2011 at 12:06:37PM +0100, Niels Thykier wrote:
> I was informed (and have verified) that hardening-check uses "ldd(1)".
> Unfortunately, ldd(1) appears to be (semi-)executing the binaries it
> is run on[1].  This smells like a CVE in the making, so would it be
> possible for you to update hardening-check to use readelf instead[2]?

Yeah, I can do this manually instead of invoking ldd(1). From the
perspective of doing build checks, it seems like a non-issue, but better to
just fix it anyway. I'll update hardening-check.

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Thu, 08 Dec 2011 22:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Thu, 08 Dec 2011 22:57:03 GMT) Full text and rfc822 format available.

Message #54 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 650536@bugs.debian.org
Cc: Jakub Wilk <jwilk@debian.org>, Niels Thykier <niels@thykier.net>
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Thu, 8 Dec 2011 14:53:27 -0800
On Thu, Dec 08, 2011 at 11:50:19AM +0100, Jakub Wilk wrote:
> Currently ldd is used to discover which libc the binaries is linked
> to, in order to read symbol from the libc library. But this won't
> work, even when using readelf, for foreign architecture binaries,
> for the simple reason that such libc might not exist on the user's
> system.

Right. How do you think this should be handled? I could fall back to the
earlier method of just looking for things named _chk()?

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Fri, 09 Dec 2011 08:30:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alexander Reichle-Schmehl <tolimar@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Fri, 09 Dec 2011 08:30:05 GMT) Full text and rfc822 format available.

Message #59 received at 650536@bugs.debian.org (full text, mbox):

From: Alexander Reichle-Schmehl <tolimar@debian.org>
To: Kees Cook <kees@debian.org>
Cc: Niels Thykier <niels@thykier.net>, 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Fri, 09 Dec 2011 09:27:18 +0100
HI!

Am 08.12.2011 23:40, schrieb Kees Cook:

>> Backporting concerns and output stability:
>> ==========================================
>>
>> Both the FTP-masters and Lintian.d.o needs everything in stable (or
>> stable-backports).
>> [..]
> Given that dpkg-buildflags won't be backported, perhaps just having lintian
> detect the lack of the "what are the hardening features?" query ability in
> dpkg-buildflags would be enough to disable the hardening tests in the
> backport?

Why would you do that?  The point of the lintian backport would be to
run the check on packages targeting unstable.  It's not that uncommon
for developers to have some unstable chroots / pbuilder environments on
a stable+backports system, and as said, ftp-master and lintian lab use
the same.  So the results of lintian backport should IMHO be as similar
to the real package as possible.


Best regards,
  Alexander




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Fri, 09 Dec 2011 17:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Fri, 09 Dec 2011 17:18:04 GMT) Full text and rfc822 format available.

Message #64 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Alexander Reichle-Schmehl <tolimar@debian.org>
Cc: Niels Thykier <niels@thykier.net>, 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Fri, 9 Dec 2011 09:14:47 -0800
On Fri, Dec 09, 2011 at 09:27:18AM +0100, Alexander Reichle-Schmehl wrote:
> Am 08.12.2011 23:40, schrieb Kees Cook:
> >> Backporting concerns and output stability:
> >> ==========================================
> >>
> >> Both the FTP-masters and Lintian.d.o needs everything in stable (or
> >> stable-backports).
> >> [..]
> > Given that dpkg-buildflags won't be backported, perhaps just having lintian
> > detect the lack of the "what are the hardening features?" query ability in
> > dpkg-buildflags would be enough to disable the hardening tests in the
> > backport?
> 
> Why would you do that?  The point of the lintian backport would be to
> run the check on packages targeting unstable.  It's not that uncommon
> for developers to have some unstable chroots / pbuilder environments on
> a stable+backports system, and as said, ftp-master and lintian lab use
> the same.  So the results of lintian backport should IMHO be as similar
> to the real package as possible.

Hm, while I see your point, I'm not sure what the best solution is. The
information about what hardening features are available is coming from
dpkg-buildflags. All that jumps to mind for me is having lintian keep
static files with the dpkg-buildflags --query-features output for each
release. It could be generated and stored instead of strictly being a
manually updated list.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 13 Dec 2011 13:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alexander Reichle-Schmehl <tolimar@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 13 Dec 2011 13:51:09 GMT) Full text and rfc822 format available.

Message #69 received at 650536@bugs.debian.org (full text, mbox):

From: Alexander Reichle-Schmehl <tolimar@debian.org>
To: 650536@bugs.debian.org
Subject: Re: Bug#650536: [new check] test for missing hardening build flags
Date: Tue, 13 Dec 2011 14:50:19 +0100
[ Good god... did I really send a full quote in that mail?  Sorry. ]

Hi!

* Alexander Reichle-Schmehl <tolimar@debian.org> [111208 10:13]:

> >   If we can get a reliable backporter for hardening-wrapper as well,
> > most of my concerns here covered.  On the lintian.d.o side, it means we
> > may have to nag DSA for an upgrade of hardening-wrapper every now and then.
> Also note that for Lenny there has already been a backport by Ulises
> Vitulli <dererk@debian.org>, whom I'll have to ping before hijacking his

FWIW:  I got the permission from Ulises to adopt the backport of
hardening-wrapper.  So from my point of view, you can introduce such a
dependencie whenever it suites you :)

Best Regards,
  Alexander




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Mon, 05 Mar 2012 03:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Mon, 05 Mar 2012 03:57:07 GMT) Full text and rfc822 format available.

Message #74 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 650536@bugs.debian.org
Subject: update!
Date: Sun, 4 Mar 2012 19:47:53 -0800
[Message part 1 (text/plain, inline)]
Okay, here's the latest version. Some notes:

- It requires the lastest dpkg-dev (still in experimental) to get
  the dpkg-buildflags that supports --query-features.

- The hardening checker only expects the hardened features that are
  defaulted on for the architecture of the package it is examining.

- The hardening checker checks if it is running as part of the
  internal test suite, so that it is disabled for all tests except
  its own, since the bulk of the internal tests do not build with
  hardening flags, and only for i386 and amd64 since there isn't
  a sane way to generate the "tags" file on the fly for a test.

Doing manual testing shows that building, for example, the "hello"
package as-is triggers appropriate warnings, and when I fix the "hello"
package to import the dpkg-buildflags correctly, the lintian warnings
go away. :)

-Kees

-- 
Kees Cook                                            @debian.org
[0001-Add-initial-lintian-checks-for-ELF-hardening.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Mon, 05 Mar 2012 10:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Mon, 05 Mar 2012 10:33:59 GMT) Full text and rfc822 format available.

Message #79 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>, 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Mon, 05 Mar 2012 11:29:46 +0100
On 2012-03-05 04:47, Kees Cook wrote:
> Okay, here's the latest version. Some notes:
> 

Hi,

Thanks for the update.

> - It requires the lastest dpkg-dev (still in experimental) to get
>   the dpkg-buildflags that supports --query-features.
> 

Unfortunately I see two issues here.  First, we have been asked to avoid
the unconditional dpkg-dev dependency (see #626476).  Perhaps we can use
libdpkg-perl as a fall-back in this case (like we do in
collection/unpacked).

The second problem is that the given version of dpkg-dev is not in
stable[1] and (as I recall) the backport FTP masters were not too happy
with the last backport.

[1] It is not in unstable either, but at this point I am more concerned
with getting it in stable.

> - The hardening checker only expects the hardened features that are
>   defaulted on for the architecture of the package it is examining.
> 

Good :)

> - The hardening checker checks if it is running as part of the
>   internal test suite, so that it is disabled for all tests except
>   its own, since the bulk of the internal tests do not build with
>   hardening flags, and only for i386 and amd64 since there isn't
>   a sane way to generate the "tags" file on the fly for a test.
> 

To be honest I do not like the idea of Lintian checks/collections
behaving differently during tests.
  I suppose we could a make """sane way to generate the "tags" file""".
 We already have several hooks in the test suite, adding another one
should not be a great issue.

Though, we only want hardening tags emitted in a selected few tests...

> Doing manual testing shows that building, for example, the "hello"
> package as-is triggers appropriate warnings, and when I fix the "hello"
> package to import the dpkg-buildflags correctly, the lintian warnings
> go away. :)
> 
> -Kees
> 

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 01:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 01:03:07 GMT) Full text and rfc822 format available.

Message #84 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Mon, 5 Mar 2012 16:58:52 -0800
On Mon, Mar 05, 2012 at 11:29:46AM +0100, Niels Thykier wrote:
> On 2012-03-05 04:47, Kees Cook wrote:
> > - It requires the lastest dpkg-dev (still in experimental) to get
> >   the dpkg-buildflags that supports --query-features.
> 
> Unfortunately I see two issues here.  First, we have been asked to avoid
> the unconditional dpkg-dev dependency (see #626476).  Perhaps we can use
> libdpkg-perl as a fall-back in this case (like we do in
> collection/unpacked).

Hrm, well, as long as dpkg-buildflags is the right one, I don't care
what the Depends say. ;)

> The second problem is that the given version of dpkg-dev is not in
> stable[1] and (as I recall) the backport FTP masters were not too happy
> with the last backport.
> 
> [1] It is not in unstable either, but at this point I am more concerned
> with getting it in stable.
> 

Right -- though I have no way around this. All the pieces needed for
these checks come from the new dpkg-buildflags. Perhaps the hardening
check can be disabled for the backport, since it's rather meaningless
for stable anyway?

> > - The hardening checker checks if it is running as part of the
> >   internal test suite, so that it is disabled for all tests except
> >   its own, since the bulk of the internal tests do not build with
> >   hardening flags, and only for i386 and amd64 since there isn't
> >   a sane way to generate the "tags" file on the fly for a test.
> > 
> 
> To be honest I do not like the idea of Lintian checks/collections
> behaving differently during tests.
>   I suppose we could a make """sane way to generate the "tags" file""".
>  We already have several hooks in the test suite, adding another one
> should not be a great issue.

I could write a hook the generate the tags file on the fly, but that
only handles the per-arch limitation of the internal test for the
hardening checker.

> Though, we only want hardening tags emitted in a selected few tests...

This was the big problem. I spent a lot of time trying to see how bad
it would be to fix every build in the testsuite to DTRT with respect
to dpkg-buildflags, but it was a losing battle. Or, at least, a tedious
battle.  Ultimately I decided it was better to just have the hardening
checker disable itself in the face of the other tests.

I'm open to ideas for this part, but a lot of the test builds don't pass
all the needed flags, or hard code flags, etc etc. Changing the compat
level worked for many of the failures, but not all and left about 30
that still needed to be changed by hand. If it's important to do this
strictly correct, I can, it'll just take me a while.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 17:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 17:39:03 GMT) Full text and rfc822 format available.

Message #89 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 06 Mar 2012 18:36:07 +0100
On 2012-03-06 01:58, Kees Cook wrote:
> On Mon, Mar 05, 2012 at 11:29:46AM +0100, Niels Thykier wrote:
>> On 2012-03-05 04:47, Kees Cook wrote:
>>> - It requires the lastest dpkg-dev (still in experimental) to get
>>>   the dpkg-buildflags that supports --query-features.
>>
> [...]
>> The second problem is that the given version of dpkg-dev is not in
>> stable[1] and (as I recall) the backport FTP masters were not too happy
>> with the last backport.
>>
>> [1] It is not in unstable either, but at this point I am more concerned
>> with getting it in stable.
>>
> 
> Right -- though I have no way around this. All the pieces needed for
> these checks come from the new dpkg-buildflags. Perhaps the hardening
> check can be disabled for the backport, since it's rather meaningless
> for stable anyway?
> 

Lintian.d.o, ftp-master.d.o and potentionally a lot of developers run
Lintian on a Debian/Squeeze.  I suspect a static data file is better
than disabling it for Squeeze.

> [...]
> 
> -Kees
> 

Skipping the "testing issue" for now.  :)

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 18:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 18:12:06 GMT) Full text and rfc822 format available.

Message #94 received at 650536@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Kees Cook <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 06 Mar 2012 10:08:31 -0800
Kees Cook <kees@debian.org> writes:

> This was the big problem. I spent a lot of time trying to see how bad it
> would be to fix every build in the testsuite to DTRT with respect to
> dpkg-buildflags, but it was a losing battle. Or, at least, a tedious
> battle.  Ultimately I decided it was better to just have the hardening
> checker disable itself in the face of the other tests.

> I'm open to ideas for this part, but a lot of the test builds don't pass
> all the needed flags, or hard code flags, etc etc. Changing the compat
> level worked for many of the failures, but not all and left about 30
> that still needed to be changed by hand. If it's important to do this
> strictly correct, I can, it'll just take me a while.

The general intent of the Lintian test suite is that the packages it
produces should be Lintian-clean except for the tags that the package is
specifically testing (or others that are unavoidable for some reason).  So
when new requirements for Debian packages are added, as a general rule of
thumb we want to update the test suite so that it meets those requirements
except for those tests that are testing Lintian's tags for those
requirements.

So, this is work that does need to be done eventually, I think.  That
doesn't mean it has to be a blocker for getting the tag into Lintian,
though.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 19:21:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 19:21:14 GMT) Full text and rfc822 format available.

Message #99 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 6 Mar 2012 11:19:42 -0800
On Tue, Mar 06, 2012 at 06:36:07PM +0100, Niels Thykier wrote:
> On 2012-03-06 01:58, Kees Cook wrote:
> > Right -- though I have no way around this. All the pieces needed for
> > these checks come from the new dpkg-buildflags. Perhaps the hardening
> > check can be disabled for the backport, since it's rather meaningless
> > for stable anyway?
> 
> Lintian.d.o, ftp-master.d.o and potentionally a lot of developers run
> Lintian on a Debian/Squeeze.  I suspect a static data file is better
> than disabling it for Squeeze.

Oh, you mean they'll run a squeeze lintian against a wheezy deb?

If so, yeah, that is troublesome.

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 19:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 19:27:03 GMT) Full text and rfc822 format available.

Message #104 received at 650536@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Kees Cook <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 06 Mar 2012 11:24:50 -0800
Kees Cook <kees@debian.org> writes:
> On Tue, Mar 06, 2012 at 06:36:07PM +0100, Niels Thykier wrote:

>> Lintian.d.o, ftp-master.d.o and potentionally a lot of developers run
>> Lintian on a Debian/Squeeze.  I suspect a static data file is better
>> than disabling it for Squeeze.

> Oh, you mean they'll run a squeeze lintian against a wheezy deb?

They will run the most recent Lintian (possibly backported, possibly -- in
the case of lintian.d.o -- run from Git) on a squeeze system against a
wheezy deb.  That's how the entirety of lintian.d.o works.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 19:27:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 19:27:14 GMT) Full text and rfc822 format available.

Message #109 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 6 Mar 2012 11:26:41 -0800
Hi Russ,

On Tue, Mar 06, 2012 at 10:08:31AM -0800, Russ Allbery wrote:
> Kees Cook <kees@debian.org> writes:
> 
> > This was the big problem. I spent a lot of time trying to see how bad it
> > would be to fix every build in the testsuite to DTRT with respect to
> > dpkg-buildflags, but it was a losing battle. Or, at least, a tedious
> > battle.  Ultimately I decided it was better to just have the hardening
> > checker disable itself in the face of the other tests.
> 
> > I'm open to ideas for this part, but a lot of the test builds don't pass
> > all the needed flags, or hard code flags, etc etc. Changing the compat
> > level worked for many of the failures, but not all and left about 30
> > that still needed to be changed by hand. If it's important to do this
> > strictly correct, I can, it'll just take me a while.
> 
> The general intent of the Lintian test suite is that the packages it
> produces should be Lintian-clean except for the tags that the package is
> specifically testing (or others that are unavoidable for some reason).  So
> when new requirements for Debian packages are added, as a general rule of
> thumb we want to update the test suite so that it meets those requirements
> except for those tests that are testing Lintian's tags for those
> requirements.
> 
> So, this is work that does need to be done eventually, I think.  That
> doesn't mean it has to be a blocker for getting the tag into Lintian,
> though.

Okay. In that case, I think the work needs to be broken into several pieces:

- make lintian work for wheezy (but disable internal tests for hardening)
- build internal hardening test for all archs (hook to generate tags file)
- fix other lintian internal tests to work with hardening check
- backport hardening check to work on squeeze

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 19:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 19:39:06 GMT) Full text and rfc822 format available.

Message #114 received at 650536@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Kees Cook <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 06 Mar 2012 11:36:42 -0800
Kees Cook <kees@debian.org> writes:

> Okay. In that case, I think the work needs to be broken into several pieces:

> - make lintian work for wheezy (but disable internal tests for hardening)

A better way than disabling it might be to just list the expected tags
until the test cases have been revised to not issue those tags.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Tue, 06 Mar 2012 19:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Tue, 06 Mar 2012 19:51:03 GMT) Full text and rfc822 format available.

Message #119 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Tue, 6 Mar 2012 11:50:14 -0800
On Tue, Mar 06, 2012 at 11:36:42AM -0800, Russ Allbery wrote:
> Kees Cook <kees@debian.org> writes:
> 
> > Okay. In that case, I think the work needs to be broken into several pieces:
> 
> > - make lintian work for wheezy (but disable internal tests for hardening)
> 
> A better way than disabling it might be to just list the expected tags
> until the test cases have been revised to not issue those tags.

It changes based on architecture. ;) Wheee

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sat, 10 Mar 2012 23:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sat, 10 Mar 2012 23:21:04 GMT) Full text and rfc822 format available.

Message #124 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>, 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Sun, 11 Mar 2012 00:16:09 +0100
On 2012-03-06 20:26, Kees Cook wrote:
> Hi Russ,
> 
> On Tue, Mar 06, 2012 at 10:08:31AM -0800, Russ Allbery wrote:
>> Kees Cook <kees@debian.org> writes:
>>

Hi,

I have started an unofficial branch[1] to get something more concrete on
this.  I decided to rename the tags so they had a common prefix (it
simplified the updated to t/scripts/implemented-tags.t).

>>> This was the big problem. I spent a lot of time trying to see how bad it
>>> would be to fix every build in the testsuite to DTRT with respect to
>>> dpkg-buildflags, but it was a losing battle. Or, at least, a tedious
>>> battle.  Ultimately I decided it was better to just have the hardening
>>> checker disable itself in the face of the other tests.
>>
>>> I'm open to ideas for this part, but a lot of the test builds don't pass
>>> all the needed flags, or hard code flags, etc etc. Changing the compat
>>> level worked for many of the failures, but not all and left about 30
>>> that still needed to be changed by hand. If it's important to do this
>>> strictly correct, I can, it'll just take me a while.
>>
>> The general intent of the Lintian test suite is that the packages it
>> produces should be Lintian-clean except for the tags that the package is
>> specifically testing (or others that are unavoidable for some reason).  So
>> when new requirements for Debian packages are added, as a general rule of
>> thumb we want to update the test suite so that it meets those requirements
>> except for those tests that are testing Lintian's tags for those
>> requirements.
>>

I have bumped the debhelper standard test suite to use compat 9 by
default.  I doubt it will fix all the failures we saw, but at least the
standard flags are enabled by default.

>> So, this is work that does need to be done eventually, I think.  That
>> doesn't mean it has to be a blocker for getting the tag into Lintian,
>> though.
> 
> Okay. In that case, I think the work needs to be broken into several pieces:
> 
> - make lintian work for wheezy (but disable internal tests for hardening)
> - backport hardening check to work on squeeze

I just finished a patch that solves these two.  I made a data file that
is trivial to regenerate/update using private/refresh-archs (requiring
dpkg-dev from experimental or newer).  It also removes the need for
dpkg-dev at runtime.  :)
  I know you had some concerns about using data files, but I honestly
think they will be the easiest way to solve the backportability problem.
 Since we can use dpkg-buildflags to regenerate it automatically, it
should be trivial to keep it in sync.

It also solves one of the test errors as dpkg-buildflags does not handle
invalid architectures too well.

> - build internal hardening test for all archs (hook to generate tags file)
> - fix other lintian internal tests to work with hardening check

This part still needs some work though.

I suspect it might be a good idea to try the test suite on some
different architectures at some point.  These

> 
> -Kees
> 

Last I checked we still have an "outstanding issue" hardening-check
using ldd, which I am not certain will work with "foreign" binaries (see
comment #39).  I suspect it will mostly affect people who do
cross-builds and lintian.d.o[2].
  If I recall, hardening-check falls back to assuming the binary is
"safe" for the checks needing ldd data, so we should get false-negatives
rather than false-positives in this case.


~Niels

[1]
http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/hardening-support

[2] lintian.d.o is amd64, but it checks i386 packages.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sun, 11 Mar 2012 12:39:24 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sun, 11 Mar 2012 12:39:31 GMT) Full text and rfc822 format available.

Message #129 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Sun, 11 Mar 2012 05:37:52 -0700
On Sun, Mar 11, 2012 at 12:16:09AM +0100, Niels Thykier wrote:
> I have bumped the debhelper standard test suite to use compat 9 by
> default.  I doubt it will fix all the failures we saw, but at least the
> standard flags are enabled by default.

When I was playing with it, this solved a lot but not all of them. Doesn't
this pose an unbackportable change though? I didn't think compat 9
existed in Squeeze.

> > - make lintian work for wheezy (but disable internal tests for hardening)
> > - backport hardening check to work on squeeze
> 
> I just finished a patch that solves these two.  I made a data file that
> is trivial to regenerate/update using private/refresh-archs (requiring
> dpkg-dev from experimental or newer).  It also removes the need for
> dpkg-dev at runtime.  :)
>   I know you had some concerns about using data files, but I honestly
> think they will be the easiest way to solve the backportability problem.
>  Since we can use dpkg-buildflags to regenerate it automatically, it
> should be trivial to keep it in sync.

I think you've convinced me about the data files. The options shouldn't be
changing terribly frequently.

> It also solves one of the test errors as dpkg-buildflags does not handle
> invalid architectures too well.

True.

> > - build internal hardening test for all archs (hook to generate tags file)
> > - fix other lintian internal tests to work with hardening check
> 
> This part still needs some work though.
> 
> I suspect it might be a good idea to try the test suite on some
> different architectures at some point.  These

Cool, I'll spend some time on the branch getting any stragglers building
correctly.

> Last I checked we still have an "outstanding issue" hardening-check
> using ldd, which I am not certain will work with "foreign" binaries (see
> comment #39).  I suspect it will mostly affect people who do
> cross-builds and lintian.d.o[2].

Yeah, I was just starting to notice this. Inspired by the data file idea, I
think I might do the same for hardening-check and have it build the list of
functions at build-time. I can check if a binary is using libc without
running ldd, and I only needed ldd to generate the function list dynamically.
If it's static, things are faster and more portable. It'll just need updating
from time to time when anything major happens with eglibc.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sun, 11 Mar 2012 14:39:39 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sun, 11 Mar 2012 14:39:41 GMT) Full text and rfc822 format available.

Message #134 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Sun, 11 Mar 2012 15:24:56 +0100
On 2012-03-11 13:37, Kees Cook wrote:
> On Sun, Mar 11, 2012 at 12:16:09AM +0100, Niels Thykier wrote:
>> I have bumped the debhelper standard test suite to use compat 9 by
>> default.  I doubt it will fix all the failures we saw, but at least the
>> standard flags are enabled by default.
> 
> When I was playing with it, this solved a lot but not all of them. Doesn't
> this pose an unbackportable change though? I didn't think compat 9
> existed in Squeeze.
> 

It does not, but debhelper 9 has been backported already, so we can rely
on it.

In fact, we already needed debhelper 9 due to t/tests/debhelper-dh-exec,
but I apparently forgot to bump the depends back then...

> [...]
>>> - build internal hardening test for all archs (hook to generate tags file)
>>> - fix other lintian internal tests to work with hardening check
>>
>> This part still needs some work though.
>>
>> I suspect it might be a good idea to try the test suite on some
>> different architectures at some point.  These
> 
> Cool, I'll spend some time on the branch getting any stragglers building
> correctly.
> 

Much appreciated.

>> Last I checked we still have an "outstanding issue" hardening-check
>> using ldd, which I am not certain will work with "foreign" binaries (see
>> comment #39).  I suspect it will mostly affect people who do
>> cross-builds and lintian.d.o[2].
> 
> Yeah, I was just starting to notice this. Inspired by the data file idea, I
> think I might do the same for hardening-check and have it build the list of
> functions at build-time. I can check if a binary is using libc without
> running ldd, and I only needed ldd to generate the function list dynamically.
> If it's static, things are faster and more portable. It'll just need updating
> from time to time when anything major happens with eglibc.
> 
> -Kees
> 

Sounds good.  :)

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sun, 01 Apr 2012 07:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sun, 01 Apr 2012 07:24:03 GMT) Full text and rfc822 format available.

Message #139 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: update!
Date: Sun, 1 Apr 2012 00:21:15 -0700
[Message part 1 (text/plain, inline)]
Hi Niels,

On Sun, Mar 11, 2012 at 12:16:09AM +0100, Niels Thykier wrote:
> I have started an unofficial branch[1] to get something more concrete on
> this.  I decided to rename the tags so they had a common prefix (it
> simplified the updated to t/scripts/implemented-tags.t).

Attached is a patch to clean up the remaining tests that still needed
stack protector and fortify to show up in their binaries.

> Last I checked we still have an "outstanding issue" hardening-check
> using ldd, which I am not certain will work with "foreign" binaries (see
> comment #39).  I suspect it will mostly affect people who do
> cross-builds and lintian.d.o[2].

And this should be taken care of now in hardening-includes 2.0, which
uses a hard-coded list of libc functions instead of trying to build the
list at runtime.

After this patch, the TODO's single remaining item is:

    + revise tag certainty and description:
      - overrides (we can't do much about FP etc.)

What is needed for this? Should I expand the descriptions more? Or was
there something else?

Thanks!

-Kees

-- 
Kees Cook                                            @debian.org
[0001-Update-for-latest-hardening-check.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sun, 01 Apr 2012 15:21:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Niels Thykier" <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sun, 01 Apr 2012 15:21:09 GMT) Full text and rfc822 format available.

Message #144 received at 650536@bugs.debian.org (full text, mbox):

From: "Niels Thykier" <niels@thykier.net>
To: "Kees Cook" <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Sun, 01 Apr 2012 17:16:38 +0200
On Apr 1, 2012 09:21 "Kees Cook" <kees@debian.org> wrote:
> Hi Niels,
> 
> On Sun, Mar 11, 2012 at 12:16:09AM +0100, Niels Thykier wrote:
> > I have started an unofficial branch[1] to get something more
> > concrete on
> > this.  I decided to rename the tags so they had a common prefix (it
> > simplified the updated to t/scripts/implemented-tags.t).
> 
> Attached is a patch to clean up the remaining tests that still needed
> stack protector and fortify to show up in their binaries.
> 

Hi,

Thanks, I have pushed it to my branch (with a minor change to also update
the Depends of lintian in d/control).

Kees, btw, are you certain of the copyright statements in
collection/hardening-info?

"""
# The original shell script version of this script is
# Copyright (C) 1998 Christian Schwarz
#
# The objdump version, including support for etch's binutils, is
# Copyright (C) 2008 Adam D. Barratt
#
# This version, a trimmed-down wrapper for hardening-check, is
# Copyright (C) 2012 Kees Cook <kees@debian.org>
"""

I suspect some of it is copy-waste from collection/objdump-info...

> > Last I checked we still have an "outstanding issue" hardening-check
> > using ldd, which I am not certain will work with "foreign" binaries
> > (see
> > comment #39).  I suspect it will mostly affect people who do
> > cross-builds and lintian.d.o[2].
> 
> And this should be taken care of now in hardening-includes 2.0, which
> uses a hard-coded list of libc functions instead of trying to build
> the list at runtime.
> 

Awesome, :)

> After this patch, the TODO's single remaining item is:
> 
>     + revise tag certainty and description:
>       - overrides (we can't do much about FP etc.)
> 
> What is needed for this? Should I expand the descriptions more? Or was
> there something else?
>

It was mostly a reminder to myself to review them and maybe add a
"disclaimer" on the false-positives.

There was also something else, namely making the test suite able to
handle the architecture specific nature of the hardening tags.  I
have committed some code to handle this.[0]  Assuming no one objects
to the approach, I think we are more or less good to go.

Optimally, Lintian would handle the architecture specific part of
these tags better in terms of overrides so people do not have to
maintain the archlist for their overrides.  However, that can come
in Lintian 2.5.8 or some later time (if at all).

> 
> Thanks!
> 
> -Kees
> 

I have rebased the branch and it is now available from [1] and I
intend to merge it into master before we do the 2.5.7 release.
As mentioned, I have added a new test suite hook[0], which some
may (or may not) find controversial.

Assuming no comments/objections, I intend to merge the branch
into master before the end of Easter.

~Niels

[0] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=commit;h=0ce4b89f515afac59358090174c5dd794e887e1e

[1] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/hardening-support-rebased-ee869db

The "pre-rebase" variant is available as:

http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/hardening-support





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Sun, 01 Apr 2012 15:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Sun, 01 Apr 2012 15:45:09 GMT) Full text and rfc822 format available.

Message #149 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Sun, 1 Apr 2012 08:42:08 -0700
[Message part 1 (text/plain, inline)]
On Sun, Apr 01, 2012 at 05:16:38PM +0200, Niels Thykier wrote:
> Thanks, I have pushed it to my branch (with a minor change to also update
> the Depends of lintian in d/control).

Great!

> Kees, btw, are you certain of the copyright statements in
> collection/hardening-info?
> 
> """
> # The original shell script version of this script is
> # Copyright (C) 1998 Christian Schwarz
> #
> # The objdump version, including support for etch's binutils, is
> # Copyright (C) 2008 Adam D. Barratt
> #
> # This version, a trimmed-down wrapper for hardening-check, is
> # Copyright (C) 2012 Kees Cook <kees@debian.org>
> """
> 
> I suspect some of it is copy-waste from collection/objdump-info...

Yeah, when collection/hardening-info started its life, it was largely
copied from objdump-info. I wasn't sure if I should drop the copy rights
from there, so I left them. If they shouldn't be there, then we can
drop them (patch attached).

> > After this patch, the TODO's single remaining item is:
> > 
> >     + revise tag certainty and description:
> >       - overrides (we can't do much about FP etc.)
> > 
> > What is needed for this? Should I expand the descriptions more? Or was
> > there something else?
> >
> 
> It was mostly a reminder to myself to review them and maybe add a
> "disclaimer" on the false-positives.

Yeah, I tried to do this in the descriptions already, but maybe it
could be even more verbose. I wasn't sure to what level to get into
the details of the potential false positives. I am, of course, open to
any improvements! :)

> There was also something else, namely making the test suite able to
> handle the architecture specific nature of the hardening tags.  I
> have committed some code to handle this.[0]  Assuming no one objects
> to the approach, I think we are more or less good to go.

Ah! Yeah, very cool. That had totally slipped my mind.

> Optimally, Lintian would handle the architecture specific part of
> these tags better in terms of overrides so people do not have to
> maintain the archlist for their overrides.  However, that can come
> in Lintian 2.5.8 or some later time (if at all).

Wouldn't overrides only be a problem if a maintainer disabled a hardening
feature on a subset of the archs that expected it to be enabled? This
seems unlikely, or maybe I've misunderstood.

> I have rebased the branch and it is now available from [1] and I
> intend to merge it into master before we do the 2.5.7 release.
> As mentioned, I have added a new test suite hook[0], which some
> may (or may not) find controversial.
> 
> Assuming no comments/objections, I intend to merge the branch
> into master before the end of Easter.

Great! Thank you so much for all the help with this. :)

-Kees

-- 
Kees Cook                                            @debian.org
[copyright-cleanup.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Mon, 02 Apr 2012 09:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Niels Thykier" <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Mon, 02 Apr 2012 09:27:19 GMT) Full text and rfc822 format available.

Message #154 received at 650536@bugs.debian.org (full text, mbox):

From: "Niels Thykier" <niels@thykier.net>
To: "Kees Cook" <kees@debian.org>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Mon, 02 Apr 2012 11:25:26 +0200
On Apr 1, 2012 17:42 "Kees Cook" <kees@debian.org> wrote:
> On Sun, Apr 01, 2012 at 05:16:38PM +0200, Niels Thykier wrote:
> [...]
> > Kees, btw, are you certain of the copyright statements in
> > collection/hardening-info?
> > 
> > """
> > # The original shell script version of this script is
> > # Copyright (C) 1998 Christian Schwarz
> > #
> > # The objdump version, including support for etch's binutils, is
> > # Copyright (C) 2008 Adam D. Barratt
> > #
> > # This version, a trimmed-down wrapper for hardening-check, is
> > # Copyright (C) 2012 Kees Cook <kees@debian.org>
> > """
> > 
> > I suspect some of it is copy-waste from collection/objdump-info...
> 
> Yeah, when collection/hardening-info started its life, it was largely
> copied from objdump-info. I wasn't sure if I should drop the copy
> rights
> from there, so I left them. If they shouldn't be there, then we can
> drop them (patch attached).
>

Honestly, I am not too sure about Copyright and all.  I just guessed
it was copy-paste of the file header (I have been known to do that
myself) because I did not see a lot of resemblance with objdump-info.

Maybe some of the others know what the correct thing to do here.  :)

> > > After this patch, the TODO's single remaining item is:
> > > 
> > >     + revise tag certainty and description:
> > >       - overrides (we can't do much about FP etc.)
> > > 
> > > What is needed for this? Should I expand the descriptions more? Or
> > > was
> > > there something else?
> > >
> > 
> > It was mostly a reminder to myself to review them and maybe add a
> > "disclaimer" on the false-positives.
> 
> Yeah, I tried to do this in the descriptions already, but maybe it
> could be even more verbose. I wasn't sure to what level to get into
> the details of the potential false positives. I am, of course, open to
> any improvements! :)
> 
> [...]
> > Optimally, Lintian would handle the architecture specific part of
> > these tags better in terms of overrides so people do not have to
> > maintain the archlist for their overrides.  However, that can come
> > in Lintian 2.5.8 or some later time (if at all).
> 
> Wouldn't overrides only be a problem if a maintainer disabled a
> hardening
> feature on a subset of the archs that expected it to be enabled? This
> seems unlikely, or maybe I've misunderstood.
> 

No, At least the "hardening-no-stackprotector" can be triggered in a
perfectly safe program where the stack protector is not needed.  We
worked around this in the test suite by ensuring there was a stack
that needed protection, but I would be very sad to see people do
the same in real programs.

If I understood you correctly in comment 44, then the protected
functions could have the same issue:

"""
For example, if the only function used was gethostname(), it's possible to
do compile-time verification to see that the _chk() version isn't needed,
so even though the source was built with -D_FORTIFY_SOURCE=2, the
unprotected function will be used.
"""

Actually, come to think of it - hardening-no-stackprotector smells a bit
like a "wild-guess" since we can only say if it is safe, not if it might
be vulnerable.  Though "possible" -> "wild-guess" would change it from
a "W" to "I" tag (and therefore not visible by default).
  The fortify functions code (in hardening-check) at least makes an
educated guess and marks it safe if there are no uses of "possible
vulnerable" functions (or if there are mixed uses).  It may still be
wrong, but we will not get a false-positive if the binary do not use
any of the vulnerable functions.

Do anyone have comments on dropping the stack protector to wild-guess?

> > I have rebased the branch and it is now available from [1] and I
> > intend to merge it into master before we do the 2.5.7 release.
> > As mentioned, I have added a new test suite hook[0], which some
> > may (or may not) find controversial.
> > 
> > Assuming no comments/objections, I intend to merge the branch
> > into master before the end of Easter.
> 
> Great! Thank you so much for all the help with this. :)
> 
> -Kees
> 

You are welcome.  :)

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Mon, 02 Apr 2012 16:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Mon, 02 Apr 2012 16:33:06 GMT) Full text and rfc822 format available.

Message #159 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Mon, 2 Apr 2012 09:28:07 -0700
On Mon, Apr 02, 2012 at 11:25:26AM +0200, Niels Thykier wrote:
> No, At least the "hardening-no-stackprotector" can be triggered in a
> perfectly safe program where the stack protector is not needed.  We
> worked around this in the test suite by ensuring there was a stack
> that needed protection, but I would be very sad to see people do
> the same in real programs.

Well, I'd expect people to add an overrides file instead.

> If I understood you correctly in comment 44, then the protected
> functions could have the same issue:
> 
> """
> For example, if the only function used was gethostname(), it's possible to
> do compile-time verification to see that the _chk() version isn't needed,
> so even though the source was built with -D_FORTIFY_SOURCE=2, the
> unprotected function will be used.
> """
> 
> Actually, come to think of it - hardening-no-stackprotector smells a bit
> like a "wild-guess" since we can only say if it is safe, not if it might
> be vulnerable.  Though "possible" -> "wild-guess" would change it from
> a "W" to "I" tag (and therefore not visible by default).
>   The fortify functions code (in hardening-check) at least makes an
> educated guess and marks it safe if there are no uses of "possible
> vulnerable" functions (or if there are mixed uses).  It may still be
> wrong, but we will not get a false-positive if the binary do not use
> any of the vulnerable functions.
> 
> Do anyone have comments on dropping the stack protector to wild-guess?

Based entirely on the language, it seems like the stack protector warning
really is "possible". It's not "certain", for sure, but it doesn't seem
like what I'd think of as a "wild-guess". In practice, if its behavior
is more like the "wild-guess" checks, then it would make sense to drop
it to that level.

Perhaps we should examine some subset of the archive to figure out how
much noise these checks will add?

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Mon, 02 Apr 2012 17:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Mon, 02 Apr 2012 17:09:03 GMT) Full text and rfc822 format available.

Message #164 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: Kees Cook <kees@debian.org>, 650536@bugs.debian.org
Subject: Re: Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Mon, 02 Apr 2012 19:07:44 +0200
On 2012-04-02 18:28, Kees Cook wrote:
> On Mon, Apr 02, 2012 at 11:25:26AM +0200, Niels Thykier wrote:
>> No, At least the "hardening-no-stackprotector" can be triggered in a
>> perfectly safe program where the stack protector is not needed.  We
>> worked around this in the test suite by ensuring there was a stack
>> that needed protection, but I would be very sad to see people do
>> the same in real programs.
> 
> Well, I'd expect people to add an overrides file instead.
> 

Yes, but the tag will only be emitted on architectures that have
stackprotector enabled - hench the override ought to be architecture
specific.  At the moment the user/packagers will have to keep that
architecture list up to date in their override (or ignore it), and I
feel Lintian would do a better job given we have the information available.

>> If I understood you correctly in comment 44, then the protected
>> functions could have the same issue:
>>
>> """
>> For example, if the only function used was gethostname(), it's possible to
>> do compile-time verification to see that the _chk() version isn't needed,
>> so even though the source was built with -D_FORTIFY_SOURCE=2, the
>> unprotected function will be used.
>> """
>>
>> Actually, come to think of it - hardening-no-stackprotector smells a bit
>> like a "wild-guess" since we can only say if it is safe, not if it might
>> be vulnerable.  Though "possible" -> "wild-guess" would change it from
>> a "W" to "I" tag (and therefore not visible by default).
>>   The fortify functions code (in hardening-check) at least makes an
>> educated guess and marks it safe if there are no uses of "possible
>> vulnerable" functions (or if there are mixed uses).  It may still be
>> wrong, but we will not get a false-positive if the binary do not use
>> any of the vulnerable functions.
>>
>> Do anyone have comments on dropping the stack protector to wild-guess?
> 
> Based entirely on the language, it seems like the stack protector warning
> really is "possible". It's not "certain", for sure, but it doesn't seem
> like what I'd think of as a "wild-guess". In practice, if its behavior
> is more like the "wild-guess" checks, then it would make sense to drop
> it to that level.
> 


Maybe - I do not code C if I can avoid it, so I do not know how common
stack arrays are.  This is partly why I tried to invovle others in the
choice.  :)

> Perhaps we should examine some subset of the archive to figure out how
> much noise these checks will add?
> 
> -Kees
> 

Perhaps - unfortunately, the Lintian infrastructure cannot do it for us,
yet (see #660733).

~Niels





Added tag(s) pending. Request was from Niels Thykier <niels@thykier.net> to control@bugs.debian.org. (Wed, 04 Apr 2012 21:27:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Wed, 04 Apr 2012 21:46:51 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Wed, 04 Apr 2012 21:46:52 GMT) Full text and rfc822 format available.

Message #171 received at 650536@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: 650536@bugs.debian.org, Kees Cook <kees@debian.org>
Subject: Re: Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Wed, 04 Apr 2012 23:45:38 +0200
On 2012-04-01 17:16, Niels Thykier wrote:
> [...]
> 
> I have rebased the branch and it is now available from [1] and I
> intend to merge it into master before we do the 2.5.7 release.
> As mentioned, I have added a new test suite hook[0], which some
> may (or may not) find controversial.
> 
> Assuming no comments/objections, I intend to merge the branch
> into master before the end of Easter.
> 
> ~Niels
> 
> [0] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=commit;h=0ce4b89f515afac59358090174c5dd794e887e1e
> 
> [1] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/hardening-support-rebased-ee869db
> 
> The "pre-rebase" variant is available as:
> 
> http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/hardening-support
> 

Merged with some changes on the way:
 * Split Kees's second patch, merged + re-ordered some commits.
   - I only merged "minor" things into Kees commits to keep
     authorship fairly consistent.
   - Despite my changes, commits d44806c and e2544b2 are broken to
     some extend (first completely, second only on certain archs).
     - Note d44806c was broken due to infrastrucal changes done on
       my part interleaved with the given patch and not due to Kees.
 * Remove bindnow and nopie tags
   - It was not possible to trigger them (not enabled).
 * test calibration fix
   - I noticed that my original patch fails if the calibration
     removes a "Test-For" tag.

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#650536; Package lintian. (Wed, 04 Apr 2012 21:54:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. (Wed, 04 Apr 2012 21:54:08 GMT) Full text and rfc822 format available.

Message #176 received at 650536@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: 650536@bugs.debian.org
Subject: Re: Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
Date: Wed, 4 Apr 2012 14:52:07 -0700
On Wed, Apr 04, 2012 at 11:45:38PM +0200, Niels Thykier wrote:
>  * Remove bindnow and nopie tags
>    - It was not possible to trigger them (not enabled).

I guess this is okay since we'd need to rebuild lintian to get the new
dpkg-buildflags defaults if pie was enabled for an arch.

-Kees

-- 
Kees Cook                                            @debian.org




Reply sent to Niels Thykier <niels@thykier.net>:
You have taken responsibility. (Mon, 14 May 2012 22:21:19 GMT) Full text and rfc822 format available.

Notification sent to Moritz Muehlenhoff <jmm@debian.org>:
Bug acknowledged by developer. (Mon, 14 May 2012 22:21:19 GMT) Full text and rfc822 format available.

Message #181 received at 650536-close@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
To: 650536-close@bugs.debian.org
Subject: Bug#650536: fixed in lintian 2.5.7
Date: Mon, 14 May 2012 22:19:34 +0000
Source: lintian
Source-Version: 2.5.7

We believe that the bug you reported is fixed in the latest version of
lintian, which is due to be installed in the Debian FTP archive:

lintian_2.5.7.dsc
  to main/l/lintian/lintian_2.5.7.dsc
lintian_2.5.7.tar.gz
  to main/l/lintian/lintian_2.5.7.tar.gz
lintian_2.5.7_all.deb
  to main/l/lintian/lintian_2.5.7_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 650536@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Niels Thykier <niels@thykier.net> (supplier of updated lintian package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 14 May 2012 23:45:08 +0200
Source: lintian
Binary: lintian
Architecture: source all
Version: 2.5.7
Distribution: unstable
Urgency: low
Maintainer: Debian Lintian Maintainers <lintian-maint@debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Description: 
 lintian    - Debian package checker
Closes: 614034 628189 648777 649277 649852 650536 657402 660845 663516 664061 664471 664600 666207 666765 668546 671024 671537 672615
Changes: 
 lintian (2.5.7) unstable; urgency=low
 .
   * Summary of tag changes:
     + Added:
       - apache2-configuration-files-need-conf-suffix
       - apache2-deprecated-auth-config
       - apache2-module-depends-on-real-apache2-package
       - apache2-module-does-not-depend-on-apache2-api
       - apache2-module-does-not-ship-load-file
       - apache2-reverse-dependency-calls-invoke-rc.d
       - apache2-reverse-dependency-calls-wrapper-script
       - apache2-reverse-dependency-ships-file-in-not-allowed-directory
       - apache2-reverse-dependency-uses-obsolete-directory
       - apache2-unparseable-dependency
       - apache2-unsupported-dependency
       - diff-contains-quilt-control-dir
       - hardening-no-fortify-functions
       - hardening-no-relro
       - hardening-no-stackprotector
       - non-standard-apache2-configuration-name
       - non-standard-apache2-module-package-name
       - rc-version-greater-than-expected-version
       - udeb-uses-unsupported-compression-for-data-tarball
       - web-application-depends-on-apache2-data-package
       - web-application-should-not-depend-unconditionally-on-apache2
     + Removed:
       - ancient-dpkg-long-filenames-check
       - ancient-dpkg-predepends-check
       - bad-ubuntu-distribution-in-changes-file
       - binary-nmu-uses-old-version-style
       - debian-control-with-duplicate-fields
       - doc-base-file-references-usr-doc
       - duplicate-fields-in-templates
       - manpage-for-non-x11-binary-in-wrong-directory
       - manpage-for-x11-binary-in-wrong-directory
       - missing-dependency-on-install-info
       - obsolete-field
       - old-app-defaults-directory
       - old-style-copyright-file
       - old-style-example-dir
       - package-installs-file-to-usr-x11r6-bin
       - package-installs-font-to-usr-x11r6
       - package-uses-obsolete-file
       - postinst-should-not-set-usr-doc-link
       - raster-image-in-scalable-directory
       - udeb-uses-non-gzip-data-tarball
       - x11-games-should-be-in-usr-games
 .
   * checks/*:
     + [NT] Remove some old tags that are no longer useful.
       (Closes: #663516)
     + [NT] Migrate to sorted_index from sorted_file_info.
     + [NT] Explicitly import needed subs from L::Util.
   * checks/apache2{,.desc}:
     + [NT] New files to check for apache2 related packages.  Thanks
       to Arno Töll and Stefan Fritsch for the patches.
       (Closes: #668546)
     + [NT] This check is not enabled by default.  It can be used
       via the debian/extra-apache2 profile.
   * checks/binaries{,.desc}:
     + [NT] Move embedded library data to a data file.
     + [NT] Add ELF hardening checks.  Thanks to Kees Cook for
       report and the patches.  (Closes: 650536)
     + [NT] Replace architecture tables with data files.
     + [JW] Check for missing Python3 numpy ABI dependency.
       (Closes: #671024)
   * checks/changelog-file:
     + [NT] Output the correct line number for the "line-too-long"
       tag.  Thanks to Arno Töll for the report.  (Closes: #657402)
   * checks/changes-file{,.desc}:
     + [NT] Remove Ubuntu specific handling of distribution names.
       Instead replace it with a more generalized one that derivatives
       can reuse by extending vendor specific data files.  Thanks to
       Daniel Dehennin for the suggestion.  (Closes: #648777)
   * checks/control-file:
     + [NT] Rewrote parts to use Lintian::Collect for fetching data.
   * checks/cruft{,.desc}:
     + [NT] Check for quilt control dirs in the debian packaging files.
   * checks/deb-format{,.desc}:
     + [NT] Replace old udeb compression tag with a more general
       one.  (Closes: #664600)
     + [NT] Remove logic for checking if a deb is meant for
       Ubuntu.  Instead unconditionally emit the tag and let the
       vendor profiles handle it.
   * checks/debconf:
     + [NT] Special case debconf providers for purge-debconf tag.
       Generally they cannot use db_purge in postrm (for obvious
       reasons), so the tag will be a false-positive in such
       cases.
   * checks/fields{,.desc}:
     + [NT] Add devref reference.
     + [NT] Remove special handling of the Ubuntu specific field,
       "original-maintainer".  This field is now handled by vendor
       specific data files.  (Closes: #649852)
     + [JW,NT] Check for common mistakes with preview release and
       release candidate versions.  For non-native packages, this
       check is only done on initial uploads of new upstream
       releases.  Thanks to Stefano Rivera and Julian Taylor for
       their additional suggestions.  (Closes: #649277)
   * checks/filename-length.desc:
     + [ADB, NT] Reword description of package-has-long-file-name.
       Thanks to Andreas Beckmann for suggestion.
   * checks/files{,.desc}:
     + [NT] Remove "manual" lazy loads of data files.
     + [NT] Remove code for the uses-FHS-doc-dir tag.
     + [NT] Extend icon checks to all icon directories and look for
       raster images in "scalable" icon directories.  Thanks to
       Paul Wise for the report and Felix Geyer for the patches.
       (Closes: #628189)
   * checks/group-checks:
     + [NT] Include Provides when checking for conflict relations.
       Thanks to Damyan Ivanov for the report.  (Closes: #672615)
   * checks/java:
     + [NT] Ignore "codeless" jars if they appear to be maven
       javadoc jars.  Thanks to Ludovic Claude for the patch.
       (Closes: #660845)
   * checks/lintian.desc:
     + [NT] Updated the description of the override tags.
   * checks/manpages{,.desc}:
     + [RA] Detect hyphen used as minus sign following a groff \f[C] font
       change.  Thanks, Iustin Pop.  (Closes: #664471)
   * checks/menu-format:
     + [NT] Move menu section lists into a data file.
     + [NT] If a package is missing a menu icon, check its direct strong
       dependencies built from the same source (if any) for the icon.
       This fixes false-positives menu-icon-missing in some cases.
   * checks/menus{,.desc}:
     + [NT] Remove "manual" lazy load of data file.
   * checks/nmu:
     + [NT] Remove Ubuntu specific code to handle their (lack of) NMUs.
       These tags are instead suppressed by the Ubuntu profile.
   * chekcs/rules:
     + [NT] Fix false-positive "ignores-make-clean-error" tag caused by
       using make with -C and a dir containing the letter "i".  Thanks to
       Tobias Hansen for the report.  (Closes: #671537)
   * checks/scripts{,.desc}:
     + [NT] Mention devref 6.4 in command-with-path-in-maintainer-script.
       Thanks to Arno Töll for the patch.
     + [NT] Do not emit unusual-interpreter if the package provides the
       interpreter itself.
     + [NT] Ignore the lack of exec bit on th debconf shell modules.
   * checks/standards-version.desc:
     + [NT] Add references to the Policy upgrading checklist.  Thanks to
       Simon Paillard for the patch.
 .
   * collection/*:
     + [NT] Use Lintian::Collect to access the package index.
   * collection/bin-pkg-control{,.desc}:
     + [NT] Compress control-index file and bump version of
       bin-pkg-control.
   * collection/copyright-file:
     + [NT] Remove code to look for old-style copyright file.
   * collection/file-info{,.desc}:
     + [NT] Compress file-info output and bump version of file-info.
   * collection/hardening-info{,.desc}:
     + [NT] New files.  Thanks to Kees Cook for the patch.
   * collection/index{,.desc}:
     + [NT] Compress index output and bump version of index.
   * collection/java-info{,.desc}:
     + [NT] Compress java-info output and bump version of java-info.
   * collection/objdump-info:
     + [NT] Use "fail" from Lintian::Util.pm rather than embedding a
       copy of it.
     + [NT] Use Lintian::Collect to find ELF files.
     + [NT] Replace all usage of objdump with readelf.
       (Closes: #614034)
     + [NT] Compress objdump-info output and bump version of objdump-info.
   * collection/strings{,.desc}:
     + [NT] Compress strings output and bump version of strings.
 .
   * data:
     + [NT] Move to vendors/debian/ftp-master-auto-reject and replace
       it with a symlink.
   * data/binaries/{arch-{64bit-equivs,regex},hardening-tags}:
     + [NT] New file.
   * data/binaries/embedded-libs:
     + [NT] New file.
     + [NT] Add libav libraries.  Thanks to Andres Mejia for the
       suggestion and the suggested patch.  (Closes: #666765)
   * data/changes-file/{debian-dists -> known-dists}:
     + [NT] Renamed file.
   * data/menu-format/menu-sections:
     + [NT] New file.
 .
   * debian/changelog:
     + [NT] Amend the 2.5.5 to mention that it also added the tag
       binaries-have-file-conflict.
 .
   * frontend/lintian:
     + [JW] Fix typo in error message.
     + [JW,NT] Fix handling of "override" option in the lintianrc file.
       (Closes: #666207)
 .
   * lib/Lintian/Architecture.pm:
     + [NT] Lazily evaluate the data file.
   * lib/Lintian/Collect/Package.pm:
     + [NT] Remove an extra level of quoting in index.
     + [NT] Remove root dir from sorted_index.
     + [NT] Keep trailing slash in dir names for file_info.
   * lib/Lintian/Collect/Binary.pm:
     + [NT] Remove sorted_file_info as sorted_index now produces
       an identical list.
   * lib/Lintian/Data.pm:
     + [NT] Lazily load data files.
     + [NT] Allow pre-process sub to alter existing value for a key
       by passing the previous value as third argument.
     + [NT] Allow vendor specific data files.  They will be loaded
       from LINTIAN_ROOT/vendors/$profile/data.
   * lib/Lintian/Output{,/*}.pm:
     + [NT] Replace non-printables with "?" in output.
   * lib/Lintian/Profile.pm:
     + [NT] Normalize profile name and replace "parents" with
       "profile_list".  The latter also includes the current profile
       name.
   * lib/Lintian/Tag/Info.pm:
     + [NT] Use Lintian::Data to load the manual-references data
       file instead using an ad-hoc parser.
   * lib/{Text_utils => Lintian/Tag/TextUtil}.pm:
     + [NT] Renamed module.
   * lib/{Util => Lintian/Util}.pm:
     + [NT] Renamed Util to Lintian::Util.
     + [JW] Consider duplicate fields a syntax error in dctrl files.
       Previously, duplicate fields were silently ignored (except
       when a separate tag would check for it).  (Closes: #664061)
     + [NT] Stop exported a majority of all subs by default.
 .
   * profiles/ubuntu/main.profile:
     + [NT] Add a number of NMU related tags to the list of disabled
       tags.
 .
   * vendors/ubuntu/main/data/changes-file/known-dists:
     + [NT] New file based on data/changes-file/ubuntu-dists.
     + [ADB] Add "quantal" (Quetzal)
   * vendors/ubuntu/main/data/common/source-fields:
     + [NT] New file.
   * vendors/ubuntu/main/data/fields/{binary,udeb}-fields:
     + [NT] New files.
Checksums-Sha1: 
 0b03babd3aa8571eb0af02af768f7c4fade12fbd 2462 lintian_2.5.7.dsc
 3af1c36dbe4ae3dc7b70aa375107928c28c8555f 1087847 lintian_2.5.7.tar.gz
 2ebf64764da8e9b03cea8555ec6db1cf5da38f59 692506 lintian_2.5.7_all.deb
Checksums-Sha256: 
 0dd400eff2da35e2e1b39370a0edf8a918ce3e3cdd68b6be2fcb53ae8a143e5f 2462 lintian_2.5.7.dsc
 c56d7550e10acb7672708911c7636611d128ab7ec3eded8e70035737581f1a26 1087847 lintian_2.5.7.tar.gz
 5fd3554d5e76aa70334a4a56f87c75fe6a287b9723d64330621d7a423fffb2a0 692506 lintian_2.5.7_all.deb
Files: 
 ab60445e9f6618d0b9349dbc8e3455c3 2462 devel optional lintian_2.5.7.dsc
 ec47bdf0735e61fffd0a582cd76cdb74 1087847 devel optional lintian_2.5.7.tar.gz
 af45b86b4b0a254ab0cb46fab4de2bbf 692506 devel optional lintian_2.5.7_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPsYILAAoJEAVLu599gGRCaAEQAIs32SOJUFQMhKA5KMyPX7Ps
Xr74WsCkSbyw5/klXdzkiFkf7mgcpuonYCBucTqRFWqyRCbtFPBtuogR8JSXyuG6
XvI4nOrKmkIGRGj2vnIyL1Jm/oaJZv4gkZBqRNKpQGpTuTk57yqmnl3TzXXDydh8
/HeOzE66XpCGBVqOygbBltQHPKXGE6U0O/h6pwwOglrsiW0/rV0AAY+pbk62TJxx
3NPZjlORSSJLtVgM+EZ1zKY4t+KdmqTXqpGyVhiMhs2u9FKnG3oCUlfPS+2kWFKq
ZDdAD016a5CAH5xcUf3uNujlzuwFDgqjzCGG9c1oH8esvgL+nPKwBiaAeP1/AOTO
aBQRERq4fo41SPFMcq8F5AtHw6AaEfKS5iJ/kSUds+8lI26alCezIRLL1TpbhrqV
/LzLfKbp1aERek00kXr9K/P6Ke3ZCXMvdMqAGBvNvlThmPP0eG7H3IUE6yrHacvi
UAbOjCGSMpJVrAeQ3zXKjFNUwYQ0Ykjqw9gWaWSbpo3RPAzmugBDrZQhS9yLFkDC
9jqo8gfOkKTXpL87Vk1jil1n7nLcDb/O4vW4/k5TK/sX1GY7zUzINk8pqpKmbIlP
/yH1VJyhi2c7WO176dTFpoh7HkdLm8AIGONuLHGzYiYJ6Diy3kExbkMFqsC1TjVk
SdFPmfihW8KzGJ4n7pqy
=lpp5
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 12 Jun 2012 07:38:41 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 01:20:40 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.