Bug#657853: Building perl with hardened build flags
On Wed, Mar 14, 2012 at 11:04:16PM +, Dominic Hargreaves wrote: On Wed, Feb 22, 2012 at 06:16:16PM +0100, Moritz Muehlenhoff wrote: If it's only 30 packages we should rather push it into debhelper 9 now if that's okay with Joey. I'll make sure the 30 packages get rebuilt. I believe that debhelper 9.20120312 implements what we need. Niko pointed out a reliable way of finding the packages which need to be rebuilt at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662666#40. I guess we need an email to the buildd maintainers asking them to update debhelper, and then you can kick off the binNMUs and I can upload the few packages I have queued to bump to compat level 9. Hi Moritz, Just wanted to check - are you happy to prod the buildd maintainers into making sure that debhelper = 9.20120312 is installed, or should I? I'd like to make sure that the changes I've got queued up don't get forgotten about. (Is there even a way to get interrogate the buildds to get the current set of installed packages, or a policy about how often they should update from unstable?) Thanks, 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
Bug#657853: Building perl with hardened build flags
On Mon, 26 Mar 2012 18:46:54 +0100, Dominic Hargreaves wrote: Just wanted to check - are you happy to prod the buildd maintainers into making sure that debhelper = 9.20120312 is installed, or should I? I'd like to make sure that the changes I've got queued up don't get forgotten about. (Is there even a way to get interrogate the buildds to get the current set of installed packages, or a policy about how often they should update from unstable?) There's an un(der)documented wann-build command for that, similar to dw but slightly different, and I neither remember nor find it now. (We used that for binNMUs of some xs-packages that needed a specific perl version.) Ha, here it is: extra-depends! Sources: http://article.gmane.org/gmane.linux.debian.devel.bugs.general/843972 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632467#20 Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Tanita Tikaram: Twist In My Sobriety [Tikaramp signature.asc Description: Digital signature
Bug#657853: Building perl with hardened build flags
Hi Dominic On Wed, Mar 14, 2012 at 11:06:45PM +, Dominic Hargreaves wrote: libdbd-pg-perl To be rebuilt by Moritz Maybe for this one, we could first wait one further day, to have the 2.19.0 upload in wheezy? It contains the fix for CVE-2012-1151. To all involved, many thanks for your work on this! Regrads, Salvatore signature.asc Description: Digital signature
Bug#657853: Building perl with hardened build flags
On Wed, Feb 22, 2012 at 06:16:16PM +0100, Moritz Muehlenhoff wrote: If it's only 30 packages we should rather push it into debhelper 9 now if that's okay with Joey. I'll make sure the 30 packages get rebuilt. I believe that debhelper 9.20120312 implements what we need. Niko pointed out a reliable way of finding the packages which need to be rebuilt at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662666#40. I guess we need an email to the buildd maintainers asking them to update debhelper, and then you can kick off the binNMUs and I can upload the few packages I have queued to bump to compat level 9. Cheers, 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
Bug#657853: Building perl with hardened build flags
On Sun, Feb 12, 2012 at 09:28:48PM +0100, Moritz Mühlenhoff wrote: These four Perl modules had a DSA since 2006 and are not pure Perl: So, once the fixed debhelper is installed on buildds: libhtml-parser-perl Ready for upload libdbd-pg-perl To be rebuilt by Moritz libimager-perl Ready for upload libnet-dns-perl Not a pkg-perl package; ready to file a bug -- 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 21, 2012 at 01:38:07PM +0200, Niko Tyni wrote: Problems/thoughts: Most of this got addressed with the implementation that landed in 5.14.2-9, so I think we're fine now. Concluding notes: - we're invoking dpkg-buildflags in two places (debian/rules and debian/config.debian), and if the invocations go out of sync we get a silent failure. Solved adequately enough. - not sure if we should blindly remove the dpkg-buildflags output from every line in Config_heavy.pm or just the ones we care about (i.e. ccflags, ld(dl?)flags) I think just /^(cc|cpp)flags/ and /^ld(dl)?flags/ is OK. In particular, I think it's good to keep it in config_args so we aren't lying about the configuration. - should we be defensive against a situation where dpkg-buildflags returns something short and generic (like or -g)? Solved. - I'd love to delegate the -Doptimize handling to dpkg-buildflags instead of doing it manually, but that way we end up stripping the default optimize flags from Perl modules in the same way as the hardening flags, which is probably not good. As long as we support building on systems without dpkg-buildflags, which I think we should for now, this isn't going to happen. -- Niko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Thu, Feb 23, 2012 at 10:24:50PM +, Dominic Hargreaves wrote: On Thu, Feb 23, 2012 at 11:49:31AM +0200, Niko Tyni wrote: I've pushed a slightly refined version of the patch. I'll file such a wishlist bug if/when this ends up in sid. Thanks. I'm inclined to release the current package to sid this weekend. Reviewing the package, I noticed that -fstack-protector disappears from ccflags with the current patch (compared against -7): -cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', +cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', I assume this is because the option is given twice to Configure, which then purges one of them as a duplicate, and we later substitute the other away. As this affects all XS module packages not using dpkg-buildflags, I don't think it's acceptable for sid. I've put a note on debian/changelog and held off uploading for the time being. Will try to come up with something better. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Sun, Feb 12, 2012 at 09:27:24PM +0100, Moritz Mühlenhoff wrote: If the missing format string is variable and controlled externally (e.g. if read from a file or from network communication), please file it with RC severity and the security tag. (If it's a popular Perl module, please contact t...@security.debian.org, so that we can coordinate with other distros.) Otherwise it's rather normal severity. I didn't feel qualified to make judgements about the exploitablity, but I thought it would be worth an initial filing in any case (I made this clear in the text of my reports). You can see them at http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=hardening;users=debian...@lists.debian.org Cheers, 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 21, 2012 at 10:21:04PM +, Dominic Hargreaves wrote: I'm in much the same situation as well; fairly limited hack time at the moment. So, not that this probably helps much, but: in order to make some progress with this, you could commit your patch as-is, and also open a wishlist bug recording the desired cleanups above. Makes sense. I've pushed a slightly refined version of the patch. I'll file such a wishlist bug if/when this ends up in sid. -- Niko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Thu, Feb 23, 2012 at 11:49:31AM +0200, Niko Tyni wrote: On Tue, Feb 21, 2012 at 10:21:04PM +, Dominic Hargreaves wrote: I'm in much the same situation as well; fairly limited hack time at the moment. So, not that this probably helps much, but: in order to make some progress with this, you could commit your patch as-is, and also open a wishlist bug recording the desired cleanups above. Makes sense. I've pushed a slightly refined version of the patch. I'll file such a wishlist bug if/when this ends up in sid. Thanks. I'm inclined to release the current package to sid this weekend. -- 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 21, 2012 at 10:37:48PM +, Dominic Hargreaves wrote: 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). If it's only 30 packages we should rather push it into debhelper 9 now if that's okay with Joey. I'll make sure the 30 packages get rebuilt. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Fri, Feb 17, 2012 at 12:36:21PM +0200, Niko Tyni wrote: (cc's trimmed for the implementation details) If we have consensus on that, the way forward as I see it: Dominic, I'm not sure if you're fine with that plan? - prepare a perl upload in unstable that is built with the hardened flags but doesn't export them through Config.pm Here's my first try at this. It works, but I'm not really happy with it. My hack time is fairly limited ATM and I haven't got any further just by glaring at it, so it's probably better to share this anyway. Problems/thoughts: - we're invoking dpkg-buildflags in two places (debian/rules and debian/config.debian), and if the invocations go out of sync we get a silent failure. - not sure if we should blindly remove the dpkg-buildflags output from every line in Config_heavy.pm or just the ones we care about (i.e. ccflags, ld(dl?)flags) - should we be defensive against a situation where dpkg-buildflags returns something short and generic (like or -g)? If we should, the blindly part above becomes much less attractive - I'd love to delegate the -Doptimize handling to dpkg-buildflags instead of doing it manually, but that way we end up stripping the default optimize flags from Perl modules in the same way as the hardening flags, which is probably not good. Ideas/patches welcome. -- Niko From c00d69add54d6da1765927462ef924cc5e608089 Mon Sep 17 00:00:00 2001 From: Niko Tyni nt...@debian.org Date: Fri, 17 Feb 2012 23:24:50 +0200 Subject: [PATCH] Massage Config_heavy.pm after the build to remove dpkg-buildflags effects We don't want to force ccflags and lddlflags on all packages at this stage. --- debian/changelog |3 +++ debian/rules | 10 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/debian/changelog b/debian/changelog index 6b155b2..c0b62da 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,6 +8,9 @@ perl (5.14.2-9) UNRELEASED; urgency=low [ Niko Tyni ] * No longer disable the 'pie' build flags: the implementation was overwriting DEB_BUILD_MAINT_OPTIONS altogether. + * Massage Config_heavy.pm after the build to remove dpkg-buildflags +effects on ccflags and lddlflags; we don't want to force them on +all packages at this stage. -- Dominic Hargreaves d...@earth.li Tue, 14 Feb 2012 19:38:31 + diff --git a/debian/rules b/debian/rules index 2c5075e..69ef967 100755 --- a/debian/rules +++ b/debian/rules @@ -132,6 +132,16 @@ install-stamp: build-stamp -e 's/^(man3ext=).*/$$1'\''3pm'\''/;' \ $(lib)/Config.pm $(lib)/Config_heavy.pl + # remove dpkg-buildflags effects from %Config + # see #657853 + if which dpkg-buildflags /dev/null 21; then \ + ccflags=$(shell dpkg-buildflags --get CPPFLAGS) $(shell dpkg-buildflags --get CFLAGS); \ + ldflags=$(shell dpkg-buildflags --get LDFLAGS); \ + ./perl.static -i -pe /^ccflags/ and s/\Q$$ccflags//;\ + /^ld(dl)?flags/ and s/\Q$$ldflags// \ + $(lib)/Config.pm $(lib)/Config_heavy.pl; \ + fi + # convert required header files -cd /usr/include; $(srcdir)/perl.static -I $(srcdir)/lib \ $(srcdir)/utils/h2ph -a -d $(srcdir)/$(lib) \
Bug#657853: Building perl with hardened build flags
On Tue, Feb 21, 2012 at 01:38:07PM +0200, Niko Tyni wrote: On Fri, Feb 17, 2012 at 12:36:21PM +0200, Niko Tyni wrote: (cc's trimmed for the implementation details) If we have consensus on that, the way forward as I see it: Dominic, I'm not sure if you're fine with that plan? Yes. Sorry I've lagged behind on this conversation recently. - prepare a perl upload in unstable that is built with the hardened flags but doesn't export them through Config.pm Here's my first try at this. It works, but I'm not really happy with it. My hack time is fairly limited ATM and I haven't got any further just by glaring at it, so it's probably better to share this anyway. Problems/thoughts: - we're invoking dpkg-buildflags in two places (debian/rules and debian/config.debian), and if the invocations go out of sync we get a silent failure. Wouldn't be too much work to abstract that if needed. - not sure if we should blindly remove the dpkg-buildflags output from every line in Config_heavy.pm or just the ones we care about (i.e. ccflags, ld(dl?)flags) No particular ideas about this one. - should we be defensive against a situation where dpkg-buildflags returns something short and generic (like or -g)? If we should, the blindly part above becomes much less attractive Mmm. - I'd love to delegate the -Doptimize handling to dpkg-buildflags instead of doing it manually, but that way we end up stripping the default optimize flags from Perl modules in the same way as the hardening flags, which is probably not good. Ideas/patches welcome. I'm in much the same situation as well; fairly limited hack time at the moment. So, not that this probably helps much, but: in order to make some progress with this, you could commit your patch as-is, and also open a wishlist bug recording the desired cleanups above. 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
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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Tue, 21 Feb 2012 22:37:48 +, Dominic Hargreaves wrote: 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). [..] 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. Sure, as soon as the dust settles, I (and probably others in the team) will happily help. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nick Cave And The Bad Seeds: Hiding All Away signature.asc Description: Digital signature
Bug#657853: Building perl with hardened build flags
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 - preferably fix #660195 (recursive Makefile.PL arguments) while at it - 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 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? I don't have much time to work on this myself, help welcome. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
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. -- see shy jo signature.asc Description: Digital signature
Bug#657853: Building perl with hardened build flags
[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 +, 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 +, 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.
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.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
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 +, 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 +, 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
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 +, 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 +, 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Sat, Feb 11, 2012 at 01:51:19PM +, Dominic Hargreaves wrote: - 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? If the missing format string is variable and controlled externally (e.g. if read from a file or from network communication), please file it with RC severity and the security tag. (If it's a popular Perl module, please contact t...@security.debian.org, so that we can coordinate with other distros.) Otherwise it's rather normal severity. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Sun, Feb 12, 2012 at 06:52:18PM +, Dominic Hargreaves 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. 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. These four Perl modules had a DSA since 2006 and are not pure Perl: libhtml-parser-perl libdbd-pg-perl libimager-perl libnet-dns-perl Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
Moritz Mühlenhoff 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? Well, how many perl packages that this could affect use v9 already? -- see shy jo signature.asc Description: Digital signature
Bug#657853: Building perl with hardened build flags
On Sun, 12 Feb 2012 17:12:31 -0400, Joey Hess 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? Well, how many perl packages that this could affect use v9 already? 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 Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #362: Plasma conduit breach signature.asc Description: Digital signature
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 +, 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
Bug#657853: Building perl with hardened build flags
On Thu, Feb 09, 2012 at 08:44:25PM +, 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
On Wed, Feb 08, 2012 at 09:46:22AM +0200, Niko Tyni wrote:
On Tue, Feb 07, 2012 at 10:13:58PM +, Dominic Hargreaves wrote:
On Tue, Feb 07, 2012 at 08:48:12PM +, Dominic Hargreaves wrote:
I've just kicked off a test rebuild of all CPAN
modules in Debian with the perl from experimental, to try and catch any
severe breakage introduced by this.
Early indications from my rebuilds indicate that we will have some
new FTBFS bugs with
-Wformat-security -Werror=format-security
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?)? Presumably we'd need to fix
ExtUtils::MakeMaker too.
It would be nice to fix all the packages first, but it's probably not
a sensible approach.
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
- 1 (libsystem-command-perl) is a test failure I haven't diagnosed,
which is also found at [1] and [2] (at least) where hardening flags
aren't to be found.
The test build logs are up at
http://people.debian.org/~dom/perl/test/hardening-logs/
[1]
http://www.cpantesters.org/cpan/report/8df074dc-5142-11e1-a48f-e7fb434ae6f1
[2]
http://www.cpantesters.org/cpan/report/29dae392-4058-11e1-9d6f-f6dbfa7543f5
--
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
Bug#657853: Building perl with hardened build flags
On Wed, Feb 08, 2012 at 06:58:53PM +0100, Moritz Mühlenhoff wrote: On Tue, Feb 07, 2012 at 10:13:58PM +, Dominic Hargreaves wrote: Moritz, could you comment on your preferred way of dealing with communicating/fixing this problem for packages which inherit build flags from perl? I'll post a complete list of affected packages to debian-perl once the rebuilds are complete. I've been working on a hardening/dpkg-buildflags walkthrough document, which is 80% ready. I'll add it to wiki.debian.org once ready and send a mail to d-d-a pointing to it. I'll add the necessary steps for perl Modules there. Okay - I'd be happy to check the perl bits over before it goes out. Cheers, 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 07, 2012 at 10:13:58PM +, Dominic Hargreaves wrote: Moritz, could you comment on your preferred way of dealing with communicating/fixing this problem for packages which inherit build flags from perl? I'll post a complete list of affected packages to debian-perl once the rebuilds are complete. I've been working on a hardening/dpkg-buildflags walkthrough document, which is 80% ready. I'll add it to wiki.debian.org once ready and send a mail to d-d-a pointing to it. I'll add the necessary steps for perl Modules there. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657853: Building perl with hardened build flags
Hello, As discussed in http://bugs.debian.org/657853/ we are adding various hardening build flags to the perl build in Debian, as part of a Debian release goal[1]. The version currently in Debian experimental has the following additional flags defined: ccflags: add -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security (note: -fstack-protector is added by perl's config already, but is also in the standard set of flags defined by the Debian dpkg-buildflags utility; -g -O2 is also not new, at least for the non-debugging build). ldflags: -Wl,-z,relro Notes on what the flags do are availble at [2]. These flags will also be enabled on XS modules built on Debian once this goes into unstable. I've just kicked off a test rebuild of all CPAN modules in Debian with the perl from experimental, to try and catch any severe breakage introduced by this. My question: does anyone know of any problems with using these flags with perl? Thanks, Dominic. [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags [2] http://wiki.debian.org/Hardening -- 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 07, 2012 at 08:48:12PM +, Dominic Hargreaves wrote: I've just kicked off a test rebuild of all CPAN modules in Debian with the perl from experimental, to try and catch any severe breakage introduced by this. Early indications from my rebuilds indicate that we will have some new FTBFS bugs with -Wformat-security -Werror=format-security So far (for all lib*-perl, alphabetically, up to libc): libapache2-mod-perl2: cc -c -I/build/dom-libapache2-mod-perl2_2.0.5-5-i386-x1v_OO/libapache2-mod-perl2-2.0.5/src/modules/perl -I/build/dom-libapache2-mod-perl2_2.0.5-5-i386- x1v_OO/libapache2-mod-perl2-2.0.5/xs -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/us r/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -I/usr/include/apache2 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL -DMP_USE_GTOP -DMP_COMPAT_1X -Wall -DVERSION=\0.009000\ -DXS_VERSION=\0.009000\ -fPIC -I/usr/lib/perl/5.14/CORE -DMP_HAVE_APR_LIBS Pool.c In file included from Pool.xs:26:0: /build/dom-libapache2-mod-perl2_2.0.5-5-i386-x1v_OO/libapache2-mod-perl2-2.0.5/xs/APR/Pool/APR__Pool.h: In function 'mpxs_cleanup_run': /build/dom-libapache2-mod-perl2_2.0.5-5-i386-x1v_OO/libapache2-mod-perl2-2.0.5/xs/APR/Pool/APR__Pool.h:315:9: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors libberkeleydb-perl: cc -c -I/usr/local/BerkeleyDB/include -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wform at -Wformat-security -Werror=format-security -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64-DVERSION=\0 .49\ -DXS_VERSION=\0.49\ -fPIC -I/usr/lib/perl/5.14/CORE BerkeleyDB.c BerkeleyDB.xs: In function 'softCrash': BerkeleyDB.xs:948:5: error: format not a string literal and no format arguments [-Werror=format-security] BerkeleyDB.xs: In function 'XS_BerkeleyDB__Env__db_appinit': BerkeleyDB.xs:2697:7: warning: too many arguments for format [-Wformat-extra-args] BerkeleyDB.xs:2709:11: warning: too many arguments for format [-Wformat-extra-args] BerkeleyDB.c: In function 'XS_BerkeleyDB__Env_DB_ENV': BerkeleyDB.c:3194:13: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] BerkeleyDB.xs: In function 'XS_BerkeleyDB__Unknown__db_open_unknown': BerkeleyDB.xs:3630:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cc1: some warnings being treated as errors Moritz, could you comment on your preferred way of dealing with communicating/fixing this problem for packages which inherit build flags from perl? I'll post a complete list of affected packages to debian-perl once the rebuilds are complete. Thanks, 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
Bug#657853: Building perl with hardened build flags
On Tue, Feb 07, 2012 at 10:13:58PM +, Dominic Hargreaves wrote:
On Tue, Feb 07, 2012 at 08:48:12PM +, Dominic Hargreaves wrote:
I've just kicked off a test rebuild of all CPAN
modules in Debian with the perl from experimental, to try and catch any
severe breakage introduced by this.
Early indications from my rebuilds indicate that we will have some
new FTBFS bugs with
-Wformat-security -Werror=format-security
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.
No idea how to do that yet :)
--
Niko
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
