[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enabling hardened build flags for Wheezy

Charles Plessy <plessy@debian.org> writes:

> all our packages include a way to pass build flags to the upstream build
> system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.
> It would have been trivial to pass the hardening flags automatically
> through the same communication channel.

I don't understand what you mean.  Explicit logic is required in
debian/rules to handle DEB_BUILD_OPTIONS=noopt unless you use a helper
system that embeds that logic.  There's nothing magic about that.  dh
deals with it for you, of course, but it's no different so far as I can
tell from the way hardening flags were implemented, except that it's much
simpler to change the optimization level than it is to harden all the
parts of the build.

> Unfortunately, the hardening build flags have been split in three
> variables.  To make sure they are passed correctly, either the upstream
> makefiles have to be modified, or debian/rules has to be modified.

Well... it's usual to have to modify debian/rules to adjust to new
features of the Debian build system, no?  It's a pretty simple one-time
change, isn't it?

> Why couldn't we design a solution that does not require these
> modifications except for corner cases ?

We did... that's dh.  dh 9 just picks up hardening flags and just works
without any changes required for any Autoconf-enabled package, or for any
package with another build system that it understands.

> It does not matter that they are trivial, the point is that if most C
> programs need to have the same override in debian/rules, it feels that
> there is something wrong.

Most C programs use Autoconf in my experience.  I know that scientific
software often doesn't, but I think scientific software is the significant
outlier in that respect.

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

Reply to: