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)
> > >
> > > 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.
>
> > > C. force the flags that Perl was compiled with to the XS modules via
> > > $Config{ccflags} and friends
>
> > Yes, I hadn't considered impact on non-packaged XS modules; it's probably
> > less acceptable for them to have to opt-out. A shame, since it's the
> > best way of ensuring that the buggy packages do get fixed, and in many
> > ways my preferred option.
>
> Yes, it certainly has upsides. I'm not totally ruling it out, but
> it doesn't feel "right" to me.
>
> > > 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.
Except perhaps for the modules which are specifically included in
the wheezy criteria:
<http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>
I don't know how many of those there are.
I realised that this thread is pretty relevant - I'm afraid I forgot
about some of the detail in there:
<http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2012-January/050055.html>
<http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2012-January/050100.html>
> > > Options A and B also require some fiddling inside the perl package to
> > > prevent the hardening flags from going into $Config{ccflags} and friends
> > > even if we build perl itself with them. I don't except this to be
> > > a big problem.
> >
> > Although it may well be straying in a direction that upstream doesn't
> > like.
>
> I was thinking of a running sed on Config_heavy.pl after the build to take
> the dpkg-buildflags induced options out. I think that's in our domain.
> If there's a cleaner way to apply those flags to the Perl build without
> imposing them on XS modules, I'd certainly be happy to adopt that.
This sounds like a reasonable way.
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
