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 :-)
Cheers,
Moritz
Reply to: