Debian Bug report logs - #552688
Please decide how Debian should enable hardening build flags

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Kees Cook <kees@debian.org>

Date: Wed, 28 Oct 2009 18:09:03 UTC

Severity: wishlist

Done: Russ Allbery <rra@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian GCC Maintainers <debian-gcc@lists.debian.org>:
Bug#552688; Package gcc-4.4. (Wed, 28 Oct 2009 18:09:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
New Bug report received and forwarded. Copy sent to Debian GCC Maintainers <debian-gcc@lists.debian.org>. (Wed, 28 Oct 2009 18:09:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Debian Bugs <submit@bugs.debian.org>
Subject: enable hardening defaults
Date: Tue, 27 Oct 2009 14:24:41 -0700
[Message part 1 (text/plain, inline)]
Package: gcc-4.4
Version: 4.4.2-1
Severity: wishlist
Tags: patch

Hello!

Based on the ubuntu-devel discussions[1], there are no objections yet
from other developers about enabling the hardened compiler defaults in
Debian.

Thanks,

-Kees

[1] http://lists.debian.org/debian-gcc/2009/10/msg00186.html

-- 
Kees Cook                                            @debian.org
[hardening-for-all.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC Maintainers <debian-gcc@lists.debian.org>:
Bug#552688; Package gcc-4.4. (Sun, 01 Nov 2009 14:18:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GCC Maintainers <debian-gcc@lists.debian.org>. (Sun, 01 Nov 2009 14:18:07 GMT) Full text and rfc822 format available.

Message #10 received at 552688@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Kees Cook <kees@debian.org>, 552688@bugs.debian.org
Cc: Debian Bug Tracking System <control@bugs.debian.org>
Subject: Re: Bug#552688: enable hardening defaults
Date: Sun, 01 Nov 2009 15:06:57 +0100
tags 552688 - patch
tags 552688 + wontfix
thanks

Please get the patches accepted upstream, then remove the won't fix tag again. 
Make sure that GCC builds for all languages without configuring with 
--disable-werror.  I don't have the resources to maintain that patch in Debian, 
and in Ubuntu it did take more than twelve months to even get the testsuite fixes.

On 27.10.2009 22:24, Kees Cook wrote:
> Package: gcc-4.4
> Version: 4.4.2-1
> Severity: wishlist
> Tags: patch
>
> Hello!
>
> Based on the ubuntu-devel discussions[1], there are no objections yet
> from other developers about enabling the hardened compiler defaults in
> Debian.
>
> Thanks,
>
> -Kees
>
> [1] http://lists.debian.org/debian-gcc/2009/10/msg00186.html
>





Removed tag(s) patch. Request was from Matthias Klose <doko@debian.org> to control@bugs.debian.org. (Sun, 01 Nov 2009 14:18:09 GMT) Full text and rfc822 format available.

Added tag(s) wontfix. Request was from Matthias Klose <doko@debian.org> to control@bugs.debian.org. (Sun, 01 Nov 2009 14:18:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC Maintainers <debian-gcc@lists.debian.org>:
Bug#552688; Package gcc-4.4. (Wed, 06 Oct 2010 16:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to dave b <db.pub.mail@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian GCC Maintainers <debian-gcc@lists.debian.org>. (Wed, 06 Oct 2010 16:45:06 GMT) Full text and rfc822 format available.

Message #19 received at 552688@bugs.debian.org (full text, mbox):

From: dave b <db.pub.mail@gmail.com>
To: 552688@bugs.debian.org
Subject: This seems a bit stupid
Date: Thu, 7 Oct 2010 03:43:49 +1100
IMHO this is a bit silly you are denying users of debian security
features found elsewhere (at least found elsewhere in their
packages...). The point is to make the compiler hardened by default
not only packages compiled and packaged for debian.

Please see http://wiki.debian.org/Hardening and please do reconsider.
Given the (actual)patches are already in the source package for 4.4
and 4.5 (gcc) I don't see what your complaint is ?
Why carry something you won't maintain ... this doesn't make sense to me.

--
Things past redress and now with me past care.		-- William
Shakespeare, "Richard II"




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GCC Maintainers <debian-gcc@lists.debian.org>:
Bug#552688; Package gcc-4.4. (Sun, 17 Oct 2010 12:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GCC Maintainers <debian-gcc@lists.debian.org>. (Sun, 17 Oct 2010 12:33:06 GMT) Full text and rfc822 format available.

Message #24 received at 552688@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: dave b <db.pub.mail@gmail.com>, 552688@bugs.debian.org, Debian Bug Tracking System <control@bugs.debian.org>
Subject: Re: Bug#552688: This seems a bit stupid
Date: Sun, 17 Oct 2010 14:31:59 +0200
reassign 552688 dpkg-dev
thanks

[reassigning to dpkg-dev, if there is no consensus to enable these,
 the bug should be reassigned to general]

On 06.10.2010 18:43, dave b wrote:
> IMHO this is a bit silly you are denying users of debian security
> features found elsewhere (at least found elsewhere in their
> packages...). The point is to make the compiler hardened by default
> not only packages compiled and packaged for debian.

the point of injection is wrong.  dpkg-buildflags supports setting defaults for 
compiler and linker flags.  If some flags are missing, add them. If packages are 
not honouring these flags, fix them.

  Matthias




Bug reassigned from package 'gcc-4.4' to 'dpkg-dev'. Request was from Matthias Klose <doko@debian.org> to control@bugs.debian.org. (Sun, 17 Oct 2010 12:33:07 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions gcc-4.4/4.4.2-1. Request was from Matthias Klose <doko@debian.org> to control@bugs.debian.org. (Sun, 17 Oct 2010 12:33:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#552688; Package dpkg-dev. (Mon, 18 Oct 2010 02:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to dave b <db.pub.mail@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 18 Oct 2010 02:21:03 GMT) Full text and rfc822 format available.

Message #33 received at 552688@bugs.debian.org (full text, mbox):

From: dave b <db.pub.mail@gmail.com>
To: 552688@bugs.debian.org
Subject: actually this is a compiler level bug or feature request
Date: Mon, 18 Oct 2010 13:16:19 +1100
actually this is a compiler level bug or feature request.
Story: I want to compiler packages hardened

As a User of debian
I want *anything* I compile (and packaged I install) to be compiled
with hardening options.
So that I will have some protection against security flaws.

THIS IS NOT A DPKG BUG.

--
Having nothing, nothing can he lose.		-- William Shakespeare, "Henry VI"




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#552688; Package dpkg-dev. (Mon, 18 Oct 2010 04:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alex Sharp <alex.sharp@orionvm.com.au>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 18 Oct 2010 04:24:03 GMT) Full text and rfc822 format available.

Message #38 received at 552688@bugs.debian.org (full text, mbox):

From: Alex Sharp <alex.sharp@orionvm.com.au>
To: 552688@bugs.debian.org
Subject: GCC hardening
Date: Mon, 18 Oct 2010 15:19:57 +1100
[Message part 1 (text/plain, inline)]
I could really use GCC hardening, it would make my life significantly
easier, so please enable it.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#552688; Package dpkg-dev. (Sat, 20 Nov 2010 15:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 20 Nov 2010 15:21:06 GMT) Full text and rfc822 format available.

Message #43 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 552688@bugs.debian.org
Cc: gcc@packages.debian.org, debian-ctte@lists.debian.org, "Kees Cook <kees@debian.org>"@soleymieux.ouaza.com
Subject: Please decide how Debian should enable hardening build flags
Date: Sat, 20 Nov 2010 16:18:29 +0100
reassign 552688 tech-ctte
retitle 552688 Please decide how Debian should enable hardening build flags
tag 552688 - wontfix
thanks

I think none of the discussions up to now have resulted in a consensus
among all the parties. Most people are in favor of changing the defaults
in GCC, except the gcc maintainer.

We have dpkg-buildflags available but few packages are using it and it's
unlikely they will be all converted in the wheezy timeframe. (And everytime I
discuss how packages should communicate to dpkg-buildflags whether or not
they want/support hardening build flags (and which one in particular), the
discussion stalls).

I would really like Debian to build hardened binaries by default and it
would be great if the switch could happen early in the wheezy cycle. For
this I think we need to have a clear plan and I hope the technical
committee can bring some clarity here. Either by overruling the GCC
maintainer or by designing the missing pieces so that we can at least go
forward (I would implement what's needed in dpkg-dev if I knew what's
needed).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Bug reassigned from package 'dpkg-dev' to 'tech-ctte'. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 20 Nov 2010 15:21:09 GMT) Full text and rfc822 format available.

Changed Bug title to 'Please decide how Debian should enable hardening build flags' from 'enable hardening defaults' Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 20 Nov 2010 15:21:10 GMT) Full text and rfc822 format available.

Removed tag(s) wontfix. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 20 Nov 2010 15:21:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sat, 20 Nov 2010 15:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 20 Nov 2010 15:48:03 GMT) Full text and rfc822 format available.

Message #54 received at 552688@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sat, 20 Nov 2010 09:45:37 -0600
Hi,

Raphael Hertzog wrote:

> We have dpkg-buildflags available but few packages are using it and it's
> unlikely they will be all converted in the wheezy timeframe.

I agree with the precise meaning of this statement, but the spirit seems
quite wrong.  For the packages I am involved in (not many), I have
deliberately not used dpkg-buildflags to make backporting easier.
It is a new facility but a very good one, and I suspect that it will
be adopted fairly quickly, especially if someone writes the appropriate
patches to debian/rules (or even better, writes a program maintainers
can use to automate this).

Also, I am not the GCC maintainer, but from experience of receiving
reports from people building software with Ubuntu, I think changing
the defaults in GCC is quite wrong.

Just my two cents.
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sat, 20 Nov 2010 15:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to dave b <db.pub.mail@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 20 Nov 2010 15:54:03 GMT) Full text and rfc822 format available.

Message #59 received at 552688@bugs.debian.org (full text, mbox):

From: dave b <db.pub.mail@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>, 552688@bugs.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 02:50:23 +1100
On 21 November 2010 02:45, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Raphael Hertzog wrote:
>
>> We have dpkg-buildflags available but few packages are using it and it's
>> unlikely they will be all converted in the wheezy timeframe.
>
> I agree with the precise meaning of this statement, but the spirit seems
> quite wrong.  For the packages I am involved in (not many), I have
> deliberately not used dpkg-buildflags to make backporting easier.
> It is a new facility but a very good one, and I suspect that it will
> be adopted fairly quickly, especially if someone writes the appropriate
> patches to debian/rules (or even better, writes a program maintainers
> can use to automate this).
>
> Also, I am not the GCC maintainer, but from experience of receiving
> reports from people building software with Ubuntu, I think changing
> the defaults in GCC is quite wrong.

Why do you think this?




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sat, 20 Nov 2010 16:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 20 Nov 2010 16:12:03 GMT) Full text and rfc822 format available.

Message #64 received at 552688@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: dave b <db.pub.mail@gmail.com>
Cc: 552688@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sat, 20 Nov 2010 10:09:31 -0600
dave b wrote:
> On 21 November 2010 02:45, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Also, I am not the GCC maintainer, but from experience of receiving
>> reports from people building software with Ubuntu, I think changing
>> the defaults in GCC is quite wrong.
>
> Why do you think this?

