Bug#687704: speex: Hardening flags missing

[Ron]

On Sun, Sep 16, 2012 at 07:03:27PM +0200, Simon Ruderich wrote:
> On Sun, Sep 16, 2012 at 08:10:12PM +0930, Ron wrote:
> > On Sat, Sep 15, 2012 at 12:53:53PM +0200, Simon Ruderich wrote:
> >> Some hardening flags (format flags and relro on some archs) are
> >> still missing because they are not set in debian/rules.
> >
> > Do you have some actual evidence of that?
> 
> Of course. Either look at the build logs on your own, or use a
> tool like blhc to check the build logs.

Yes, I read the build logs fairly carefully on my own when I first
added these flags.  There's not a lot of point enabling additional
compiler warnings if you aren't going to actually look to see if
they were emitted ...

> The following flag is missing:
> 
>     -Werror=format-security

Uh.  That's not a hardening option.

That's road spikes for people who blindly applied dpkg-buildflags
and didn't actually bother to look at their build logs ...


> I made a mistake about the relro flags, that was a false
> positive, they are applied correctly. Sorry for that.
> 
> > Since the patch you attached _removes_ the lines that set these
> > things from rules - I'd have thought the obvious incorrectness
> > of that statement would be obvious.
> 
> The patch removes the manually added flags, but uses
> dpkg-buildflags which automatically applies all the default
> hardening flags.

... which provides a lesser degree of checking than what the
existing options enable.  And makes it far more difficult to
know for certain what any individual build might actually use
on a given system.  And a greater burden to track how it might
silently change over time.


> The general consensus (see [1], and the links in my original
> post) is to use dpkg-buildflags as global institution which
> decides which flags to use by default (and to handle platform
> specific flags in one place, and not in each package), that
> includes hardening flags.

I'm pretty sure that general consensus isn't arrived at by someone
writing their personal preference that people use the new tool they
wrote on a wiki page ...

Especially when even that page sort of grudgingly half-mentions
there are other ways to do this too.


It was a mistake for dpkg to start messing with package build options,
and it's only slightly less of a mistake to let some other external
tool be doing that too (the slightly less part being it's more obvious
how (and the default) to opt out).

The hardening flags that dpkg-buildflags provides were cargo-culted
from the rules and exceptions in the hardening-wrapper package, without
paying any attention to (or fixing) how badly out of date some of those
exceptions now are.  Despite there being comments and references there
which should have made that quite obvious to even a casual enquirer.

That doesn't really make me have more confidence in it than in the job
that I and upstream can do wrt selecting the best set of build options
for a particular package to use.


I'm sorry if that doesn't really fit with your idea of "just close your
eyes and let other people take care of it" here.  But there really was
some thought that went into deciding what options were appropriate for
this package (and even benchmarks done on options we worried might be
more expensive than the protection they added was worth).  I'd really
rather that it actually remain perfectly clear that the options being
used were a conscious and informed selection - and that the history of
the package should show how and when things related to that changed.

If there are real bugs in that, or valuable options that we might be
missing, then I'd love to hear about that.  But I don't really see any
value in throwing away the work done to make these decisions and just
leaving it to the whims of an external agent, which almost certainly
will not test its changes against this package.

Does that make sense?

 Cheers,
 Ron