On Mon, 21 Jul 2008, Kees Cook wrote: > Well, the original goal was to move the hardening option knowledge out > of hardening-wrapper and into dpkg-buildpackage, so this was designed to > be a migration path.
Why do we need a migration path and not a direct migration ? Since hardening-wrapper does nothing without environment variables and since dpkg-buildpackage already provides default values to compiler flags... what would be the required intermediary step between: "hardening-wrapper does the job" and "dpkg-buildpackage does the job" ? > Since dpkg-buildpackage is setting the default compiler flags (-g -Wall, > etc), this seemed like a sensible place for the other distro-wide flags > to go live so we can get rid of the crazy hack that is > hardening-wrapper. :) Indeed. But your patch was not changing the distro-wide flags. :) > > Note that I'm not opposed to have dpkg-buildpackage enable hardening > > by default in the future (by auto-setting the option unless instructed > > otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just > > want to not bloat dpkg-buildpackage with too much specific code like this > > one and want to integrate this change in a more generic framework. > > Sure, I can certainly understand that. Will there be a framework that a > compiler flag default option system can be plugged into? I haven't thought about this yet. As you noticed, the framework I was referring to was more for controlling DEB_BUILD_OPTIONS than for controlling CFLAGS & all. But, if someones comes up with a sensible design for such a framework, I'm happy to give it a try. But I'm not sure if it would add any value compared to some hardcoded rules to generate the compiler flags. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
