Hi, On Thu, 28 Jul 2011, Kees Cook wrote: > On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote: > > The current implementation in my branch is that PIE is disabled by defaut > > but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was > > easily done on top of the compatibility layer with > > hardening-includes/hardening-wrapper but I'm not convinced it's an > > interface we want to use for this transition. > > If someone chose to build-dep on hardening-wrapper/hardening-includes, they > expect to have built PIE, so I think that the dpkg-buildflags default > should likely depend on that in some way.
Do you mean analyze the build-dep to automatically enable PIE? That doesn't seem clean and I'd rather have maintainer make it explicit. If hardening-includes/hardening-wrapper is still used by that package, does it really matter what dpkg-buildflags is returning? > The problem here is that h-w/i defaults to PIE-when-supported rather than > PIE-when-supported-and-desired, so having a maintainer explicitly set > DEB_BUILD_HARDENING_PIE=1 will trigger FTBFS on the architectures that > don't support it. I think we'll need some other flag instead that means > "PIE if possible" when moving to dpkg-buildflags from h-w/i. Why? If a package migrates from h-w/i to dpkg-buildflags I don't expect it to keep using h-w/i. > There's a lot of ways to do this. I'm not sure what is best. What's > important to me is that maintainers that were using h-w/i don't suddenly > end up with builds that aren't PIE, since they explicitly chose to build > with PIE (unless they also explicitly chose to disable it). That seems a matter of properly documenting the transition from one to the other. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
