Bug#687704: speex: Hardening flags missing

[Simon Ruderich]

On Mon, Sep 17, 2012 at 11:26:44PM +0930, Ron wrote:
>> 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 ...

It's not really a hardening flag, true. But it prevents
oversights and I think it can't hurt to add it.

>> 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.

On the other hand it doesn't require you as maintainer to track
the support of certain hardening flags on different architectures
in all your packages.

> [snip]
>
> 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).

I don't think it was a mistake. It enables a basic set of flags
for all packages without too much effort for the maintainer. Of
course it would be better if all maintainers would carefully take
care of hardening their package, but at least it enables basic
hardening for many packages.

> 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.

I'm curious. What hardening flags do you consider obsolete or
missing?

> [snip]
>
> 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

That's not my idea. I just proposed these changes because I
thought they would make it easier for you as maintainer - and to
enable all the default "hardening" flags set by dpkg-buildflags.

> [snip]
>
> 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?

It does. I can understand why you want to have control of all the
flags used in the build and I didn't want to push my patch onto
you. I just thought it was the simplest way to get all the
hardening flags, but I get your point of manual control.

Regards,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20120919/566dfdf4/attachment.pgp>