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.
Jonathan Nieder 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 eff
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 e
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-bu
[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-sec
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 doe
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
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 a
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
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
effectiv
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 w
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
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 shoul
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=
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 a
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 compa
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'
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
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
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-wrapp
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
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 presen
Hi,
On Wed, 27 Jul 2011, Kees Cook wrote:
> > TODO: revert debian/buildflags support, and implement
> > support for the environment variable DEB__MAINT_ which
> > work exactly like the corresponding DEB__ except it's
> > meant to be used by the package maintainer within debian/rules.
>
> I'm not
debian-d...@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 t
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 clari
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 hard
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
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-w
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 thi
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
> t
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
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
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 ?
--
To UNSUBSCRIBE, e
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.
W
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?
--
To UNSUBSCRIBE, email
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
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
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 approach
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
bef
dave b wrote:
> On 21 November 2010 02:45, Jonathan Nieder 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 t
On 21 November 2010 02:45, Jonathan Nieder 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 se
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)
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 m
43 matches
Mail list logo
