Bug#657853: Building perl with hardened build flags

[Niko Tyni]

On Thu, Feb 09, 2012 at 08:44:25PM +0000, Dominic Hargreaves wrote:
> On Wed, Feb 08, 2012 at 09:46:22AM +0200, Niko Tyni wrote:

> > I suspect we need to patch ExtUtils::CBuilder to invoke dpkg-buildflags
> > at XS module build time rather than blindly use $Config{ccflags} from
> > perl. That way XS module packages can disable some hardening flags if
> > necessary.
> 
> Hrm, I guess. Or add a more generic function to allow the stripping out
> of build flags (NOCCFLAGS?)?

I see I was rather confused there. Sorry.

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)

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.

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.

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.

> 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.)

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.

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/>

Thanks for your work once again!
-- 
Niko