Well, I should scale that back a little and say, an easy way for
individual users to turn on hardening build flags in GCC is very
welcome.

My comment is really about the default.  The main problem I had in
mind is that with -D_FORTIFY_SOURCE=2, if you are not specifically
coding with that in mind, there are spurious warnings like this:

	some-file.c:70: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result

Sometimes that may be a welcome warning, but often enough one knows
very well that errors are being ignored.  And

	(void) whatever_function(...

does not suppress this; you instead have to uglify your code like so:

	int unused = whatever_function(...

The consequences are worst when a person or project makes the
misguided choice of using -Werror on code he is not developing.
Then with a GCC update, the code starts to fail to build from source,
for confusing reasons like the above, without much of an upside to
the non-developer to offset that.

That said, the burden of handling fallout like this seems perfectly
acceptable for a project like Debian to take on.  It is not such a
cost for secure code.  That is why I would be happy to see hardening
flags added for the build of Debian packages, though not for the
default invocation of gcc.

Hoping that is clearer.
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 03:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 03:06:02 GMT) Full text and rfc822 format available.

Message #69 received at 552688@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 552688@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Sat, 20 Nov 2010 19:03:33 -0800
On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> I think none of the discussions up to now have resulted in a
> consensus among all the parties. Most people are in favor of
> changing the defaults in GCC, except the gcc maintainer.

There are a couple of things here that should be worked out first
before the CTTE can make a decision:

1) Has gcc's upstream been approached about including this patch? What
was their response?

2) Has the archive been successfully rebuilt with the proposed patch?

3) Since Matthias has indicated that he doesn't have the resources to
steward this patch in Debian, who is going to work on maintaining it
if upstream isn't interested in the patch and the CTTE decides to
override Matthias?

Alternatives to patching gcc include making dpkg-buildflags more
prevalent, a wrapper that we require to install on buildds (coupled
with throwing away binary builds), or some combination of the above.


Don Armstrong

-- 
I really wanted to talk to her.
I just couldn't find an algorithm that fit.
 -- Peter Watts _Blindsight_ p294

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 07:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 07:42:03 GMT) Full text and rfc822 format available.

Message #74 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Don Armstrong <don@debian.org>
Cc: 552688@bugs.debian.org, gcc@packages.debian.org, kees@debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 08:39:21 +0100
CCing Kees Cook, he has been the one leading the efforts up to now. I hope
he can answer your queries. 

Hi,

On Sat, 20 Nov 2010, Don Armstrong wrote:
> There are a couple of things here that should be worked out first
> before the CTTE can make a decision:
> 
> 1) Has gcc's upstream been approached about including this patch? What
> was their response?

No idea.

> 2) Has the archive been successfully rebuilt with the proposed patch?

I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
Steve Langasek should be able to tell us a bit more.

> 3) Since Matthias has indicated that he doesn't have the resources to
> steward this patch in Debian, who is going to work on maintaining it
> if upstream isn't interested in the patch and the CTTE decides to
> override Matthias?

Kees, would you be willing to take this responsibility in that case?

> Alternatives to patching gcc include making dpkg-buildflags more
> prevalent, a wrapper that we require to install on buildds (coupled
> with throwing away binary builds), or some combination of the above.

Indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 08:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 08:24:03 GMT) Full text and rfc822 format available.

Message #79 received at 552688@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Don Armstrong <don@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org, kees@debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 09:21:43 +0100
On 21.11.2010 08:39, Raphael Hertzog wrote:
> CCing Kees Cook, he has been the one leading the efforts up to now. I hope
> he can answer your queries.
>
> Hi,
>
> On Sat, 20 Nov 2010, Don Armstrong wrote:
>> There are a couple of things here that should be worked out first
>> before the CTTE can make a decision:

I assume that there is a decision to turn on hardening defaults?  Who made it, 
and which defaults to turn on?  Which ports should it use?  Where is it 
documented?  So involvement of the ctte seems to be a bit premature, asking the 
*how* before the *if*.  As said before in the report, it should be reassigned to 
`general'.

>> 1) Has gcc's upstream been approached about including this patch? What
>> was their response?
>
> No idea.

Afaik, not submitted, and not upstreamable in this form.

>> 2) Has the archive been successfully rebuilt with the proposed patch?
>
> I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
> Steve Langasek should be able to tell us a bit more.
>
>> 3) Since Matthias has indicated that he doesn't have the resources to
>> steward this patch in Debian, who is going to work on maintaining it
>> if upstream isn't interested in the patch and the CTTE decides to
>> override Matthias?
>
> Kees, would you be willing to take this responsibility in that case?

The patch itself is "maintained", however it requires patches to the testsuite 
which are not maintained. They are in 4.4, partially forwarded, incomplete for 
4.5 and not done at all for trunk.  So I do have an answer about the 
responsibility (and no, you won't convince me otherwise in a few weeks or months 
having seen this for years).

An additional effort is testing with upstream builds for submitting bug reports. 
 I didn't see anybody to step up with this testing, when the toolchain diverges 
much more, compared to upstream.

>> Alternatives to patching gcc include making dpkg-buildflags more
>> prevalent, a wrapper that we require to install on buildds (coupled
>> with throwing away binary builds), or some combination of the above.

yes, I consider the current solution a hack, introduced in some derivates by the 
lack of resources to get it done properly as nearly any other distribution is 
doing it.  Changes to the build flags should be injected in the package build 
system, not by changing the compiler itself.  I first submitted a patch to 
introduce default flags from the environment, this was replaced/refined by 
dpkg-buildflags.  Now please work on getting it honored in the package builds 
and maybe make it a policy for packages with a certain priority.

  Matthias




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 08:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 08:42:03 GMT) Full text and rfc822 format available.

Message #84 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: Don Armstrong <don@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org, kees@debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 09:39:41 +0100
Hi,

On Sun, 21 Nov 2010, Matthias Klose wrote:
> I assume that there is a decision to turn on hardening defaults?
> Who made it, and which defaults to turn on?  Which ports should it
> use?  Where is it documented?  So involvement of the ctte seems to
> be a bit premature, asking the *how* before the *if*.  As said
> before in the report, it should be reassigned to `general'.

Any past discussion that I remember, a vast majority of people were in
favor of hardening and discussions stalled on the implementation details.
I don't think that reassigning it to general will help in any way.

> An additional effort is testing with upstream builds for submitting
> bug reports.  I didn't see anybody to step up with this testing,
> when the toolchain diverges much more, compared to upstream.

I don't understand what you are referring to here. Can you elaborate a
bit?

> yes, I consider the current solution a hack, introduced in some
> derivates by the lack of resources to get it done properly as nearly
> any other distribution is doing it.  Changes to the build flags
> should be injected in the package build system, not by changing the
> compiler itself.  I first submitted a patch to introduce default
> flags from the environment, this was replaced/refined by
> dpkg-buildflags.  Now please work on getting it honored in the
> package builds and maybe make it a policy for packages with a
> certain priority.

I think the proper solution is a combination of both approaches. There's
no reason we should continue to not have hardened builds for all packages
right now (in particular when everybody else have them).

Packages should be able to opt-in/opt-out by using dpkg-buildflags
properly. The flags returned by dpkg-buildflags could include some sort of
"--no-magical-defaults-behind-my-back" so that dpkg-buildflags is then
entirely in control, and it can even disable hardening build for the
packages where it breaks.

The day when all packages are using dpkg-buildflags properly, then we can
drop that patch in gcc.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 09:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to dave b <db.pub.mail@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 09:24:03 GMT) Full text and rfc822 format available.

Message #89 received at 552688@bugs.debian.org (full text, mbox):

From: dave b <db.pub.mail@gmail.com>
To: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 20:21:16 +1100
Hi I am just going to say that as a debian user, I would think that
compiling with hardening (features on by default) would be a good
thing.
It means that custom compiled applications (non-debian origin) will be
compiled with gcc hardening.

Is this really a bad thing?




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 13:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 13:03:03 GMT) Full text and rfc822 format available.

Message #94 received at 552688@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: dave b <db.pub.mail@gmail.com>, 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 12:58:51 +0000
dave b writes ("Bug#552688: Please decide how Debian should enable hardening build flags"):
> Hi I am just going to say that as a debian user,

Thanks for your contribution, but please, this list and bug is for
technical discussion and not for users' expressions of interest.

We don't need to be convinced that improving security is a good thing
so please don't send us messages like this one.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 14:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to dave b <db.pub.mail@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 14:54:03 GMT) Full text and rfc822 format available.

Message #99 received at 552688@bugs.debian.org (full text, mbox):

From: dave b <db.pub.mail@gmail.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Mon, 22 Nov 2010 01:49:41 +1100
Sir, I think you should be more polite:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5726

I was simply voicing what I thought as a user of debian.
I know this bug report is *technical*. I was making a *technical* comment.

Also, note I did not reply to the list did I ?




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 19:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 21 Nov 2010 19:36:03 GMT) Full text and rfc822 format available.

Message #104 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: dave b <db.pub.mail@gmail.com>, 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 20:34:18 +0100
Hi,

On Mon, 22 Nov 2010, dave b wrote:
> Sir, I think you should be more polite:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5726

Please don't dig old mails to justify your assertion. He was trying to be
polite (even if it was not obvious to you).

> I was simply voicing what I thought as a user of debian.
> I know this bug report is *technical*. I was making a *technical* comment.

Ian might not have understood you correctly.

Ian, Dave was saying that having the defaults in gcc was good since it
also protected custom binaries compiled by users and not only binaries in
official Debian packages.

It's certainly an aspect that the technical committee ought to consider in
the balance.

> Also, note I did not reply to the list did I ?

I reassigned the bug to the technical committee so any mail sent to the bug
is also sent to the list of the technical committee. That's why Ian saw
your mail.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 21 Nov 2010 20:48:03 GMT) Full text and rfc822 format available.

Message #107 received at 552688@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 552688@bugs.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org, kees@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 21 Nov 2010 12:45:02 -0800
On Sun, 21 Nov 2010, Matthias Klose wrote:
> On Sat, 20 Nov 2010, Don Armstrong wrote:
> >There are a couple of things here that should be worked out first
> >before the CTTE can make a decision:
> 
> I assume that there is a decision to turn on hardening defaults?

No one has decided anything. I'm asking questions to figure out if the
CTTE should decide something, or whether it needs to send the problem
back for detailed design work, or if there is a known blocker that we
just don't have available manpower to resolve.
 
> > 3) Since Matthias has indicated that he doesn't have the
> > resources to steward this patch in Debian, who is going to work
> > on maintaining it if upstream isn't interested in the patch and
> > the CTTE decides to override Matthias?
> 
> The patch itself is "maintained", however it requires patches to the
> testsuite which are not maintained. They are in 4.4, partially
> forwarded, incomplete for 4.5 and not done at all for trunk. So I do
> have an answer about the responsibility (and no, you won't convince
> me otherwise in a few weeks or months having seen this for years).

Your answer is that you don't want the responsibility of dealing with
the test suite changes; that's fine. This means that if we are going
to decide to include the hardening patch, someone needs to be stepping
up to fix the test suite and forward the patches. [Why is this not a
problem for Ubuntu, BTW?]


Don Armstrong

-- 
To steal ideas from one person is plagiarism; to steal from many is
research.
 -- Steven Wright

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 21 Jan 2011 19:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Jan 2011 19:57:03 GMT) Full text and rfc822 format available.

Message #112 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org, debian-ctte@lists.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 21 Jan 2011 11:55:06 -0800
On Sat, Nov 20, 2010 at 04:18:29PM +0100, Raphael Hertzog wrote:
> We have dpkg-buildflags available but few packages are using it and it's
> unlikely they will be all converted in the wheezy timeframe. (And everytime I
> discuss how packages should communicate to dpkg-buildflags whether or not
> they want/support hardening build flags (and which one in particular), the
> discussion stalls).

It would be easy to add hardening-includes a dep of dpkg-buildflags, and
have it pull in the defaults. (Though perhaps PIE should be turned off by
default in this case.)

> I would really like Debian to build hardened binaries by default and it
> would be great if the switch could happen early in the wheezy cycle. For
> this I think we need to have a clear plan and I hope the technical
> committee can bring some clarity here. Either by overruling the GCC
> maintainer or by designing the missing pieces so that we can at least go
> forward (I would implement what's needed in dpkg-dev if I knew what's
> needed).

I stand by my preference for this being done in the compiler defaults
itself. I've been maintaining in Ubuntu for years now, it's not very hard
to keep the patch up to date.

That said, I do recognize that it creates a delta from upstream gcc and
makes it harder to diagnose compiler bugs. I would like to have upstream
take a --configure build-time option for gcc for these defaults, but I
haven't made any headway on it.

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 21 Jan 2011 20:09:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Jan 2011 20:09:12 GMT) Full text and rfc822 format available.

Message #117 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Don Armstrong <don@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 21 Jan 2011 12:00:26 -0800
Hi Raphael,

On Sun, Nov 21, 2010 at 08:39:21AM +0100, Raphael Hertzog wrote:
> On Sat, 20 Nov 2010, Don Armstrong wrote:
> > There are a couple of things here that should be worked out first
> > before the CTTE can make a decision:
> > 
> > 1) Has gcc's upstream been approached about including this patch? What
> > was their response?
> 
> No idea.

Zorry from Gentoo was working on a --configure option. In general, upstream
gcc is against global behavioral changes like this. I can try to open some
discussion with them, though.

> > 2) Has the archive been successfully rebuilt with the proposed patch?
> 
> I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
> Steve Langasek should be able to tell us a bit more.

Yes, all of Ubuntu has been compiled with hardening enabled since Oct 2008.
As mentioned in the original thread[1], the only thing needed to turn it on
in Debian is to just not filter the patch list in Debian[2].

[1] http://lists.debian.org/debian-gcc/2009/10/msg00186.html
[2] http://outflux.net/hardening-for-all.patch

> > 3) Since Matthias has indicated that he doesn't have the resources to
> > steward this patch in Debian, who is going to work on maintaining it
> > if upstream isn't interested in the patch and the CTTE decides to
> > override Matthias?
> 
> Kees, would you be willing to take this responsibility in that case?

I already am maintaining this patchset (since it is used in Ubuntu, and the
package is shared between Debian and Ubuntu). The core of Matthias's
objection to using it in Debian is that it it leaves him with no "stock"
gcc to diagnose compiler bugs with. While "gcc-snapshot" exists, there is
nothing like "gcc-4.5-stock", though perhaps that might be a solution to
that objection, though that would add yet-another-package-of-gcc.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 21 Jan 2011 20:09:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Jan 2011 20:09:14 GMT) Full text and rfc822 format available.

Message #122 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: Raphael Hertzog <hertzog@debian.org>, Don Armstrong <don@debian.org>, 552688@bugs.debian.org, gcc@packages.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 21 Jan 2011 12:07:25 -0800
[Message part 1 (text/plain, inline)]
Hi Matthias,

On Sun, Nov 21, 2010 at 09:21:43AM +0100, Matthias Klose wrote:
> I assume that there is a decision to turn on hardening defaults?
> Who made it, and which defaults to turn on?  Which ports should it
> use?  Where is it documented?  So involvement of the ctte seems to

The hardening-wrapper package has all of the combinations and ports
well-declared. For example:

ifneq (,$(filter $(DEB_HOST_ARCH_CPU), ia64 alpha mips mipsel hppa arm ))
  # Stack protector disabled on ia64, alpha, mips, mipsel, hppa.
  #   "warning: -fstack-protector not supported for this target"
  # Stack protector disabled on arm (ok on armel).
  #   compiler supports it incorrectly (leads to SEGV)
  DEB_BUILD_HARDENING_STACKPROTECTOR ?= 0
endif
DEB_BUILD_HARDENING_STACKPROTECTOR ?= 1

etc

> The patch itself is "maintained", however it requires patches to the
> testsuite which are not maintained. They are in 4.4, partially
> forwarded, incomplete for 4.5 and not done at all for trunk.  So I
> do have an answer about the responsibility (and no, you won't
> convince me otherwise in a few weeks or months having seen this for
> years).

Since this, I've gotten half the testsuite changes into upstream, so this
has improved. The testsuite work is extremely time-consuming, and I've been
very slow to get that work done, unfortunately.

> yes, I consider the current solution a hack, introduced in some
> derivates by the lack of resources to get it done properly as nearly
> any other distribution is doing it.  Changes to the build flags
> should be injected in the package build system, not by changing the
> compiler itself.  I first submitted a patch to introduce default
> flags from the environment, this was replaced/refined by
> dpkg-buildflags.  Now please work on getting it honored in the
> package builds and maybe make it a policy for packages with a
> certain priority.

This is likely the core of the disagreement: how to apply the
flags. I have a strong opinion about this because my perspective is
security-oriented. I think all compiles should be hardened; default
to being secure, and whitelist that which needs things disabled. Same
policy applies to firewalls, etc. As before, I stand by my original email
that started this thread:
http://lists.debian.org/debian-gcc/2009/10/msg00186.html

-Kees

-- 
Kees Cook                                            @debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 23 Jan 2011 21:42:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rico Secada <coolzone@it.dk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Jan 2011 21:42:07 GMT) Full text and rfc822 format available.

Message #127 received at 552688@bugs.debian.org (full text, mbox):

From: Rico Secada <coolzone@it.dk>
To: 552688@bugs.debian.org
Subject: For real!?
Date: Sun, 23 Jan 2011 22:27:45 +0100
> I don't have the resources to maintain that patch in Debian, 
> and in Ubuntu it did take more than twelve months to even get the
> testsuite fixes.

Matthias if you wont do the job right, just don't! You are not
maintaining something when you are not doing it right! 

Please step down and let someone else take over! Debian needs to be
secure by default!

Ubuntu has been running with hardening patches for more than about four
years now. Both Fedora and SUSE are also using different solutions to
provide a hardened by default system

Debian is a quality system and it is unacceptable that we are still not
using the hardening options by default.

> This is likely the core of the disagreement: how to apply the
> flags. I have a strong opinion about this because my perspective is
> security-oriented. I think all compiles should be hardened; default
> to being secure, and whitelist that which needs things disabled. Same
> policy applies to firewalls, etc. As before, I stand by my original
> email that started this thread:
> http://lists.debian.org/debian-gcc/2009/10/msg00186.html

You are quite right!

RS




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Mon, 24 Jan 2011 02:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 24 Jan 2011 02:12:03 GMT) Full text and rfc822 format available.

Message #132 received at 552688@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Rico Secada <coolzone@it.dk>, 552688@bugs.debian.org
Subject: Re: Bug#552688: For real!?
Date: Sun, 23 Jan 2011 18:08:28 -0800
On Sun, 23 Jan 2011, Rico Secada wrote:
> Matthias if you wont do the job right, just don't! You are not
> maintaining something when you are not doing it right!

This is unhelpful. The issue has been referred to the CTTE and we will
make a decision. Messages which do not contain information directly
bearing on the underlying technical problem need not be sent to the
bug log or the CTTE.


Don Armstrong

-- 
Guns Don't Kill People.
*I* Kill People.

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Mon, 24 Jan 2011 21:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 24 Jan 2011 21:30:07 GMT) Full text and rfc822 format available.

Message #137 received at 552688@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Kees Cook <kees@debian.org>, 552688@bugs.debian.org
Cc: Matthias Klose <doko@debian.org>, Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Mon, 24 Jan 2011 13:26:00 -0800
On Fri, 21 Jan 2011, Kees Cook wrote:
> This is likely the core of the disagreement: how to apply the flags.
> I have a strong opinion about this because my perspective is
> security-oriented. I think all compiles should be hardened; default
> to being secure, and whitelist that which needs things disabled.
> Same policy applies to firewalls, etc. As before, I stand by my
> original email that started this thread:
> http://lists.debian.org/debian-gcc/2009/10/msg00186.html

1) Can a complete patch to enable hardening by default include
specific documentation on how to disable it? [Can this "return to a
default compiler" be made simpler than switching the three or four
options currently used?]

2) The current state of the patch doesn't properly document that the
flag is on by default; if the patch is enabled, it should say so in
the documentation, not referencing a version of Ubuntu.

3) Who is willing to do a complete rebuild with the patch enabled and
handle filing any bugs (with appropriate patches, ideally) that turn
up? [On how many architectures?]

4) What solution would you enact if the CTTE were to have hardening be
on by default for all Debian packages, but disabled by default for the
compiler as shipped?

Matthias: if #3 were to be done, and some mechanism of either doing #4
or #1 were required, what additional objections (if any) would you
have?


Don Armstrong

-- 
Let me bring you up to speed:
We know nothing.
You are now up to speed.
  -- Steve Martin as Inspector Clouseau in _The Pink Panther 2_ (2009)

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Mon, 24 Jan 2011 23:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 24 Jan 2011 23:09:06 GMT) Full text and rfc822 format available.

Message #142 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Don Armstrong <don@debian.org>
Cc: 552688@bugs.debian.org, Matthias Klose <doko@debian.org>, Raphael Hertzog <hertzog@debian.org>, gcc@packages.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Mon, 24 Jan 2011 15:05:09 -0800
[Message part 1 (text/plain, inline)]
On Mon, Jan 24, 2011 at 01:26:00PM -0800, Don Armstrong wrote:
> On Fri, 21 Jan 2011, Kees Cook wrote:
> > This is likely the core of the disagreement: how to apply the flags.
> > I have a strong opinion about this because my perspective is
> > security-oriented. I think all compiles should be hardened; default
> > to being secure, and whitelist that which needs things disabled.
> > Same policy applies to firewalls, etc. As before, I stand by my
> > original email that started this thread:
> > http://lists.debian.org/debian-gcc/2009/10/msg00186.html
> 
> 1) Can a complete patch to enable hardening by default include
> specific documentation on how to disable it? [Can this "return to a
> default compiler" be made simpler than switching the three or four
> options currently used?]

Anything is possible, but nothing like this exists at the moment. While it
might be possible to invent some kind of --no-hardening option that would
disable the defaults, it would take a non-trivial amount of time to
implement, especially since the defaults must currently be implemented in 3
separate ways (spec updates, warning state defaults, and built-in defines).
If this fell to me, I would probably want to fold this into getting the
upstream configure option accepted, but that's still down on my priority
list.

There are effectively 4 sets of options in the compiler hardening patches:

    -Wformat -Wformat-security
    -D_FORTIFY_SOURCE=2
    -fstack-protector --param ssp-buffer-size=4
    -Wl,-z,relro

I should mention: PIE (-pie -fPIE) is _not_ included in the compiler
defaults patch. This is only done via the hardening-wrapper
package. Building PIE by default in the compiler is something I haven't
finished testing. (Also note that included with PIE is -Wl,-z,now since
it's not hugely useful as a defensive ELF feature without PIE. Though since
it seems that with the symbol hash table now, there isn't a penalty in
using it so maybe it should become a stand-alone default. Needs more
research...)

> 2) The current state of the patch doesn't properly document that the
> flag is on by default; if the patch is enabled, it should say so in
> the documentation, not referencing a version of Ubuntu.

Sure, this could easily be changed. It does say things are on by default,
but the "since when" language would need to be changed to reflect the
inclusion of Debian.

> 3) Who is willing to do a complete rebuild with the patch enabled and
> handle filing any bugs (with appropriate patches, ideally) that turn
> up? [On how many architectures?]

Is there infrastructure to do a full archive rebuild on all architectures?
I've always filed bugs (usually with patches) in Debian for any issues I've
noticed in Ubuntu from building with the hardening options enabled, so at
least i386, amd64, powerpc, sparc, and armel should be relatively free from
complications. I do not know what to expect from hppa and m68k, but at
least hardening-wrapper has build-time tests and logic to avoid broken
situations -- this logic may need to be moved into the gcc package if the
defaults are enabled there (since Ubuntu builds only a subset of the Debian
archs).

> 4) What solution would you enact if the CTTE were to have hardening be
> on by default for all Debian packages, but disabled by default for the
> compiler as shipped?

One of the options would be to use hardening-wrapper with a config file
on the buildds. The wrapper already reads /etc/hardening-wrapper.conf,
so that DEB_BUILD_HARDENING=1 can be set globally. If the wrapper were
part of build-essential or pre-installed in the buildd chroots and the
buildds had this turned on (probably with DEB_BUILD_HARDENING_PIE=0
for archs that had low general register counts like ia32), the entire
archive would be built with hardening without any changes to the compiler.

I suspect some people will utterly hate this idea, though, but it will
work. Though the global defaults can even be explicitly disabled in a
build (debian/rules exporting DEB_BUILD_HARDENING=0, or some subset,
for example) if there were packages with specific issues.

-Kees

-- 
Kees Cook                                            @debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Tue, 26 Jul 2011 21:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 Jul 2011 21:36:03 GMT) Full text and rfc822 format available.

Message #147 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 552688@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Tue, 26 Jul 2011 23:32:27 +0200
[Message part 1 (text/plain, inline)]
Hi,

On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> I would really like Debian to build hardened binaries by default and it
> would be great if the switch could happen early in the wheezy cycle. For
> this I think we need to have a clear plan and I hope the technical
> committee can bring some clarity here. Either by overruling the GCC
> maintainer or by designing the missing pieces so that we can at least go
> forward (I would implement what's needed in dpkg-dev if I knew what's
> needed).

So we just had some discussion with Steve Langasek, Ian Jackson, Bdale
Garbee, me and Matthias Klose on this topic. I'll try to summarize the
outcome here. It's probably a good idea to be familiar with the
current dpkg-buildflags features before reading this mail, so check
"man dpkg-buildflags" if needed.

The consensus seems to be that we do not want to take the "gcc patch"
approach and thus we're not going to overrule the maintainer. The bulk
of the discussion then drifted on deciding how (hardening) build flags
should be injected in the package build process.

We evaluated how dpkg-buildflags can be used for this. For most
autoconf/automake-based build systems there are	2 ways to inject flags:
1/ On the ./configure command line:
./configure --with-foo CFLAGS="..." LDFLAGS="..." ...
2/ In the environment

The first form seem to be preferred but both approaches work and should be
properly supported. However dpkg-buildflags does not easily support the
former approach. This is something that should be fixed.

TODO: implement "dpkg-buildflags --export=configure" that outputs
“CFLAGS="…" LDFLAGS="…" ...” so that a maintainer can do
./configure --with-foo $(shell dpkg-buildflags --export=configure)

Also up to now, dpkg-buildflags has only been designed to return the
default build flags and it was my expectation that maintainers would
tweak its output should this be necessary (either to add flags or to
drop them, etc.).

Unfortunately recent experience proved that dpkg-buildflags is likely to
be called by various helpers and thus not in direct control of the
maintainer via the rules files (unless all the helper provide their own
way to do this but we really would like to avoid having severals ways
to do the same thing). The current git version of dpkg already has support
for debian/buildflags{,.<arch>} to allow maintainers to post-process
the resulting buildflags but while this interface works for 95% of the
easy cases, it can't cover them all because we have stuff like packages
doing several builds of the same code with different build options (for
example -Os for udebs) or adding flags depending on which compiler is 
actually in use. So the correct interface to feed post-processing
instructions to dpkg-buildflags is environment variables (because this way
we can call dpkg-builflags multiple times with different values to the
environment variable as part of the debian/rules logic).

TODO: revert debian/buildflags support, and implement
support for the environment variable DEB_<flag>_MAINT_<operation> which
work exactly like the corresponding DEB_<flag>_<operation> except it's
meant to be used by the package maintainer within debian/rules.

Another limitation of dpkg-buildflags thas has been brought up is that
it only allows to append build flags and not to drop them. While it's
often possible to disable some option by providing the opposite option
later on the command line (e.g. "... --foo ... --no-foo"), it has been
pointed out that the possibility to drop them is useful in particular when
you would like to use another compiler that doesn't understand the
option in question. Also it's cleaner as the resulting command line is
shorter and more readable.

TODO: add a "STRIP" operation to the set of operations supported by
dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
drop all occurrences of --foo and --bar in the returned build flags.

QUESTION: Is this ok to assume that all build flags can be "delimited"
by a space character?

Assuming that all those improvements are done, the consensus was that
it's fine for dpkg-buildflags to start emitting the hardening build
flags by default. According to Ubuntu's experience only a few dozen of
packages are broken by the presence of these flags and those packages
should just be updated to use the new STRIP operation to drop the
problematic flags. This could be dealt as part of a wheezy release goal.

Obviously those new flags will only be picked by packages already using
dpkg-buildflags but that already includes packages using "dh" since it uses
dpkg-buildflags to set the corresponding environment variable and 
also packages using CDBS (AFAIK). The other remaining packages would have
to be updated by hand (and could also be part of a release goal).

The discussion mainly covered automake/autoconf-based build systems and
obviously there are some packages using alternate build systems where
this out-of-the-box support by dh/CDBS will not be enough. In those cases,
it's still up to the maintainer to adapt whatever is needed to feed
the build flags in the appropriate way.

Hopefully I have not forgotten anything important and I have correctly
summarized the whole discussion (which was rather dense for a 1h
discussion).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Wed, 27 Jul 2011 14:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Jul 2011 14:12:03 GMT) Full text and rfc822 format available.

Message #152 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: doko@debian.org, vorlon@debian.org, 552688@bugs.debian.org
Subject: Re: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Wed, 27 Jul 2011 07:09:29 -0700
Hi,

Thanks for the forward! Comment below...

On Wed, Jul 27, 2011 at 12:03:24AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> see the attached mail I just sent to the tech-ctte bug about hardening
> build flags.
> 
> Kees, it would be good to have your feedback.
> 
> Cheers,
> -- 
> Raphaël Hertzog ◈ Debian Developer
> 
> Follow my Debian News ▶ http://RaphaelHertzog.com (English)
>                       ▶ http://RaphaelHertzog.fr (Français)

> Date: Tue, 26 Jul 2011 23:32:27 +0200
> From: Raphael Hertzog <hertzog@debian.org>
> To: 552688@bugs.debian.org
> Cc: debian-dpkg@lists.debian.org
> Subject: Bug#552688: Please decide how Debian should enable hardening build
>  flags
> 
> Hi,
> 
> On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> > I would really like Debian to build hardened binaries by default and it
> > would be great if the switch could happen early in the wheezy cycle. For
> > this I think we need to have a clear plan and I hope the technical
> > committee can bring some clarity here. Either by overruling the GCC
> > maintainer or by designing the missing pieces so that we can at least go
> > forward (I would implement what's needed in dpkg-dev if I knew what's
> > needed).
> 
> So we just had some discussion with Steve Langasek, Ian Jackson, Bdale
> Garbee, me and Matthias Klose on this topic. I'll try to summarize the
> outcome here. It's probably a good idea to be familiar with the
> current dpkg-buildflags features before reading this mail, so check
> "man dpkg-buildflags" if needed.
> 
> The consensus seems to be that we do not want to take the "gcc patch"
> approach and thus we're not going to overrule the maintainer. The bulk
> of the discussion then drifted on deciding how (hardening) build flags
> should be injected in the package build process.

For the record, I still think this is a mistake since then only built
packages are protected instead of everything the compiler builds. FWIW, I
intend to still use the gcc patch in Ubuntu.

> We evaluated how dpkg-buildflags can be used for this. For most
> autoconf/automake-based build systems there are	2 ways to inject flags:
> 1/ On the ./configure command line:
> ./configure --with-foo CFLAGS="..." LDFLAGS="..." ...
> 2/ In the environment
> 
> The first form seem to be preferred but both approaches work and should be
> properly supported. However dpkg-buildflags does not easily support the
> former approach. This is something that should be fixed.
> 
> TODO: implement "dpkg-buildflags --export=configure" that outputs
> “CFLAGS="…" LDFLAGS="…" ...” so that a maintainer can do
> ./configure --with-foo $(shell dpkg-buildflags --export=configure)

That seems like a good addition.

> Also up to now, dpkg-buildflags has only been designed to return the
> default build flags and it was my expectation that maintainers would
> tweak its output should this be necessary (either to add flags or to
> drop them, etc.).
> 
> Unfortunately recent experience proved that dpkg-buildflags is likely to
> be called by various helpers and thus not in direct control of the
> maintainer via the rules files (unless all the helper provide their own
> way to do this but we really would like to avoid having severals ways
> to do the same thing). The current git version of dpkg already has support
> for debian/buildflags{,.<arch>} to allow maintainers to post-process
> the resulting buildflags but while this interface works for 95% of the
> easy cases, it can't cover them all because we have stuff like packages
> doing several builds of the same code with different build options (for
> example -Os for udebs) or adding flags depending on which compiler is 
> actually in use. So the correct interface to feed post-processing
> instructions to dpkg-buildflags is environment variables (because this way
> we can call dpkg-builflags multiple times with different values to the
> environment variable as part of the debian/rules logic).
> 
> TODO: revert debian/buildflags support, and implement
> support for the environment variable DEB_<flag>_MAINT_<operation> which
> work exactly like the corresponding DEB_<flag>_<operation> except it's
> meant to be used by the package maintainer within debian/rules.

I'm not sure how this will interact with hardening options, but okay.

> Another limitation of dpkg-buildflags thas has been brought up is that
> it only allows to append build flags and not to drop them. While it's
> often possible to disable some option by providing the opposite option
> later on the command line (e.g. "... --foo ... --no-foo"), it has been
> pointed out that the possibility to drop them is useful in particular when
> you would like to use another compiler that doesn't understand the
> option in question. Also it's cleaner as the resulting command line is
> shorter and more readable.
> 
> TODO: add a "STRIP" operation to the set of operations supported by
> dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
> drop all occurrences of --foo and --bar in the returned build flags.

Right, this will be required for the PIE options (see the end of
/usr/share/hardening-includes/hardening.make for details).

> QUESTION: Is this ok to assume that all build flags can be "delimited"
> by a space character?

For the hardening flags, yes.

> Assuming that all those improvements are done, the consensus was that
> it's fine for dpkg-buildflags to start emitting the hardening build
> flags by default. According to Ubuntu's experience only a few dozen of
> packages are broken by the presence of these flags and those packages
> should just be updated to use the new STRIP operation to drop the
> problematic flags. This could be dealt as part of a wheezy release goal.

And a large portion of them are already fixed since Ubuntu reported the
bugs to Debian and most were fixed.

> Obviously those new flags will only be picked by packages already using
> dpkg-buildflags but that already includes packages using "dh" since it uses
> dpkg-buildflags to set the corresponding environment variable and 
> also packages using CDBS (AFAIK). The other remaining packages would have
> to be updated by hand (and could also be part of a release goal).
> 
> The discussion mainly covered automake/autoconf-based build systems and
> obviously there are some packages using alternate build systems where
> this out-of-the-box support by dh/CDBS will not be enough. In those cases,
> it's still up to the maintainer to adapt whatever is needed to feed
> the build flags in the appropriate way.
> 
> Hopefully I have not forgotten anything important and I have correctly
> summarized the whole discussion (which was rather dense for a 1h
> discussion).

I see three remaining issues:

- by what mechanism will dpkg-buildflags use hardening-includes? It
  wouldn't make sense to duplicate the existing arch-specific logic
  that lives in hardening-includes.

- should the hardening flags presence still be controlled by the env
  variables that are exposed as the existing interfaces defined by
  hardening-wrapper/hardening-includes?

- there needs to be a way to identify those architectures that are
  "register starved", since those should _not_ get the PIE flags by
  default (e.g. i386 should not get PIE, but amd64 should get PIE by
  default). Right now if one uses hardening-wrapper, it's expected
  that everything that can be enabled is enabled, so you gain PIE
  even on i386 at the moment.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Wed, 27 Jul 2011 15:15:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Jul 2011 15:15:22 GMT) Full text and rfc822 format available.

Message #157 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@debian.org>, 552688@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Wed, 27 Jul 2011 17:13:30 +0200
Hi,

On Wed, 27 Jul 2011, Kees Cook wrote:
> > TODO: revert debian/buildflags support, and implement
> > support for the environment variable DEB_<flag>_MAINT_<operation> which
> > work exactly like the corresponding DEB_<flag>_<operation> except it's
> > meant to be used by the package maintainer within debian/rules.
> 
> I'm not sure how this will interact with hardening options, but okay.

It's not really relevant for hardening options except that if we want to
make dpkg-buildflags a mandatory interface to retrieve the complete
set of build flags, it's important that the interface it offers can be used
in all cases.

> > QUESTION: Is this ok to assume that all build flags can be "delimited"
> > by a space character?
> 
> For the hardening flags, yes.

The question was more general because it's a generic interface for
dpkg-buildflags and it should handle any build flag that might
realistically be used.

> > Assuming that all those improvements are done, the consensus was that
> > it's fine for dpkg-buildflags to start emitting the hardening build
> > flags by default. According to Ubuntu's experience only a few dozen of
> > packages are broken by the presence of these flags and those packages
> > should just be updated to use the new STRIP operation to drop the
> > problematic flags. This could be dealt as part of a wheezy release goal.
> 
> And a large portion of them are already fixed since Ubuntu reported the
> bugs to Debian and most were fixed.

How are they fixed? By adding DEB_BUILD_HARDENING_* := 0 in their
environment?

> I see three remaining issues:

I think all those issues are to be sorted between you and me, and
do not need the involvment of the technical committee (but obviously
I always welcome review by anyone even of TC members :)).

> - by what mechanism will dpkg-buildflags use hardening-includes? It
>   wouldn't make sense to duplicate the existing arch-specific logic
>   that lives in hardening-includes.

It would not be reasonable for dpkg-dev to depend on hardening-includes so
my plan was basically to move this logic into dpkg-dev. But instead of
duplicating it we can find a way for hardening-includes to reuse the logic
that would be integrated in dpkg-dev.

All the code is in libdpkg-perl and we can decide to have a specific
function that retrieves only the hardening build flags instead of all the
build flags.

That said, why should hardening-includes last any longer if
dpkg-buildflags offers everything it does?

> - should the hardening flags presence still be controlled by the env
>   variables that are exposed as the existing interfaces defined by
>   hardening-wrapper/hardening-includes?

If that's how current debian packages have been fixed, possibly yes at the
start but we would emit a warning explaining that package have to be
updated to use the new STRIP dpkg-buildflags operation.

And at some point, the support for those env variables should be dropped.

> - there needs to be a way to identify those architectures that are
>   "register starved", since those should _not_ get the PIE flags by
>   default (e.g. i386 should not get PIE, but amd64 should get PIE by
>   default). Right now if one uses hardening-wrapper, it's expected
>   that everything that can be enabled is enabled, so you gain PIE
>   even on i386 at the moment.

Not sure I understand your problem. What's difficult in excluding
i386 from the set of architectures where PIE is used?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Wed, 27 Jul 2011 22:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Jul 2011 22:00:04 GMT) Full text and rfc822 format available.

Message #162 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Cc: kees@debian.org, doko@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Wed, 27 Jul 2011 23:56:39 +0200
Hi,

On Tue, 26 Jul 2011, Raphael Hertzog wrote:
> Assuming that all those improvements are done, the consensus was that
> it's fine for dpkg-buildflags to start emitting the hardening build
> flags by default. According to Ubuntu's experience only a few dozen of
> packages are broken by the presence of these flags and those packages
> should just be updated to use the new STRIP operation to drop the
> problematic flags. This could be dealt as part of a wheezy release goal.

I have prepared a branch that implements all this, that also includes
hardening build flags and that modify dpkg's debian/rules to actually
use dpkg-buildflags in the way we expect maintainers to use it.

See http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/build-flags
You can grab it with "git clone git://git.debian.org/~hertzog/dpkg.git -b
pu/build-flags".

In the course of doing this I discovered that this won't have the
expected result:
---
export DEB_CFLAGS_MAINT_APPEND = -Wall
[...]
	./configure $(shell dpkg-buildflags --export=configure)
---

Apparently make doesn't export the variables to the sub-shell
run in this way but only to shells run for commands in the various
targets. So instead I have to do it this way:
./configure $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)

One thing that is really not clear to me is how we should handle PIE.
It's not enabled by default by the gcc patch. This means that it's not
safe to enable it by default in dpkg-buildflags because we have no idea of
its impact. While all the other options have been well tested thanks to
Ubuntu, this one was not. Yet it seems that we should still aim to use it
by default at some point. How should we handle that transition?

The current implementation in my branch is that PIE is disabled by defaut
but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
easily done on top of the compatibility layer with
hardening-includes/hardening-wrapper but I'm not convinced it's an
interface we want to use for this transition.

In that case, it means that we should rebuild the archive with PIE
enabled, see what breaks, report bugs and ask people to add
DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
where required. Once most packages have been fixed, we can add
PIE to the default flags. Does this sound reasonable?

Should we go further and provide centralized variables that can be used
to strip out the precise set of build flags that each hardening "feature"
adds? For reference /usr/share/hardening-includes/hardening.make does
provide such variables.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 16:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 16:57:03 GMT) Full text and rfc822 format available.

Message #167 received at 552688@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 18:55:11 +0200
On 07/27/2011 11:56 PM, Raphael Hertzog wrote:
> Hi,
>
> On Tue, 26 Jul 2011, Raphael Hertzog wrote:
>> Assuming that all those improvements are done, the consensus was that
>> it's fine for dpkg-buildflags to start emitting the hardening build
>> flags by default. According to Ubuntu's experience only a few dozen of
>> packages are broken by the presence of these flags and those packages
>> should just be updated to use the new STRIP operation to drop the

for strip you need to know the exact options to be passed; wouldn't it be better 
to have them stripped by something like `nohardening'?

> In the course of doing this I discovered that this won't have the
> expected result:
> ---
> export DEB_CFLAGS_MAINT_APPEND = -Wall
> [...]
> 	./configure $(shell dpkg-buildflags --export=configure)
> ---
>
> Apparently make doesn't export the variables to the sub-shell
> run in this way but only to shells run for commands in the various
> targets. So instead I have to do it this way:
> ./configure $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)
>
> One thing that is really not clear to me is how we should handle PIE.
> It's not enabled by default by the gcc patch. This means that it's not
> safe to enable it by default in dpkg-buildflags because we have no idea of
> its impact. While all the other options have been well tested thanks to
> Ubuntu, this one was not.

> Yet it seems that we should still aim to use it
> by default at some point. How should we handle that transition?

I did see performance penalties of more than 20% on i386 and armel when enabling 
PIE by default. This shouldn't be the scope of this discussion, and I still 
don't see value to rebuild the whole archive using PIE.

> The current implementation in my branch is that PIE is disabled by defaut
> but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> easily done on top of the compatibility layer with
> hardening-includes/hardening-wrapper but I'm not convinced it's an
> interface we want to use for this transition.
>
> In that case, it means that we should rebuild the archive with PIE
> enabled, see what breaks, report bugs and ask people to add
> DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
> where required. Once most packages have been fixed, we can add
> PIE to the default flags. Does this sound reasonable?

No, there's no value having cc1 built with PIE, same for number crunching 
libraries, doubtful for interpreters.

  Matthias




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 17:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 17:03:06 GMT) Full text and rfc822 format available.

Message #172 received at 552688@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Kees Cook <kees@debian.org>
Cc: Raphael Hertzog <hertzog@debian.org>, vorlon@debian.org, 552688@bugs.debian.org
Subject: Re: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Thu, 28 Jul 2011 19:01:02 +0200
On 07/27/2011 04:09 PM, Kees Cook wrote:
> - there needs to be a way to identify those architectures that are
>    "register starved", since those should _not_ get the PIE flags by
>    default (e.g. i386 should not get PIE, but amd64 should get PIE by
>    default). Right now if one uses hardening-wrapper, it's expected
>    that everything that can be enabled is enabled, so you gain PIE
>    even on i386 at the moment.

please communicate the trade off even for amd64. It's measurable, and I don't 
see any value in slowing down cc1* for this.

  Matthias




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 20:36:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 20:36:07 GMT) Full text and rfc822 format available.

Message #177 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, doko@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 13:34:02 -0700
On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
> One thing that is really not clear to me is how we should handle PIE.
> It's not enabled by default by the gcc patch. This means that it's not
> safe to enable it by default in dpkg-buildflags because we have no idea of
> its impact. While all the other options have been well tested thanks to
> Ubuntu, this one was not. Yet it seems that we should still aim to use it
> by default at some point. How should we handle that transition?

While I did not make it a default in Ubuntu yet, I have done archive
rebuilds with PIE enabled. It was about 2 years ago, but they were still
interesting. The majority of things compiled fine, but the logs were huge,
so I, unfortunately, deleted them a while ago.

I really want have it be the default for at least amd64. There are a
few issues that come to mind:

- speed impact in places
  Some things are genuinely slower with PIE (but I don't have amd64
  benchmarks -- I only measured i386 at the time). My feeling is that
  speed sensitive packages (e.g. cc1 as doko points out) would then have
  the option of disabling it for their specific build. The default case,
  I think, is worth it, though I haven't actually ever been able to
  keep all the rebuilds I did with testing to see if there were any
  problems with a running system built that way.

- assembly FTBFSes
  There are a few packages (usually codecs etc) that have non-relocatable
  assembly in them, so PIE builds fail to handle it, or to find an available
  register to use for thunking. This is, I feel, a case-by-case issue.
  Ironically, these are usually the things I'd like to see built PIE more
  than other things! :)

- non-PIC .a file relocation
  Using PIE by default means that packages shipping non-PIC .a files
  suddenly produce relocatable .a files. If a package that links against
  them isn't building as PIE too, it will FTBFS.

> The current implementation in my branch is that PIE is disabled by defaut
> but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> easily done on top of the compatibility layer with
> hardening-includes/hardening-wrapper but I'm not convinced it's an
> interface we want to use for this transition.

If someone chose to build-dep on hardening-wrapper/hardening-includes, they
expect to have built PIE, so I think that the dpkg-buildflags default
should likely depend on that in some way.

The problem here is that h-w/i defaults to PIE-when-supported rather than
PIE-when-supported-and-desired, so having a maintainer explicitly set
DEB_BUILD_HARDENING_PIE=1 will trigger FTBFS on the architectures that
don't support it. I think we'll need some other flag instead that means
"PIE if possible" when moving from dpkg-buildflags from h-w/i.

It might be possible to reorganize hardening.make to have
_HARDENED_PIE_CFLAGS and _HARDENED_PIE_LDFLAGS only be populated on archs
that support PIE. Right now, the selection logic is part of
HARDENING_CFLAGS and HARDENING_LDFLAGS. Or they could be exposed as a
separate set?

There's a lot of ways to do this. I'm not sure what is best. What's
important to me is that maintainers that were using h-w/i don't suddenly
end up with builds that aren't PIE, since they explicitly chose to build
with PIE (unless they also explicitly chose to disable it).

> In that case, it means that we should rebuild the archive with PIE
> enabled, see what breaks, report bugs and ask people to add
> DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
> where required. Once most packages have been fixed, we can add
> PIE to the default flags. Does this sound reasonable?

Well, this can only be done once the archive is using dpkg-buildflags,
which will be a long transition, IIUC.

> Should we go further and provide centralized variables that can be used
> to strip out the precise set of build flags that each hardening "feature"
> adds? For reference /usr/share/hardening-includes/hardening.make does
> provide such variables.

It seemed like a good idea to me (which is why hardening.make has it), so
I'd support that again. Having a common way to control the flags seems like
a very good idea.

There's also the complex case of some build systems passing -fPIC to
everything, which supersedes -fPIE unfortunately. I think this is a GCC
bug, personally, but I haven't had time to hunt it down.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 20:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 20:45:03 GMT) Full text and rfc822 format available.

Message #182 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 13:42:19 -0700
Hi Matthias,

On Thu, Jul 28, 2011 at 06:55:11PM +0200, Matthias Klose wrote:
> On 07/27/2011 11:56 PM, Raphael Hertzog wrote:
> >On Tue, 26 Jul 2011, Raphael Hertzog wrote:
> >>Assuming that all those improvements are done, the consensus was that
> >>it's fine for dpkg-buildflags to start emitting the hardening build
> >>flags by default. According to Ubuntu's experience only a few dozen of
> >>packages are broken by the presence of these flags and those packages
> >>should just be updated to use the new STRIP operation to drop the
> 
> for strip you need to know the exact options to be passed; wouldn't
> it be better to have them stripped by something like `nohardening'?

Do you mean via DEB_BUILD_OPTIONS? That can't really be set _in_ a
package, so we'd need something else, IIUC.

> >One thing that is really not clear to me is how we should handle PIE.
> >It's not enabled by default by the gcc patch. This means that it's not
> >safe to enable it by default in dpkg-buildflags because we have no idea of
> >its impact. While all the other options have been well tested thanks to
> >Ubuntu, this one was not.
> 
> >Yet it seems that we should still aim to use it
> >by default at some point. How should we handle that transition?
> 
> I did see performance penalties of more than 20% on i386 and armel
> when enabling PIE by default. This shouldn't be the scope of this
> discussion, and I still don't see value to rebuild the whole archive
> using PIE.

I recall it being no more than 15% in the worst case, but yes, that was
for the register-starved architectures. I totally agree: it should not be
the default for i386. I would like to see more benchmarks for armel and
amd64, though.

The only part of PIE, I think, should be that it should be able to be
enabled trivially, so that the hardening-wrapper/includes transition is
easy for maintainers.

> >The current implementation in my branch is that PIE is disabled by defaut
> >but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> >easily done on top of the compatibility layer with
> >hardening-includes/hardening-wrapper but I'm not convinced it's an
> >interface we want to use for this transition.
> >
> >In that case, it means that we should rebuild the archive with PIE
> >enabled, see what breaks, report bugs and ask people to add
> >DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
> >where required. Once most packages have been fixed, we can add
> >PIE to the default flags. Does this sound reasonable?
> 
> No, there's no value having cc1 built with PIE, same for number
> crunching libraries, doubtful for interpreters.

Libraries are already PIC. PIE will only make a difference for the main
binary. But, as you say, worst-case situations tend to be things that use
very few library calls, like interpreters, compilers, etc. I would agree that
cc1 doesn't need to be PIE. I would, however, argue that interpreters
should be PIE, since they are frequently dealing with external input
(just think of all the utf-8 vulnerabilities that have happened over
the last few years).

But, as you mention, this is out of scope really. Let's get the rest in
place and work to make the transition not accidentally trigger feature
loss for maintainers.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 21:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 21:00:03 GMT) Full text and rfc822 format available.

Message #187 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Thu, 28 Jul 2011 13:57:42 -0700
On Wed, Jul 27, 2011 at 05:13:30PM +0200, Raphael Hertzog wrote:
> On Wed, 27 Jul 2011, Kees Cook wrote:
> > > Assuming that all those improvements are done, the consensus was that
> > > it's fine for dpkg-buildflags to start emitting the hardening build
> > > flags by default. According to Ubuntu's experience only a few dozen of
> > > packages are broken by the presence of these flags and those packages
> > > should just be updated to use the new STRIP operation to drop the
> > > problematic flags. This could be dealt as part of a wheezy release goal.
> > 
> > And a large portion of them are already fixed since Ubuntu reported the
> > bugs to Debian and most were fixed.
> 
> How are they fixed? By adding DEB_BUILD_HARDENING_* := 0 in their
> environment?

The Ubuntu gcc patch doesn't handle the DEB_BUILD_HARDENING_* flags, so
the bulk of the fixes were for things that _FORTIFY_SOURCE and
stack-protector caught, so the code itself was fixed either upstream or
with a Debian-carried patch.

Things that were built in Ubuntu with hardening-wrapper/includes were
to explicitly gain PIE (since gcc already turned everything else on),
so when they went weird they were fixed the same way (code fixes,
upstream or Debian-carried patch). Most of the packages that had an
Ubuntu delta of just h-w/i were taken by the Debian maintainers, so all
of those packages should be sensible.

> > - by what mechanism will dpkg-buildflags use hardening-includes? It
> >   wouldn't make sense to duplicate the existing arch-specific logic
> >   that lives in hardening-includes.
> 
> It would not be reasonable for dpkg-dev to depend on hardening-includes so
> my plan was basically to move this logic into dpkg-dev. But instead of
> duplicating it we can find a way for hardening-includes to reuse the logic
> that would be integrated in dpkg-dev.

That seems fine to me as long as I'm in a position to still be able to fix
bugs in the logic. :)

> That said, why should hardening-includes last any longer if
> dpkg-buildflags offers everything it does?

I'm totally fine with h-i going away. The "hardening-check" script will
need somewhere to live, though. And, as mentioned in the other thread, we
need to figure out a sensible transition for the PIE bits, since it will
likely start life in dpkg-buildflags globally disabled.

> > - should the hardening flags presence still be controlled by the env
> >   variables that are exposed as the existing interfaces defined by
> >   hardening-wrapper/hardening-includes?
> 
> If that's how current debian packages have been fixed, possibly yes at the
> start but we would emit a warning explaining that package have to be
> updated to use the new STRIP dpkg-buildflags operation.

Maintainers transitioning from hardening-wrapper should just skip straight
to STRIP since it's the same work moving from -wrapper to -includes.

Maintainers transitioning from hardening-includes should be able to easily
switch to STRIP, so I'm not sure it's worth supporting the h-i flags.

Do you have an example of what the STRIP stuff would look like for a build?
I don't want maintainers to have to know what all the individual flags are,
especially since they might change, which is why I did what I did in h-i.

> And at some point, the support for those env variables should be dropped.
> 
> > - there needs to be a way to identify those architectures that are
> >   "register starved", since those should _not_ get the PIE flags by
> >   default (e.g. i386 should not get PIE, but amd64 should get PIE by
> >   default). Right now if one uses hardening-wrapper, it's expected
> >   that everything that can be enabled is enabled, so you gain PIE
> >   even on i386 at the moment.
> 
> Not sure I understand your problem. What's difficult in excluding
> i386 from the set of architectures where PIE is used?

Hopefully I explained this in the other thread. The situation is that
everyone presently using h-w/i expects to build PIE, on architectures
that _support_ it, including architectures that should not use it by
_default_. So we need an easy way in a specific package to turn on PIE
for architectures that support it, but for which we don't want it on by
default.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 21:03:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 21:03:09 GMT) Full text and rfc822 format available.

Message #192 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@debian.org>, 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 23:02:16 +0200
Hi,

On Thu, 28 Jul 2011, Kees Cook wrote:
> On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
> > The current implementation in my branch is that PIE is disabled by defaut
> > but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> > easily done on top of the compatibility layer with
> > hardening-includes/hardening-wrapper but I'm not convinced it's an
> > interface we want to use for this transition.
> 
> If someone chose to build-dep on hardening-wrapper/hardening-includes, they
> expect to have built PIE, so I think that the dpkg-buildflags default
> should likely depend on that in some way.

Do you mean analyze the build-dep to automatically enable PIE? That
doesn't seem clean and I'd rather have maintainer make it explicit.

If hardening-includes/hardening-wrapper is still used by that package,
does it really matter what dpkg-buildflags is returning?

> The problem here is that h-w/i defaults to PIE-when-supported rather than
> PIE-when-supported-and-desired, so having a maintainer explicitly set
> DEB_BUILD_HARDENING_PIE=1 will trigger FTBFS on the architectures that
> don't support it. I think we'll need some other flag instead that means
> "PIE if possible" when moving to dpkg-buildflags from h-w/i.

Why? If a package migrates from h-w/i to dpkg-buildflags I don't expect
it to keep using h-w/i.

> There's a lot of ways to do this. I'm not sure what is best. What's
> important to me is that maintainers that were using h-w/i don't suddenly
> end up with builds that aren't PIE, since they explicitly chose to build
> with PIE (unless they also explicitly chose to disable it).

That seems a matter of properly documenting the transition from one to the
other.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 21:15:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 21:15:13 GMT) Full text and rfc822 format available.

Message #197 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: Raphael Hertzog <hertzog@debian.org>, vorlon@debian.org, 552688@bugs.debian.org
Subject: Re: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Thu, 28 Jul 2011 14:11:38 -0700
On Thu, Jul 28, 2011 at 07:01:02PM +0200, Matthias Klose wrote:
> On 07/27/2011 04:09 PM, Kees Cook wrote:
> >- there needs to be a way to identify those architectures that are
> >   "register starved", since those should _not_ get the PIE flags by
> >   default (e.g. i386 should not get PIE, but amd64 should get PIE by
> >   default). Right now if one uses hardening-wrapper, it's expected
> >   that everything that can be enabled is enabled, so you gain PIE
> >   even on i386 at the moment.
> 
> please communicate the trade off even for amd64. It's measurable,
> and I don't see any value in slowing down cc1* for this.

Hopefully I have done this in one of the other emails now.

Do you have a specific test-case I can use for cc1? I cannot find my notes
on the Python benchmark you showed me before, so that would be handy too.
At the time, I only benchmarked i386 since I wanted to better understand
the scope of the slowdown there, under the assumption that everything was
better off than i386. :)

In the hardening bzr tree, I have some notes from i386 comparisons,
all with caches dropped before starting each run:

Inkscape converting a massive SVG to PNG, under 1%, same error:
inkscape    Normal  Hardened (with PIE)
1           48.163  48.503
2           48.227  48.535
3           48.267  48.647
4           48.335  48.431
5           48.199  48.587
avg         48.2382 48.5406 diff: 0.63%
error       0.20%   0.22%

gfsplit chopping up 1M random data into 50-of-100 splits, was faster,
but within the normal error, so hard to say:
gfsplit Normal  Hardened (with PIE)
1       32.226  32.022
2       32.118  32.042
3       32.026  32.026
4       32.178  31.996
5       31.998  32.054
avg     32.1092 32.028  diff: -0.253%
error   0.36%   0.08%

Nexiuz timedemo, under 1%, though the hardened error was high:
nexuiz  Normal  Hardened (with PIE)
1       66.680  68.113
2       66.802  66.930
3       66.758  67.030
4       66.728  67.051
5       66.859  67.037
avg     66.7654 67.2322  diff: 0.70%
error   0.14%   1.31%

I don't have the Python benchmark unfortunately, but it was impressively
nasty. Something like 15% slower. So while many things do just fine,
some show amazingly bad speed changes on i386. But, I haven't seen the
benchmarks for amd64 and armel. I'm very curious them, given that even on
i386 most things are under 1% (and when these benchmarks were done,
they also included _FORTIFY_SOURCE and stack-protector and everything
else in the speed delta).

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 21:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 21:45:04 GMT) Full text and rfc822 format available.

Message #202 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 14:42:16 -0700
On Thu, Jul 28, 2011 at 11:02:16PM +0200, Raphael Hertzog wrote:
> On Thu, 28 Jul 2011, Kees Cook wrote:
> > On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
> > > The current implementation in my branch is that PIE is disabled by defaut
> > > but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> > > easily done on top of the compatibility layer with
> > > hardening-includes/hardening-wrapper but I'm not convinced it's an
> > > interface we want to use for this transition.
> > 
> > If someone chose to build-dep on hardening-wrapper/hardening-includes, they
> > expect to have built PIE, so I think that the dpkg-buildflags default
> > should likely depend on that in some way.
> 
> Do you mean analyze the build-dep to automatically enable PIE? That
> doesn't seem clean and I'd rather have maintainer make it explicit.
> 
> If hardening-includes/hardening-wrapper is still used by that package,
> does it really matter what dpkg-buildflags is returning?

Yeah, all true. I guess it should be in the docs that cover migration from
h-i/h-w. Looking at the git branch, you've already handled the "and
supported" option, so just "DEB_BUILD_HARDENING_PIE=1" is sufficient.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 21:48:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 21:48:10 GMT) Full text and rfc822 format available.

Message #207 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 14:46:28 -0700
On Thu, Jul 28, 2011 at 02:42:16PM -0700, Kees Cook wrote:
> On Thu, Jul 28, 2011 at 11:02:16PM +0200, Raphael Hertzog wrote:
> > If hardening-includes/hardening-wrapper is still used by that package,
> > does it really matter what dpkg-buildflags is returning?
> 
> Yeah, all true. I guess it should be in the docs that cover migration from
> h-i/h-w. Looking at the git branch, you've already handled the "and
> supported" option, so just "DEB_BUILD_HARDENING_PIE=1" is sufficient.

That said, maintainers may want to disable hardening features on a
file-by-file basis. Right now, it's possible to use all the stuff defined
in hardening.make to get at those for filtering. It seems like we need
something similar here? (Basically, the corner case described at line 102
of hardening.make.)

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 22:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 22:33:09 GMT) Full text and rfc822 format available.

Message #212 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@debian.org>, 552688@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Fri, 29 Jul 2011 00:29:17 +0200
On Thu, 28 Jul 2011, Kees Cook wrote:
> > It would not be reasonable for dpkg-dev to depend on hardening-includes so
> > my plan was basically to move this logic into dpkg-dev. But instead of
> > duplicating it we can find a way for hardening-includes to reuse the logic
> > that would be integrated in dpkg-dev.
> 
> That seems fine to me as long as I'm in a position to still be able to fix
> bugs in the logic. :)

Well, it's low-maintenance mode I hope so I have no problem merging your
patches whenever needed.

> I'm totally fine with h-i going away. The "hardening-check" script will
> need somewhere to live, though.

lintian? devscripts? dpkg-dev? I'm not sure what the best place is. But I
would really like lintian to check if all binaries are built with hardening
flags. It should probably not report any problem as long as one of
the hardening feature has been found.

That way it's still possible to disable some of the hardening features
without generating a warning that you have to override.

> Do you have an example of what the STRIP stuff would look like for a build?
> I don't want maintainers to have to know what all the individual flags are,
> especially since they might change, which is why I did what I did in h-i.

DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie" dpkg-buildflags

So yes it requires precise knowledge of the flag in use. To make this
less obnoxious I can certainly include a copy of the default flags
in the new /usr/share/dpkg/buildflags.mk file and let maintainer
use the variables listed there instead of hardcoding the precise set of
flags.

(I just did that in my pu/build-flags test branch)

But this is all rather verbose, maybe it's best to keep some separate
logic to enable/disable hardening features. Other opinions are welcome.
Maybe with a DEB_BUILD_MAINT_OPTIONS variable.

DEB_BUILD_MAINT_OPTIONS="hardening=-relro,+pie"

> Hopefully I explained this in the other thread. The situation is that
> everyone presently using h-w/i expects to build PIE, on architectures
> that _support_ it, including architectures that should not use it by
> _default_. So we need an easy way in a specific package to turn on PIE
> for architectures that support it, but for which we don't want it on by
> default.

Maybe something like this:
DEB_BUILD_MAINT_OPTIONS="hardening=+pie:default"
DEB_BUILD_MAINT_OPTIONS="hardening=+pie:always"

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 22:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 22:57:03 GMT) Full text and rfc822 format available.

Message #217 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Date: Thu, 28 Jul 2011 15:55:53 -0700
On Fri, Jul 29, 2011 at 12:29:17AM +0200, Raphael Hertzog wrote:
> On Thu, 28 Jul 2011, Kees Cook wrote:
> > That seems fine to me as long as I'm in a position to still be able to fix
> > bugs in the logic. :)
> 
> Well, it's low-maintenance mode I hope so I have no problem merging your
> patches whenever needed.

Cool. Normally it's just been little things -- tweaking features, updating
documentation, or changing arch exclusions.

> > I'm totally fine with h-i going away. The "hardening-check" script will
> > need somewhere to live, though.
> 
> lintian? devscripts? dpkg-dev? I'm not sure what the best place is. But I
> would really like lintian to check if all binaries are built with hardening
> flags. It should probably not report any problem as long as one of
> the hardening feature has been found.
> 
> That way it's still possible to disable some of the hardening features
> without generating a warning that you have to override.

Lintian was where I have been planning to put it, but it's non-trivial. It
is easy to detect certain hardening features (BINDNOW, RELRO), but
stack-protector and _FORTIFY_SOURCE are not possible to detect that they
are strictly _missing_. For example, if a program doesn't use any string
arrays on the stack, it will have no protected stacks. Same for the
protected libc functions with fortify.

> > Do you have an example of what the STRIP stuff would look like for a build?
> > I don't want maintainers to have to know what all the individual flags are,
> > especially since they might change, which is why I did what I did in h-i.
> 
> DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie" dpkg-buildflags
> 
> So yes it requires precise knowledge of the flag in use. To make this
> less obnoxious I can certainly include a copy of the default flags
> in the new /usr/share/dpkg/buildflags.mk file and let maintainer
> use the variables listed there instead of hardcoding the precise set of
> flags.
> 
> (I just did that in my pu/build-flags test branch)

Excellent, I think this is the right thing to do. The flags do slowly
change over time (e.g. adding "--param ssp-buffer-size=4" to stack
protector).

Oh, eek, pointing out that example reminds me about the "can be space
separated?" question ... "--param ssp-buffer-size=4" has a space in the
middle! It should be safe to change this to "--param=ssp-buffer-size=4".
Sorry about missing that.

I'm still not sure what to do about the -fPIC vs -fPIE conflict for
cmake builds, though. I guess the documentation should just specifically
mention it and show how to filter for those cases. And it's not like it's
anything except -fPIC, so I don't think we need a whole system to deal with
it.

> But this is all rather verbose, maybe it's best to keep some separate
> logic to enable/disable hardening features. Other opinions are welcome.
> Maybe with a DEB_BUILD_MAINT_OPTIONS variable.
> 
> DEB_BUILD_MAINT_OPTIONS="hardening=-relro,+pie"

This would be excellent.

> > Hopefully I explained this in the other thread. The situation is that
> > everyone presently using h-w/i expects to build PIE, on architectures
> > that _support_ it, including architectures that should not use it by
> > _default_. So we need an easy way in a specific package to turn on PIE
> > for architectures that support it, but for which we don't want it on by
> > default.
> 
> Maybe something like this:
> DEB_BUILD_MAINT_OPTIONS="hardening=+pie:default"
> DEB_BUILD_MAINT_OPTIONS="hardening=+pie:always"

I think just "+pie" is sufficient, due to how you wrote the supported
tests.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Thu, 28 Jul 2011 23:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 28 Jul 2011 23:21:02 GMT) Full text and rfc822 format available.

Message #222 received at 552688@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 28 Jul 2011 16:18:17 -0700
Oh, I've thought of one additional detail in making these defaults.
"-Werror=format-security" was only recently added, and this will likely
cause a fair level of FTBFS from some packages. This is not one of the gcc
defaults used in Ubuntu. It was added to hardening-includes because h-i has
effectively been a low-volume opt-in build-dep.

Since switching to dpkg-buildflags is also opt-in, it probably shouldn't
hurt too much, but I have never attempted an archive-wide rebuild with
-Werror=format-security added to the hardening flags.

Personally, I think it's a good idea to fix them all, but on the other
hand, having _FORTIFY_SOURCE enabled _should_ block most of the dangerous
format string conditions. It won't block leaks, though, which could lead to
stack protection bypasses, etc.

So, I'll be sure to call it out in documentation. I may reproduce the
Ubuntu wiki page I wrote for reference in the Debian wiki, since it is
where we send people by default when the hardening flags cause problems:
https://wiki.ubuntu.com/CompilerFlags

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 29 Jul 2011 08:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 29 Jul 2011 08:00:03 GMT) Full text and rfc822 format available.

Message #227 received at 552688@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 29 Jul 2011 00:56:34 -0700
On Tue, Jul 26, 2011 at 11:32:27PM +0200, Raphael Hertzog wrote:
> TODO: add a "STRIP" operation to the set of operations supported by
> dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
> drop all occurrences of --foo and --bar in the returned build flags.

> QUESTION: Is this ok to assume that all build flags can be "delimited"
> by a space character?

Counterexample: -Wl,-z -Wl,defs

While this *can* also be written as -Wl,-z,defs, I'm not sure there's any
way to guarantee it will be?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 29 Jul 2011 08:33:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 29 Jul 2011 08:33:11 GMT) Full text and rfc822 format available.

Message #232 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@debian.org>
Cc: 552688@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Fri, 29 Jul 2011 10:31:09 +0200
Hi,

On Thu, 28 Jul 2011, Kees Cook wrote:
> Oh, I've thought of one additional detail in making these defaults.
> "-Werror=format-security" was only recently added, and this will likely
> cause a fair level of FTBFS from some packages. This is not one of the gcc
> defaults used in Ubuntu. It was added to hardening-includes because h-i has
> effectively been a low-volume opt-in build-dep.
> 
> Since switching to dpkg-buildflags is also opt-in, it probably shouldn't
> hurt too much, but I have never attempted an archive-wide rebuild with
> -Werror=format-security added to the hardening flags.

It's not opt-in for all packages, any package using "dh" and CDBS is
already using dpkg-buildflags... so we should definitely get some
statistics before deciding to keep this by default.

Can you do the work of collecting those statistics? Tollef has access
to a big machine where building all package takes 14h. Roger Leigh used
it for that kind of research.

Maybe you can do the rebuild without -Werror=format-security and just grep
the log to find out those that would fail.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 29 Jul 2011 08:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 29 Jul 2011 08:48:04 GMT) Full text and rfc822 format available.

Message #237 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Fri, 29 Jul 2011 10:44:48 +0200
On Fri, 29 Jul 2011, Steve Langasek wrote:
> On Tue, Jul 26, 2011 at 11:32:27PM +0200, Raphael Hertzog wrote:
> > TODO: add a "STRIP" operation to the set of operations supported by
> > dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
> > drop all occurrences of --foo and --bar in the returned build flags.
> 
> > QUESTION: Is this ok to assume that all build flags can be "delimited"
> > by a space character?
> 
> Counterexample: -Wl,-z -Wl,defs
> 
> While this *can* also be written as -Wl,-z,defs, I'm not sure there's any
> way to guarantee it will be?

Well, the point of the "strip" operation is to drop the build flags we're
injecting by default so as long as we're able to write all flags that
we're injecting in a way that doesn't require the use of the space, we
should be fine.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Sun, 31 Jul 2011 07:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 31 Jul 2011 07:03:03 GMT) Full text and rfc822 format available.

Message #242 received at 552688@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org, doko@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 31 Jul 2011 00:01:08 -0700
[Message part 1 (text/plain, inline)]
On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
> In the course of doing this I discovered that this won't have the
> expected result:
> ---
> export DEB_CFLAGS_MAINT_APPEND = -Wall
> [...]
> 	./configure $(shell dpkg-buildflags --export=configure)
> ---

> Apparently make doesn't export the variables to the sub-shell
> run in this way but only to shells run for commands in the various
> targets. So instead I have to do it this way:
> ./configure $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)

I would be inclined to write this as:

BUILD_FLAGS = $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)

build:
	./configure $(BUILD_FLAGS)

though a helper implementing this may of course choose to avoid clobbering
the namespace by declaring new make variables.

> Should we go further and provide centralized variables that can be used
> to strip out the precise set of build flags that each hardening "feature"
> adds? For reference /usr/share/hardening-includes/hardening.make does
> provide such variables.

Now that we've suggested complementing DEB_BUILD_OPTIONS with
DEB_BUILD_MAINT_OPTIONS, it stands to reason that we might define some
macros for common cases.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Mon, 15 Aug 2011 02:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Geissert <geissert@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 15 Aug 2011 02:06:03 GMT) Full text and rfc822 format available.

Message #247 received at 552688@bugs.debian.org (full text, mbox):

From: Raphael Geissert <geissert@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Tue, 9 Aug 2011 23:01:23 -0500
[sorry for breaking the thread]

Hi,

Raphael Hertzog wrote:
> Can you do the work of collecting those statistics? Tollef has access
> to a big machine where building all package takes 14h. Roger Leigh used
> it for that kind of research.
> 
> Maybe you can do the rebuild without -Werror=format-security and just grep
> the log to find out those that would fail.

This was already done back at DC10 and the outcome was 8 packages FTBFS[1]. 
However, taking a further look at them now, it looks like the rebuild was not 
done as intended and only packages using h-w were influenced by the new flag.

If the flag is disabled then I think it is pointless to enable -Wformat and -
Wformat-security, as I stated in #587358.

[1] quagga, bist, grap, robodoc, nast, rtpproxy, strongswan, zoem 

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Mon, 19 Mar 2012 04:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 19 Mar 2012 04:21:03 GMT) Full text and rfc822 format available.

Message #252 received at 552688@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Sun, 18 Mar 2012 21:16:41 -0700
I believe at this point the dpkg-buildflags solution has proven reasonably
successful and is being widely deployed.  I think we should confirm that
the TC agrees with that approach and close out this bug.

I therefore propose the following ballot:

A. The Technical Committee agrees with the dpkg-buildflags approach
   currently in use to enable hardening flags.

B. Further discussion.

I think the remaining open question is whether there is a desire to list
overriding the GCC maintainer and patching GCC to enable the flags for all
compilation on the ballot.  My guess is that there is not; if anyone
disagrees, please speak up and I'll draft a revised ballot including that
option.

If there is no other feedback, I plan to call for a vote on the above
ballot in a few days.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 04 May 2012 07:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 04 May 2012 07:09:04 GMT) Full text and rfc822 format available.

Message #257 received at 552688@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 4 May 2012 02:06:01 -0500
Hi Russ,

Russ Allbery wrote:

> I believe at this point the dpkg-buildflags solution has proven reasonably
> successful and is being widely deployed.  I think we should confirm that
> the TC agrees with that approach and close out this bug.

While I understand that the PR effect would be good, I encourage you
not to do that.  Instead, I'd suggest just closing the bug as
described at [1]:

| 5. Sometimes, one side or other is convinced, during the committee's
|    deliberations, by the merit of the other side's arguments. This
|    is a good thing! If it happens, the committee need not make a
|    formal decision

It would be probably be worth listing issues that were resolved this
way somewhere on the Technical Committee website.  It is the best
possible outcome and worth celebrating.

Thanks,
Jonathan

[1] http://www.debian.org/devel/tech-ctte




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 04 May 2012 15:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 04 May 2012 15:51:03 GMT) Full text and rfc822 format available.

Message #262 received at 552688@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Fri, 04 May 2012 08:48:19 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> I believe at this point the dpkg-buildflags solution has proven
>> reasonably successful and is being widely deployed.  I think we should
>> confirm that the TC agrees with that approach and close out this bug.

> While I understand that the PR effect would be good, I encourage you
> not to do that.  Instead, I'd suggest just closing the bug as
> described at [1]:

> | 5. Sometimes, one side or other is convinced, during the committee's
> |    deliberations, by the merit of the other side's arguments. This
> |    is a good thing! If it happens, the committee need not make a
> |    formal decision

Why?

The solution that was chosen was chosen in part because of the tech-ctte
discussion and because of opinions expressed by the tech-ctte members.  I
believe it's a case where we would have made a formal decision had the
process been working more efficiently, and that it's worthwhile recording
that decision going forward.  I say that in part with my Policy editor hat
on, as there was quite a lot of discussion about this and related topics
in the Policy context and this decision provides some welcome clarity to
how similar situations should be handled going forward.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#552688; Package tech-ctte. (Fri, 04 May 2012 17:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 04 May 2012 17:48:03 GMT) Full text and rfc822 format available.

Message #267 received at 552688@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 552688@bugs.debian.org, debian-dpkg@lists.debian.org, kees@debian.org
Subject: Re: Please decide how Debian should enable hardening build flags
Date: Fri, 4 May 2012 12:46:46 -0500
Russ Allbery wrote:

> Why?

No strong reason.  The tech-ctte is free to decide any matter of
technical policy they choose to, so there's no constitutional reason
to go the way I was suggesting.

Since it sounds like you've thought about this carefully already,
I'm satisfied.  Sorry for the noise.




Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Thu, 31 May 2012 19:45:13 GMT) Full text and rfc822 format available.

Notification sent to Kees Cook <kees@debian.org>:
Bug acknowledged by developer. (Thu, 31 May 2012 19:45:13 GMT) Full text and rfc822 format available.

Message #272 received at 552688-done@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 552688-done@bugs.debian.org
Subject: Re: Bug#552688: Please decide how Debian should enable hardening build flags
Date: Thu, 31 May 2012 12:41:33 -0700
Following discussion of this bug in today's Technical Committee meeting on
IRC, we tentatively decided (assuming no objections from those who
couldn't make it) to decide this is resolved by the dpkg-buildflags work
and to close it without a vote.

If there are any objections, particularly from TC members who couldn't
make the meeting, or if anyone involved in this work feels that it would
be useful for the TC to make a formal decision, please let me know and
I'll reopen.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 29 Jun 2012 07:42:19 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 19:13:16 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.