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
[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
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
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
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
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.
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
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
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
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
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
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
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
13 matches
Mail list logo
