Hi, On Wed, 27 Jul 2011, Kees Cook wrote: > > TODO: revert debian/buildflags support, and implement > > support for the environment variable DEB_<flag>_MAINT_<operation> which > > work exactly like the corresponding DEB_<flag>_<operation> except it's > > meant to be used by the package maintainer within debian/rules. > > I'm not sure how this will interact with hardening options, but okay.
It's not really relevant for hardening options except that if we want to make dpkg-buildflags a mandatory interface to retrieve the complete set of build flags, it's important that the interface it offers can be used in all cases. > > QUESTION: Is this ok to assume that all build flags can be "delimited" > > by a space character? > > For the hardening flags, yes. The question was more general because it's a generic interface for dpkg-buildflags and it should handle any build flag that might realistically be used. > > Assuming that all those improvements are done, the consensus was that > > it's fine for dpkg-buildflags to start emitting the hardening build > > flags by default. According to Ubuntu's experience only a few dozen of > > packages are broken by the presence of these flags and those packages > > should just be updated to use the new STRIP operation to drop the > > problematic flags. This could be dealt as part of a wheezy release goal. > > And a large portion of them are already fixed since Ubuntu reported the > bugs to Debian and most were fixed. How are they fixed? By adding DEB_BUILD_HARDENING_* := 0 in their environment? > I see three remaining issues: I think all those issues are to be sorted between you and me, and do not need the involvment of the technical committee (but obviously I always welcome review by anyone even of TC members :)). > - by what mechanism will dpkg-buildflags use hardening-includes? It > wouldn't make sense to duplicate the existing arch-specific logic > that lives in hardening-includes. It would not be reasonable for dpkg-dev to depend on hardening-includes so my plan was basically to move this logic into dpkg-dev. But instead of duplicating it we can find a way for hardening-includes to reuse the logic that would be integrated in dpkg-dev. All the code is in libdpkg-perl and we can decide to have a specific function that retrieves only the hardening build flags instead of all the build flags. That said, why should hardening-includes last any longer if dpkg-buildflags offers everything it does? > - should the hardening flags presence still be controlled by the env > variables that are exposed as the existing interfaces defined by > hardening-wrapper/hardening-includes? If that's how current debian packages have been fixed, possibly yes at the start but we would emit a warning explaining that package have to be updated to use the new STRIP dpkg-buildflags operation. And at some point, the support for those env variables should be dropped. > - there needs to be a way to identify those architectures that are > "register starved", since those should _not_ get the PIE flags by > default (e.g. i386 should not get PIE, but amd64 should get PIE by > default). Right now if one uses hardening-wrapper, it's expected > that everything that can be enabled is enabled, so you gain PIE > even on i386 at the moment. Not sure I understand your problem. What's difficult in excluding i386 from the set of architectures where PIE is used? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org