Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
[ CCing Sylvestre given the involvement in the GSoC proposal. ]
Hi!
On Mon, 2014-09-15 at 16:44:04 +0200, Guillem Jover wrote:
On Sun, 2014-09-07 at 20:31:58 +0200, Bálint Réczey wrote:
2014-09-07 17:26 GMT+02:00 Guillem Jover guil...@debian.org:
On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
The attached patches adds
the new port and enables ASAN and UBSAN through the hardening flags.
The flags are disabled on other architectures by default even when using
hardening=all, since ASAN causes significant slowdown and UBSAN will
probably reveal a lot of issues in many packages.
I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
disabled by default on a feature area, but if they do not make sense
to be enabled by “all” then they do not belong in the hardening feature
area, probably in another one. OOC how many packages do enable all
hardening features?
I think distinguishing between 'all' and 'extra' has its history, gcc
-Wall and -Wextra are similar to our case. I think ASAN should not be
part of 'all' because it should be enebled for packages shipping
binaries first, then in packages shipping the libraries used by the
binaries, thus it is not a per-package decision to enable ASAN.
UBSAN is different, I think it could be added to 'all', but I'm not
sure how many packages use 'all' and I did not want to break them.
Maybe after a full archive rebuild revealing the breakages.
What I meant is that I'm going to add a new feature area named “qa”,
alongside “hardening”, so it seems it might make sense to have a new
“sanitizer” (or similar name) feature area, with all new interesting
sanitizer options, such as asan, ubsan, tsan, lsan, etc. Does that
make more sense now?
Here's the patch I'm considering to commit, and given that there's been
no replies to the other questions and issues rised previously in the bug
report, I'm thinking about closing it with this patch.
Thanks,
Guillem
From 5016b6781bf5658505b2fb86b7666b87f044bd4a Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Tue, 21 Oct 2014 22:43:55 +0200
Subject: [PATCH] Dpkg::Vendor::Debian: Add sanitize area feature
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This feature area includes the features “address”, “thread”, “leak” and
“undefined”.
Cloess: #760741
---
man/dpkg-buildflags.1 | 27 --
scripts/Dpkg/Vendor/Debian.pm | 52 +++
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1
index ad42427..ca8488b 100644
--- a/man/dpkg-buildflags.1
+++ b/man/dpkg-buildflags.1
@@ -135,8 +135,9 @@ the flag is set/modified by an environment-specific configuration.
.TP
.BI \-\-query\-features area
Print the features enabled for a given area. The only currently recognized
-areas on Debian and derivatives are \fBqa\fP, \fBreproducible\fP and
-\fBhardening\fP, see the \fBFEATURE AREAS\fP section for more details.
+areas on Debian and derivatives are \fBqa\fP, \fBreproducible\fP,
+\fBsanitize\fP and \fBhardening\fP, see the \fBFEATURE AREAS\fP
+section for more details.
Exits with 0 if the area is known otherwise exits with 1.
.IP
The output is in RFC822 format, with one section per feature.
@@ -230,6 +231,28 @@ The only currently supported flags are \fBCPPFLAGS\fP, \fBCFLAGS\fP,
to \fB\-D__DEB_CANARY_\fP\fIflag\fP_\fIrandom-id\fP\fB__\fP, and
\fBLDFLAGS\fP set to \fB\-Wl,\-z,deb-canary\-\fP\fIrandom-id\fP.
.
+.SS Sanitize
+Several compile-time options (detailed below) can be used to help sanitize
+a resulting binary against memory corruptions, memory leaks, use after free,
+threading data races and undefined behavior bugs.
+.TP
+.B address
+This setting (disabled by default) adds \fB\-fsanitize=address\fP to
+\fBLDFLAGS\fP and \fB\-fsanitize=address \-fno\-omit\-frame\-pointer\fP to
+\fBCFLAGS\fP and \fBCXXFLAGS\fP.
+.TP
+.B thread
+This setting (disabled by default) adds \fB\-fsanitize=thread\fP to
+\fBCFLAGS\fP, \fBCXXFLAGS\fP and \fBLDFLAGS\fP.
+.TP
+.B leak
+This setting (disabled by default) adds \fB\-fsanitize=leak\fP to
+\fBLDFLAGS\fP. It gets automatically disabled if either the \fBaddress\fP
+or the \fBthread\fP features are enabled, as they imply it.
+.TP
+.B undefined
+This setting (disabled by default) adds \fB\-fsanitize=undefined\fP to
+\fBCFLAGS\fP, \fBCXXFLAGS\fP and \fBLDFLAGS\fP.
.SS Hardening
Several compile-time options (detailed below) can be used to help harden
a resulting binary against memory corruption attacks, or provide
diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 7bf45da..62b9a1b 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -69,6 +69,7 @@ sub run_hook {
} elsif ($hook eq 'update-buildflags') {
$self-_add_qa_flags(@params);
$self-_add_reproducible_flags(@params);
+
Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
Hi! On Sun, 2014-09-07 at 20:31:58 +0200, Bálint Réczey wrote: 2014-09-07 17:26 GMT+02:00 Guillem Jover guil...@debian.org: On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote: Package: dpkg Version: 1.17.13 Severity: wishlist Tags: patch I'm working on a new port, hardened-amd64 [1]. This does not what dpkg ports are meant to denote, as I think was mentioned in that thread. If the ports are ABI compatible then they are the same port. The lpia port was such a thing, which I disagreed with at the time but accepted anyway, and that was a mistake I'm not going to repeat. I'm planning on removing lpia support soonish to avoid anyone else take that as a precedent to follow. This is the equivalent of bumping the instruction set baseline or enabling a different set of build flags by default, etc. Please see the recent Boostrap Sprint notes on the multiple ISAs section, which is relevant for your scenario. In any case I'm not planning on adding support for a hardened-amd64 architecture, sorry. Sorry for not mentioning it earlier, but I don't intend to keep ABI compatibility. In what ways? You mention some above, but I'd like to understand to what extend. Libraries compiled with ASAN can't be loaded binaries without ASAN support, thus the ABI can be considered to be different. Do you have more information on this, I didn't see anything obvious by reading the (almost non-existent) information in gcc, and the canonical one in http://dev.chromium.org/developers/testing/addresssanitizer. I also plan removing some functions which are deprecated for security reasons but path of the ABI such as getwd(), thus ABI compatibility is broken again, in a different way. Well, these kind of functions can be deactivated w/o breaking ABI. For example getwd() could return NULL and set errno to ENAMETOOLONG. Or even abort at run-time. Or it could be marked to emit an error at build-time. Third, I would like to enable breaking the ABI for enabling efficient tracking of pointers through library calls. SoftBound + CETS [2] projects are researching this way and if they come up with something usable I would like to adopt it. Well, once the architecture is accepted it's “supposed” to have a stable os-kernel-cpu ABI defined, it seems to me you want to have the freedom to experiment with new developments that might break ABI? In which case I think this really should be a private playground until something stable has been defined. The attached patches adds the new port and enables ASAN and UBSAN through the hardening flags. The flags are disabled on other architectures by default even when using hardening=all, since ASAN causes significant slowdown and UBSAN will probably reveal a lot of issues in many packages. I'd be fine with adding ASAN and UBSAN or any other hardening stuff, disabled by default on a feature area, but if they do not make sense to be enabled by “all” then they do not belong in the hardening feature area, probably in another one. OOC how many packages do enable all hardening features? I think distinguishing between 'all' and 'extra' has its history, gcc -Wall and -Wextra are similar to our case. I think ASAN should not be part of 'all' because it should be enebled for packages shipping binaries first, then in packages shipping the libraries used by the binaries, thus it is not a per-package decision to enable ASAN. UBSAN is different, I think it could be added to 'all', but I'm not sure how many packages use 'all' and I did not want to break them. Maybe after a full archive rebuild revealing the breakages. What I meant is that I'm going to add a new feature area named “qa”, alongside “hardening”, so it seems it might make sense to have a new “sanitizer” (or similar name) feature area, with all new interesting sanitizer options, such as asan, ubsan, tsan, lsan, etc. Does that make more sense now? Please consired accepting the patches despite the fact that hardened-amd64 is not an official port yet. It would help the bootstrapping efforts and patch 2 would make it easier to experiment with ASAN and UBSAN for others. It's not a matter of it being or not an official port, the main requirement is that the GNU triplet is officially recognized and that the naming and the thing makes sense. Which does not in this case. I'm not sure which part of the proposal you are questioning here so I try to answer all of them. I added a FAQ entry about all the requirements (I could remember) a new port needs to fulfill at the end of https://wiki.debian.org/Teams/Dpkg/FAQ. As it stands this architecture seems to fail several of them. I think there was precedent for adopting an GNU triplet first in Debian then later getting it adopted upstream. That might have been the case in the distant past, I'd rather have it the other way around, in general. I'm not tied to a name. I think it is reasonable and reflects that this
Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
Package: dpkg
Version: 1.17.13
Severity: wishlist
Tags: patch
Hi,
I'm working on a new port, hardened-amd64 [1]. The attached patches adds
the new port and enables ASAN and UBSAN through the hardening flags.
The flags are disabled on other architectures by default even when using
hardening=all, since ASAN causes significant slowdown and UBSAN will
probably reveal a lot of issues in many packages.
Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
makes it FTBFS due to the following issue:
.../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
dpkg-buildpackage
...
PATH=../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
\
LC_ALL=C \
\
srcdir=../../src builddir=. \
PERL_DL_NONLAZY=1 \
PERL5OPT= \
/usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness-new({
lib = [ ../../scripts ], color = 1, verbosity = 0, failures = 1,
}); my $aggregate = $harness-runtests(@ARGV); die FAIL: test suite has
errors\n if $aggregate-has_errors;' \
../../src/t/dpkg_divert.t
../../src/t/dpkg_divert.t .. 1/257
not ok 62 - --list stderr
# Failed test '--list stderr'
# at ../../src/t/dpkg_divert.t line 106.
# got: '../../src/filesdb.c:581:21: runtime error: signed
integer overflow: 313137907 * 1787 cannot be represented in type 'int'
# '
# expected: ''
not ok 65 - --list * stderr
The third patch fixes the issue.
Please consired accepting the patches despite the fact that
hardened-amd64 is not an official port yet. It would help the
bootstrapping efforts and patch 2 would make it easier to experiment
with ASAN and UBSAN for others.
Cheers,
Balint
[1]
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/
From 8364086c0e499802d37d7a52ed295cf8c3014eb8 Mon Sep 17 00:00:00 2001
From: Balint Reczey rbal...@gaia.sz13.dyndns.org
Date: Tue, 22 Apr 2014 20:58:00 +0200
Subject: [PATCH 1/3] Add hardened-amd64 architecture
Use the new GNU name linux-gnuhardened for the hardened-amd64 arch.
Also extend tests to cover the new arch
---
lib/dpkg/test/t-arch.c | 3 ++-
ostable| 1 +
scripts/t/Dpkg_Arch.t | 15 ++-
triplettable | 1 +
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/lib/dpkg/test/t-arch.c b/lib/dpkg/test/t-arch.c
index 6078be4..3326c40 100644
--- a/lib/dpkg/test/t-arch.c
+++ b/lib/dpkg/test/t-arch.c
@@ -44,6 +44,7 @@ test_dpkg_arch_name_is_illegal(void)
/* Test valid architecture names. */
test_pass(dpkg_arch_name_is_illegal(i386) == NULL);
test_pass(dpkg_arch_name_is_illegal(amd64) == NULL);
+ test_pass(dpkg_arch_name_is_illegal(hardened-amd64) == NULL);
test_pass(dpkg_arch_name_is_illegal(hurd-i386) == NULL);
test_pass(dpkg_arch_name_is_illegal(kfreebsd-i386) == NULL);
test_pass(dpkg_arch_name_is_illegal(kfreebsd-amd64) == NULL);
@@ -212,7 +213,7 @@ test_dpkg_arch_describe(void)
void
test(void)
{
- test_plan(60);
+ test_plan(61);
test_dpkg_arch_name_is_illegal();
test_dpkg_arch_get_list();
diff --git a/ostable b/ostable
index 9f559bf..c3f5500 100644
--- a/ostable
+++ b/ostable
@@ -24,6 +24,7 @@ gnuspe-linux linux-gnuspe linux[^-]*-gnuspe
gnux32-linux linux-gnux32 linux[^-]*-gnux32
gnulp-linux linux-gnulp linux[^-]*-gnulp
gnu-linux linux-gnu linux[^-]*(-gnu.*)?
+gnuhardened-linux linux-gnuhardened linux[^-]*(-gnu.*)?
gnu-kfreebsd kfreebsd-gnu kfreebsd[^-]*(-gnu.*)?
gnu-knetbsd knetbsd-gnu knetbsd[^-]*(-gnu.*)?
gnu-kopensolaris kopensolaris-gnu kopensolaris[^-]*(-gnu.*)?
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index 91759ec..dc15966 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -13,7 +13,7 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see https://www.gnu.org/licenses/.
-use Test::More tests = 42;
+use Test::More tests = 54;
use strict;
use warnings;
@@ -41,11 +41,17 @@ is(debarch_to_multiarch('i386'), 'i386-linux-gnu',
'normalized i386 multiarch triplet');
is(debarch_to_multiarch('amd64'), 'x86_64-linux-gnu',
'normalized amd64 multiarch triplet');
+is(debarch_to_multiarch('hardened-amd64'), 'x86_64-linux-gnuhardened',
+ 'normalized hardened-amd64 multiarch triplet');
ok(!debarch_eq('amd64', 'i386'), 'no match, simple arch');
+ok(!debarch_eq('hardened-amd64', 'i386'), 'no match, simple arch');
ok(!debarch_eq('', 'amd64'), 'no match, empty first arch');
+ok(!debarch_eq('', 'hardened-amd64'), 'no match, empty first arch');
ok(!debarch_eq('amd64', ''), 'no match, empty second arch');
+ok(!debarch_eq('hardened-amd64', ''), 'no match, empty second arch');
ok(!debarch_eq('amd64', 'unknown'), 'no match, with first unknown arch');
+ok(!debarch_eq('hardened-amd64', 'unknown'), 'no match, with first unknown arch');
ok(!debarch_eq('unknown', 'i386'), 'no match, second unknown arch');
ok(debarch_eq('unknown', 'unknown'), 'match equal unknown arch');
Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
Hi!
On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
Package: dpkg
Version: 1.17.13
Severity: wishlist
Tags: patch
I'm working on a new port, hardened-amd64 [1].
This does not what dpkg ports are meant to denote, as I think was
mentioned in that thread. If the ports are ABI compatible then they
are the same port. The lpia port was such a thing, which I disagreed
with at the time but accepted anyway, and that was a mistake I'm not
going to repeat. I'm planning on removing lpia support soonish to
avoid anyone else take that as a precedent to follow.
This is the equivalent of bumping the instruction set baseline or
enabling a different set of build flags by default, etc. Please see
the recent Boostrap Sprint notes on the multiple ISAs section, which
is relevant for your scenario.
In any case I'm not planning on adding support for a hardened-amd64
architecture, sorry.
The attached patches adds
the new port and enables ASAN and UBSAN through the hardening flags.
The flags are disabled on other architectures by default even when using
hardening=all, since ASAN causes significant slowdown and UBSAN will
probably reveal a lot of issues in many packages.
I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
disabled by default on a feature area, but if they do not make sense
to be enabled by “all” then they do not belong in the hardening feature
area, probably in another one. OOC how many packages do enable all
hardening features?
Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
makes it FTBFS due to the following issue:
.../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
dpkg-buildpackage
...
PATH=../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
\
LC_ALL=C \
\
srcdir=../../src builddir=. \
PERL_DL_NONLAZY=1 \
PERL5OPT= \
/usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness-new({
lib = [ ../../scripts ], color = 1, verbosity = 0, failures = 1,
}); my $aggregate = $harness-runtests(@ARGV); die FAIL: test suite has
errors\n if $aggregate-has_errors;' \
../../src/t/dpkg_divert.t
../../src/t/dpkg_divert.t .. 1/257
not ok 62 - --list stderr
# Failed test '--list stderr'
# at ../../src/t/dpkg_divert.t line 106.
# got: '../../src/filesdb.c:581:21: runtime error: signed
integer overflow: 313137907 * 1787 cannot be represented in type 'int'
# '
# expected: ''
not ok 65 - --list * stderr
The third patch fixes the issue.
Thanks! I've merged this one locally, will be included in 1.17.14.
Please consired accepting the patches despite the fact that
hardened-amd64 is not an official port yet. It would help the
bootstrapping efforts and patch 2 would make it easier to experiment
with ASAN and UBSAN for others.
It's not a matter of it being or not an official port, the main
requirement is that the GNU triplet is officially recognized and that
the naming and the thing makes sense. Which does not in this case.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
Hi Gulliem,
2014-09-07 17:26 GMT+02:00 Guillem Jover guil...@debian.org:
Hi!
On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
Package: dpkg
Version: 1.17.13
Severity: wishlist
Tags: patch
I'm working on a new port, hardened-amd64 [1].
This does not what dpkg ports are meant to denote, as I think was
mentioned in that thread. If the ports are ABI compatible then they
are the same port. The lpia port was such a thing, which I disagreed
with at the time but accepted anyway, and that was a mistake I'm not
going to repeat. I'm planning on removing lpia support soonish to
avoid anyone else take that as a precedent to follow.
This is the equivalent of bumping the instruction set baseline or
enabling a different set of build flags by default, etc. Please see
the recent Boostrap Sprint notes on the multiple ISAs section, which
is relevant for your scenario.
In any case I'm not planning on adding support for a hardened-amd64
architecture, sorry.
Sorry for not mentioning it earlier, but I don't intend to keep ABI
compatibility.
Libraries compiled with ASAN can't be loaded binaries without ASAN
support, thus the ABI can be considered to be different.
I also plan removing some functions which are deprecated for security
reasons but path of the ABI such as getwd(), thus ABI compatibility is
broken again, in a different way.
Third, I would like to enable breaking the ABI for enabling efficient
tracking of pointers through library calls. SoftBound + CETS [2]
projects are researching this way and if they come up with something
usable I would like to adopt it.
Based on the three reasons above please don't consider amd64 and
hardened-amd64 ABI compatible and please don't reject it due to having
compatible ABI.
The attached patches adds
the new port and enables ASAN and UBSAN through the hardening flags.
The flags are disabled on other architectures by default even when using
hardening=all, since ASAN causes significant slowdown and UBSAN will
probably reveal a lot of issues in many packages.
I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
disabled by default on a feature area, but if they do not make sense
to be enabled by “all” then they do not belong in the hardening feature
area, probably in another one. OOC how many packages do enable all
hardening features?
I think distinguishing between 'all' and 'extra' has its history, gcc
-Wall and -Wextra are similar to our case. I think ASAN should not be
part of 'all' because it should be enebled for packages shipping
binaries first, then in packages shipping the libraries used by the
binaries, thus it is not a per-package decision to enable ASAN.
UBSAN is different, I think it could be added to 'all', but I'm not
sure how many packages use 'all' and I did not want to break them.
Maybe after a full archive rebuild revealing the breakages.
Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
makes it FTBFS due to the following issue:
.../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
dpkg-buildpackage
...
PATH=../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
\
LC_ALL=C \
\
srcdir=../../src builddir=. \
PERL_DL_NONLAZY=1 \
PERL5OPT= \
/usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness-new({
lib = [ ../../scripts ], color = 1, verbosity = 0, failures = 1,
}); my $aggregate = $harness-runtests(@ARGV); die FAIL: test suite has
errors\n if $aggregate-has_errors;' \
../../src/t/dpkg_divert.t
../../src/t/dpkg_divert.t .. 1/257
not ok 62 - --list stderr
# Failed test '--list stderr'
# at ../../src/t/dpkg_divert.t line 106.
# got: '../../src/filesdb.c:581:21: runtime error: signed
integer overflow: 313137907 * 1787 cannot be represented in type 'int'
# '
# expected: ''
not ok 65 - --list * stderr
The third patch fixes the issue.
Thanks! I've merged this one locally, will be included in 1.17.14.
Please consired accepting the patches despite the fact that
hardened-amd64 is not an official port yet. It would help the
bootstrapping efforts and patch 2 would make it easier to experiment
with ASAN and UBSAN for others.
It's not a matter of it being or not an official port, the main
requirement is that the GNU triplet is officially recognized and that
the naming and the thing makes sense. Which does not in this case.
I'm not sure which part of the proposal you are questioning here so I
try to answer all of them.
I think there was precedent for adopting an GNU triplet first in
Debian then later getting it adopted upstream.
I'm not tied to a name. I think it is reasonable and reflects that
this is not a port with a different kernel (hardened-amd64 vs.
kfreebsd-i386), but I'm open for better proposals.
I tried to explain the goals of having this new port (improved
security, discovering more bugs using the Debian buildds
automatically) and I
Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default
2014-09-07 20:31 GMT+02:00 Bálint Réczey bal...@balintreczey.hu: Hi Gulliem, 2014-09-07 17:26 GMT+02:00 Guillem Jover guil...@debian.org: Hi! On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote: Package: dpkg Version: 1.17.13 Severity: wishlist Tags: patch ... I'd be fine with adding ASAN and UBSAN or any other hardening stuff, disabled by default on a feature area, but if they do not make sense to be enabled by “all” then they do not belong in the hardening feature area, probably in another one. OOC how many packages do enable all hardening features? I think distinguishing between 'all' and 'extra' has its history, gcc -Wall and -Wextra are similar to our case. I think ASAN should not be part of 'all' because it should be enebled for packages shipping binaries first, then in packages shipping the libraries used by the binaries, thus it is not a per-package decision to enable ASAN. UBSAN is different, I think it could be added to 'all', but I'm not sure how many packages use 'all' and I did not want to break them. Maybe after a full archive rebuild revealing the breakages. Looks like 7-9% of packages use 'all'. http://outflux.net/debian/hardening/ Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
