Re: Bug#657853: Building perl with hardened build flags
[Adding debian-perl, since the decisions we take might have a wide
impact].
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:
> Going back to square one, I see three options for pushing
> the hardening flags to the XS module packages:
>
> 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).
> C. force the flags that Perl was compiled with to the XS modules via
> $Config{ccflags} and friends
>
> Option A has the downside that it probably requires a debhelper
> compat bump, so I doubt it can happen for wheezy. It's IMO the
> cleanest one as it uses existing interfaces and doesn't require
> any patching (except for subdirectory Makefile.PL files; see below.)
>
> Option B requires patching EU::MM, which always makes me nervous.
> Note that AFAICS ExtUtils::CBuilder (which is used by Build.PL based
> build systems) already honours CFLAGS and LDFLAGS.
>
> Option C is what was implemented in perl 5.14.2-8/experimental. Its
> upside is that it doesn't require any changes to existing (non-buggy) XS
> module packages. The downsides are that it has a flag day for the dozen
> or so buggy packages, it's opt-out for all XS modules (both packaged
> and non-packaged), and there's currently not even a way to opt out
> (implementing your NOCCFLAGS suggestion would fix this.) This makes me
> think it's the worst of the options above.
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.
> 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.)
> 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.
> > Presumably we'd need to fix ExtUtils::MakeMaker too.
>
> Heh, indeed. For some reason I thought it uses EU::CBuilder too,
> but obviously not.
>
>
> I haven't really investigated yet what it would take to implement
> option B.
>
> For option A, I see we could get EU::MakeMaker to act in the desired
> way by running
>
> perl Makefile.PL OPTIMIZE="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
> LD="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"
>
> OTHERLDFLAGS would be even cleaner, but for some reason it can't be
> specified on the command line (only in Makefile.PL or on the actual
> 'make' invocation.)
>
> A complication: testing with libimager-perl, I see that any command line
> Makefile.PL parameters are *not* passed to any subdirectory Makefile.PL
> invocations. This seems to be a known bug, and an old one at that.
> See [rt.cpan.org #28632] and [rt.cpan.org #67407]. I guess we could fix
> this if necessary. Fortunately, subdirectory Makefile.PL files are an
> exception rather than the norm (I think.)
Right.
> For Module::Build, the invocation could be
> perl Build.PL --config optimize="$(dpkg-buildflags --get CFLAGS) $(dpkg-buildflags --get CPPFLAGS)" \
> --config ld="$(perl -V::ld:) $(dpkg-buildflags --get LDFLAGS)"
>
> > The summary of my test run is:
> >
> > - 13 packages newly FTBFS with the perl from experimental installed
> > - of those, 12 are -Werror=format-security issues
>
> > It would be nice to fix all the packages first, but it's probably not
> > a sensible approach.
>
> Those numbers are lower than I expected, and the format-security fixes
> are generally trivial: change croak(var) to croak("%s", var) AIUI. So
> it might be sensible anyway. Somebody (TM) should file bugs about those
> in any case.
Agreed. Moritz, do you have any views on how/if to report those, and
at which severity?
> Somewhat surprisingly, I don't see the compile error with
> libparams-validate-perl on amd64 although I do on i386. I wonder why;
> there's no difference in the preprocessor output.
>
> > The test build logs are up at
> > <http://people.debian.org/~dom/perl/test/hardening-logs/>
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Reply to: