[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#657853: Building perl with hardened build flags

[Adding Joey Hess to CC]

On Sun, Feb 12, 2012 at 02:54:59PM +0200, Niko Tyni wrote:
> [Thanks for taking this to the list; should've done that myself.
>  Just a couple of quick comments for now.]
> On Sat, Feb 11, 2012 at 01:51:19PM +0000, Dominic Hargreaves wrote:
> > On Fri, Feb 10, 2012 at 11:29:09PM +0200, Niko Tyni wrote:
> > > On Thu, Feb 09, 2012 at 08:44:25PM +0000, Dominic Hargreaves wrote:
> > > A. make debhelper pass all of CFLAGS, CPPFLAGS, and LDFLAGS down to
> > >    ExtUtils::MakeMaker and ExtUtils::CBuilder via suitable command line
> > >    invocations (it currently passes only CFLAGS, starting with compat
> > >    level 9)

I would prefer this strategy.

Joey, are you comfortable with changing this for debhelper compat 9,
although it has been finalised already?

> > > B. make ExtUtils::MakeMaker and ExtUtils::CBuilder honour all of
> > >    CFLAGS, CPPFLAGS, and LDFLAGS from the environment (debhelper
> > >    sets these with compat level 9)
> > 
> > You haven't made it explicit, but I assume that the opt-out strategy
> > here is to unset those environment flags in debian/rules (there is
> > no specific way to opt-out with debhelper incantations that I can see).
> debhelper v9 sets CFLAGS and the rest based on dpkg-buildflags, so
> DEB_BUILD_MAINT_OPTIONS would be the way to opt out of specific hardening
> flags when necessary.

Agreed. DEB_BUILD_MAINT_OPTIONS="hardening=-format" would be an exemplary
way to disable format string checks.

> > > Options A and B both require compat level changes to the all the XS
> > > module packages. On the positive side, that also brings in the support
> > > for DEB_BUILD_OPTIONS=noopt.
> > 
> > The compat changes are only required to get the benefit of hardening
> > flags in those modules, which isn't strictly speaking necessary within
> > the wheezy timeframe, AIUI. (In other words, we can satisfy the request
> > to build perl itself with hardening flags without touching any other
> > packages, if we implement A or B.)
> That's a good point about the timeframe. So there's no real hurry with
> the proposed debhelper changes in option A, they can be done after wheezy.

Yep. The release goal for Wheezy is "fix as many as possible, but make
a concentrated effort for all packages of priority >= important and 
which had a DSA since 2006. perl itself matches both conditions :-)

Reply to: