Bug#656656: Please enabled hardened build flags

[Russ Allbery]

"Cantor, Scott" <cantor.2 at osu.edu> writes:
> On 1/27/12 12:28 PM, "Russ Allbery" <rra at debian.org> wrote:

>> Hm.  Well, the xmltooling build system is straightforward Autoconf and
>> Automake, and I'm really at a loss as to what the build system could
>> possibly be doing that would cause this.  You can see from the build
>> log that the right flag is being passed to the compiler:

> Not that it's necessarily likely here, but with the --silent flag on to
> limit noise, you actually can't tell what the actual compiler command
> is.  There are libtool bugs, usually on Solaris one finds, that break
> the use of some flags. I guess it's possible something like that could
> be happening.

True.  Okay, let me go do a manual build where I can remove --silent and
be sure that things are actually being passed down to the compiler.

> Is this whole set of options portable? If they're legal on any gcc, I'm
> fine adding them to the default flag set for it. If it's highly
> variable, not so much.

I think you need particular versions of gcc for the whole set of things
that Debian is starting to add, but -D_FORTIFY_SOURCE=2 should generally
be harmless even if it's not recognized.

The flags that I'm enabling are:

format          CXXFLAGS = -Wformat -Wformat-security -Werror=format-security
fortify         CPPFLAGS = -D_FORTIFY_SOURCE=2
stackprotector  CXXFLAGS = -fstack-protector --param=ssp-buffer-size=4
relro           LDFLAGS = -Wl,-z,relro

(not because any particular one has any particular effect on this package,
but just because that's the default set).

-Wformat-security wasn't always there in gcc, but it's been there a long
time.  -D should always be harmless.  stackprotector I'm not sure about;
that could well be rejected by older versions.  relro is, of course,
specific to the GNU ld and may or may not be recognized elsewhere, and I'm
not sure what version of GNU ld adds it.

Although, more generally, Debian will probably keep tweaking and changing
these flags, and this build mechanism is intended to allow us to just
rebuild the whole archive when the build flags change without having to
change any individual package.  So from Debian's perspective, I think
we'll want the mechanism of passing those flags to configure to work
regardless, although adding those flags for builds outside of Debian's
build machinery would likely increase security (on Red Hat, for example,
if Red Hat's RPM build system isn't already doing something similar).

But in general I don't think xmltooling is doing anything wrong.  I'll go
poke some more and try to confirm that.

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