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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org