Re: Bug#657853: Building perl with hardened build flags
Trying to pull a few of the subthreads together:
On Sun, Feb 12, 2012 at 09:24:40PM +0100, Moritz Mühlenhoff wrote:
> On Sun, Feb 12, 2012 at 02:54:59PM +0200, Niko Tyni wrote:
> > 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 :-)
On Thu, Feb 16, 2012 at 06:46:36PM -0400, Joey Hess wrote:
> gregor herrmann wrote:
> > Assuming they are all uploaded and all arch:any (and only looking at
> > packages in the Debian perl Group):
> >
> > % grep 9 */debian/compat | wc -l
> > 31
>
> Well, it seems easy enough to test 30 packages. It would help if someone
> developed a patch before there are too many more.
On Fri, Feb 17, 2012 at 12:36:21PM +0200, Niko Tyni wrote:
> On Sun, Feb 12, 2012 at 09:24:40PM +0100, Moritz Mühlenhoff wrote:
> > On Sun, Feb 12, 2012 at 02:54:59PM +0200, Niko Tyni wrote:
> > > > On Fri, Feb 10, 2012 at 11:29:09PM +0200, Niko Tyni 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.
>
> I think it's my preferred alternative as well.
>
> If we have consensus on that, the way forward as I see it:
>
> - prepare a perl upload in unstable that is built with the hardened flags
> but doesn't export them through Config.pm
(for which you've submitted a patch separately; thanks)
> - preferably fix #660195 (recursive Makefile.PL arguments) while at it
Yeah, this does looks like it needs to be fixed soon (otherwise the
release goal packages won't be completely hardened; it's also possible
that some of the dual-lived modules in perl itself are affected in this
way).
>From a review of the upstream bug, it doesn't looks like it should
be very hard to fix...
> - find the optimal invocations of Makefile.PL and Build.PL
> that honour all of CFLAGS, CPPFLAGS, and LDFLAGS
> - either
> + change the handful of release goal packages to use those invocations
> instead of the debhelper v9 defaults, and make debhelper v10 to use
> them by default after wheezy
> or
> + test the 30 or so affected packages and change debhelper v9
> for wheezy
Given the messages I've quoted above, deferring debhelper changes until
v10 makes most sense. This means we can file bugs on the release goal
packages to use the invocations manually in the meantime, as well as
a wishlist bug on debhelper for v10 (so we don't forget).
> For reference, the invocations I came up earlier were
>
> perl Makefile.PL OPTIMIZE="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
> LD="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"
>
> perl Build.PL --config optimize="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
> --config ld="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"
>
> but I didn't dwell long on that and there might be better ways to do
> this. In particular, I think EU::CBuilder already honours some of the
> flags so they might end up being used twice in the Build.PL version?
That should be good enough to suggest a way forward for bug reporting
for the release goal packages and/or updating [1].
> I don't have much time to work on this myself, help welcome.
Ditto. I think we have a way forward now which allows to to move
forward just far enough. Hopefully pkg-perl and other module maintainers
will be in a position to take on the task of updating release goal
modules once a recipe has been sorted out.
Dominic.
[1] <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Reply to: