Re: [gentoo-dev] stability of 17.0 hardened profile

[Magnus Granberg]

onsdag 14 februari 2018 kl. 19:44:13 CET skrev  Paweł Hajdan, Jr.:
> I was looking into the new 17.0 profiles (nice work!), and noticed the
> hardened one is marked as dev. I'm somewhat concerned about switching to
> that on my laptop (I'm currently using hardened/linux/amd64).
> 
> Is there something I can do to help move the profile to stable?
> 
> Alternatively, is there a different profile recommended for hardened?
> 
> # eselect profile list
> ...
>   [12]  default/linux/amd64/17.0 (stable)
>   [13]  default/linux/amd64/17.0/selinux (dev)
>   [14]  default/linux/amd64/17.0/hardened (dev)
>   [15]  default/linux/amd64/17.0/hardened/selinux (dev)
>   [16]  default/linux/amd64/17.0/desktop (stable)
>   [17]  default/linux/amd64/17.0/desktop/gnome (stable)
>   [18]  default/linux/amd64/17.0/desktop/gnome/systemd (stable)
>   [19]  default/linux/amd64/17.0/desktop/plasma (stable)
>   [20]  default/linux/amd64/17.0/desktop/plasma/systemd (stable)
>   [21]  default/linux/amd64/17.0/developer (stable)
>   [22]  default/linux/amd64/17.0/no-multilib (stable)
>   [23]  default/linux/amd64/17.0/no-multilib/hardened (dev)
>   [24]  default/linux/amd64/17.0/no-multilib/hardened/selinux (dev)
>   [25]  default/linux/amd64/17.0/systemd (stable)
>   [26]  default/linux/amd64/17.0/x32 (dev)
> ...
>   [40]  hardened/linux/amd64 (stable) *
> 
> Paweł
Have mark the Hardened 17.0 as stable now
/Magnus

Re: [gentoo-dev] RFC: news item for the 17.0 profiles

[Magnus Granberg]

måndag 9 oktober 2017 kl. 22:58:22 CEST skrev  Andreas K. Huettel:
> =
> Title: New 17.0 profiles in the Gentoo repository
> Author: Andreas K. Hüttel 
> Posted: xxx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: >=sys-devel/gcc-6.4.0
> 
> We have just added a new set of profiles with release version 17.0
> to the Gentoo repository. These bring tree changes:
> 1) The default C++ language version for applications is now C++14.
>This change is mostly relevant to Gentoo developers. It also
>means, however, that compilers earlier than GCC 6 are masked
>and not supported for use as a system compiler anymore. Feel
>free to unmask them if you need them for specific applications.
> 2) Where supported, GCC will now build position-independent
>executables (PIE) by default. This improves the overall
>security fingerprint. The switch from non-PIE to PIE binaries,
>however, requires some steps by users, as detailed below.
> 
3) Hardened profiles will be moved to the 17.0 profile as sub profile.

> Please consider switching from your current 13.0 profile to the
> corresponding 17.0 profile soon after GCC-6.4.0 has been
> stabilized on your architecture. The 13.0 profiles will be deprecated
> and removed in the near future.
> 
> Switching involves the following steps:
> If not already done,
> * Use gcc-config to select gcc-6.4.0 or later as system compiler
> * Re-source /etc/profile:
> . /etc/profile
> * Re-emerge libtool
> Then,
> * Select the new profile with eselect
> * Re-emerge, in this sequence, gcc, binutils, and glibc
> emerge -1 sys-devel/gcc:6.4.0
> emerge -1 sys-devel/binutils
> emerge -1 sys-libs/glibc
> * Rebuild your entire system
> emerge -e world
> 
> If you do not follow these steps you may get spurious build
> failures when the linker tries unsuccessfully to combine non-PIE
> and PIE code.
> =

Re: [gentoo-dev] 17.0 profiles

[Magnus Granberg]

fredag 6 oktober 2017 kl. 14:23:49 CEST skrev  Andreas K. Huettel:
> Hi all,
> 
> Since gcc-6 stabilization is drawing closer, I'm going to prepare the
> remaining 17.0 profiles (right now they only exist for amd64).
> 
> Meaning... copy profiles/default/linux/*/13.0 to profiles/default/linux/*/
> 17.0, and edit it so it inherits 17.0 instead of 13.0.
> 
> Plan is to add the new profiles as "exp" to profiles.desc when arches are
> cc'ed to the gcc-6 stablereq, and switch them to the same status (exp/dev/
> stable) as the corresponding 13.0 profiles when an arch stabilizes gcc-6.
> 
> Packages that don't build with >=gcc-6 will be masked in the 17.0 profiles.
>  
> I'll only take care of the default/linux/* profiles. Everyone else
> (hardened, BSD, musl, ...) please feel free to contact me for advice.
> 
> Cheers,
> Andreas
Hardened will move to features/hardened as selinux have and be addad as sub 
profile to the 17.0 profiles. Amd64 will go first.
/Magnus G.

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

[Magnus Granberg]

måndag 23 januari 2017 kl. 13:56:02 CET skrev  Rich Freeman:
> On Mon, Jan 23, 2017 at 4:23 AM, Michał Górny  wrote:
> > I've written a short proposal that aims to provide basic infrastructure
> > for defining mix-in profiles in Gentoo. I've tried to keep it simple,
> > and backwards compatible. The main goal is to be able to start defining
> > some mix-ins without having to reinvent the whole profile tree.
> 
> Would it actually make sense to reinvent more of the profile tree
> while we're at it?  So, have a few categories of mixins like kernel,
> arch, and some category that covers really invasive stuff like
> hardened/libc/etc?
> 
i think it would make sense to reinvent/split it up to a few categories/mixins 
like
base
arch
  abi
libc
kernel
init/udev
desktop
server
security

> Those might be 1-of-n selections.
> 
> Then we could have the fluff that sits on top and just set some rules
> about what they can do.
> 
> Part of me wonders if some of this could also fit in with the use of
> virtuals (think foo-meta virtuals but bigger).  A virtual can of
> course pull in USE dependencies, and a lot of other stuff.  We could
> have convenience virtuals that all the profiles pull in by default but
> which gets stuff like openssh out of @system.
> 
> I'm only suggesting the last bit to the extent where we see tie-ins to
> improve the initial mix-in implementation.  A lot of that is probably
> an expansion in scope, and to that extent I'm not suggesting that it
> needs to be addressed.  I just want to think about it broadly at first
> to make sure we're not missing something.

[gentoo-dev] Gcc 6 and Gcc 5 update

[Magnus Granberg]

Hi

Gcc 6.X update:
Gcc 6.3 will soon get released in one or two weeks on that the pie use flag 
will get unmasked and gcj will be masked for java is removed in gcc 7
Package that fail with the pie flag needed to get fixed upstream for we are not
the only dist that use it now days.

Gcc 5.X update
Time to start fixing bugs [1] for it is time to mark it stable.
it will be 5.4 or 5.5. Any more bugs that need fixing that not in the gcc 5 
porting? 
[1] https://bugs.gentoo.org/show_bug.cgi?id=536984

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Magnus Granberg]

fredag 2 december 2016 kl. 23:32:37 CET skrev  Daniel Campbell:
> On 12/02/2016 06:09 AM, Michael Mol wrote:
> > On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote:
> >> Hi, everyone.
> >> 
> >> I've heard multiple times about various tinderbox projects being
> >> started by individuals in Gentoo. In fact, so many different projects
> >> that I've forgotten who was working on most of them.
> >> 
> >> I know that Toralf is doing tinderboxing for most of the stuff.
> >> What other projects do we have there? What is their status?
> >> 
> >> Is there anything we could try to integrate with pull requests to get
> >> a better testing?
> > 
> > If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I
> > have one or two systems I could benefit from some heat from over the
> > winter. It's that or bring out the electric space heater. Was talking
> > with my wife about mining Doge on one of them last night...
> 
> I second that. I have a hexcore CPU and 16 GB of RAM, most of which I
> don't use unless I'm compiling. If there's a guide that can get me up
> and running with a VM within an hour or so, I'd be more than willing to
> pitch in some cycles.
> 
> mgorny mentioned PRs, however... are such efforts moot if I don't have a
> GitHub account?
I run tinderbox-cluster [1] with 4-7 WM's but it have been down for some time 
now.  The web frontend need alot of work. It still miss bugreporting and build 
requests and the grafic need  work to. It use django.
/Magnus

[1] https://wiki.gentoo.org/wiki/Project:Tinderbox-cluster

[gentoo-dev] Uptade for toolchain.eclass and Gcc 6.2

[Magnus Granberg]

Hi

The patch add use flag for pch, so it can be disable.
We add support to use the configure options for pie and ssp
instead of the -D* hack for it.
The hardened use flag will add or remove some compile options as,
-fstrict_overflow will be turn of for -O2 and higher,
-fstack-check is added as default and
we change from -fstack-protect-strong to -fstack-protect-all.
It will not be any hardenedno* and vanilla options in gcc-config.
That is all change we bee do for hardened.

Ssp will be enable as default when i fix that it can be disable with -nostdlib.
For the pie part it will be option to enable even for default user in the 
amd64 arch when the major bugs i fixed for it.  See the tracker https://
bugs.gentoo.org/show_bug.cgi?id=582688 any bugs should be upstreamed for we 
just configure gcc to default to pie/ssp as default that gcc 6.x has support 
for.

/Magnus G.
Gentoo Hardened Lead Dev
--- gentoogit/gentoo/eclass/toolchain.eclass	2016-08-03 16:01:50.401048177 +0200
+++ hardened/hardened-dev/eclass/toolchain.eclass	2016-08-27 19:22:41.599786421 +0200
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
@@ -154,7 +154,7 @@ if [[ ${PN} != "kgcc64" && ${PN} != gcc-
 	tc_version_is_at_least 4.8 && IUSE+=" graphite" IUSE_DEF+=( sanitize )
 	tc_version_is_at_least 4.9 && IUSE+=" cilk +vtv"
 	tc_version_is_at_least 5.0 && IUSE+=" jit mpx"
-	tc_version_is_at_least 6.0 && IUSE+=" pie +ssp"
+	tc_version_is_at_least 6.0 && IUSE+=" pie ssp +pch"
 fi
 
 IUSE+=" ${IUSE_DEF[*]/#/+}"
@@ -626,6 +626,50 @@ do_gcc_PIE_patches() {
 
 # configure to build with the hardened GCC specs as the default
 make_gcc_hard() {
+
+	local gcc_hard_flags=""
+	# Gcc >= 6.X we can use configurations options to turn pie/ssp on as default
+	if tc_version_is_at_least 6.0 ; then
+		if use pie ; then
+			einfo "Updating gcc to use automatic PIE building ..."
+		fi
+		if use ssp ; then
+			einfo "Updating gcc to use automatic SSP building ..."
+		fi
+		if use hardened ; then
+			# Will add some optimatizion as default.
+			gcc_hard_flags+=" -DEXTRA_OPTIONS"
+			# rebrand to make bug reports easier
+			BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
+		fi
+	else
+		if use hardened ; then
+			# rebrand to make bug reports easier
+			BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
+			if hardened_gcc_works ; then
+einfo "Updating gcc to use automatic PIE + SSP building ..."
+gcc_hard_flags+=" -DEFAULT_PIE_SSP"
+			elif hardened_gcc_works pie ; then
+einfo "Updating gcc to use automatic PIE building ..."
+ewarn "SSP has not been enabled by default"
+gcc_hard_flags+=" -DEFAULT_PIE"
+			elif hardened_gcc_works ssp ; then
+einfo "Updating gcc to use automatic SSP building ..."
+ewarn "PIE has not been enabled by default"
+gcc_hard_flags+=" -DEFAULT_SSP"
+			else
+# do nothing if hardened isn't supported, but don't die either
+ewarn "hardened is not supported for this arch in this gcc version"
+return 0
+			fi
+		else
+			if hardened_gcc_works ssp ; then
+einfo "Updating gcc to use automatic SSP building ..."
+gcc_hard_flags+=" -DEFAULT_SSP"
+			fi
+		fi
+	fi
+
 	# we want to be able to control the pie patch logic via something other
 	# than ALL_CFLAGS...
 	sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
@@ -634,36 +678,8 @@ make_gcc_hard() {
 	# Need to add HARD_CFLAGS to ALL_CXXFLAGS on >= 4.7
 	if tc_version_is_at_least 4.7 ; then
 		sed -e '/^ALL_CXXFLAGS/iHARD_CFLAGS = ' \
--e 's|^ALL_CXXFLAGS = |ALL_CXXFLAGS = $(HARD_CFLAGS) |' \
--i "${S}"/gcc/Makefile.in
-	fi
-
-	# defaults to enable for all toolchains
-	local gcc_hard_flags=""
-	if use hardened ; then
-		if hardened_gcc_works ; then
-			einfo "Updating gcc to use automatic PIE + SSP building ..."
-			gcc_hard_flags+=" -DEFAULT_PIE_SSP"
-		elif hardened_gcc_works pie ; then
-			einfo "Updating gcc to use automatic PIE building ..."
-			ewarn "SSP has not been enabled by default"
-			gcc_hard_flags+=" -DEFAULT_PIE"
-		elif hardened_gcc_works ssp ; then
-			einfo "Updating gcc to use automatic SSP building ..."
-			ewarn "PIE has not been enabled by default"
-			gcc_hard_flags+=" -DEFAULT_SSP"
-		else
-			# do nothing if hardened isn't supported, but don't die either
-			ewarn "hardened is not supported for this arch in this gcc version"
-			return 0
-		fi
-		# rebrand to make bug reports easier
-		BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
-	else
-		if hardened_gcc_works ssp ; then
-			einfo "Updating gcc to use automatic SSP building ..."
-			gcc_hard_flags+=" -DEFAULT_SSP"
-		fi
+			-e 's|^ALL_CXXFLAGS = |ALL_CXXFLAGS = $(HARD_CFLAGS) |' \
+			-i "${S}"/gcc/Makefile.in
 	fi
 
 	sed -i \
@@ -899,6 +915,11 @@ toolchain_src_configure() {
 		confgcc+=( --enable-libstdcxx-time )
 	fi
 
+	# Support to 

[gentoo-dev] Cluster tinderbox poc

[Magnus Granberg]

Hi

As some of you may know, I have been working on code for a tinderbox with
frontend support. I think its time to move it to a offcial project.  
The Proof-Of-Concept (poc) is almost ready, but it still have alot of the
frontend left to do.   You can see the logs and summit bugsreports and
chose what to build. The poc is runing on a 64core box with help of ganeti
to manges the virtual machines (vm). I have 4 vm's runing for now but I will
add 4 more later. I'm building the vm's with help of 
ganeti-instance-gentoobootstrap.  The vm's query the db for what to build.
Db is update with tree info and list to builds for the vm's. The vm's are 
runing python code that call portage api to build the packages in the list.  
The frontend is just django.

Featuers
-Support multiplay repos
-Support any arch there the python code can run.
-Attach the build logs.
-Use the db to store the repex for log search.

/Magnus G.

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Magnus Granberg]

torsdag 12 juni 2014 03.45.23 skrev  Greg Turner:
 On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers j...@gentoo.org wrote:
  Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with
  -fstack-protector still leads to similar problems. There doesn't
  currently seem to be a bug report about this that isn't marked INVALID.
 
 Is this a bug/limitation in glibc's actual code, or in glibc's build
 environment?
 
 Asked another (wordier) way -- should I understand -- assuming nobody
 adds some explicit -fno-stack-protector to the non-hardened profiles
 or the glibc ebuild -- and, of course, also that the user has not put
 it in make.conf or similar -- that this would break glibc compilation
 in the base configurations of the x86/amd64 non-hardened profiles?*
 
 If that's so... that doesn't sound so great, does it?
 
 Just thinking out loud, I guess, but, the fact -- if it is, indeed,
 still a fact (?) -- that, as of gcc-4.8.2, putting -fstack-protector
 in your CFLAGS breaks glibc.ebuild doesn't /necessarily/ mean that, as
 of gcc-4.8.3, leaving -fno-stack-protector out of your cflags would
 also break it, even if they are supposed to mean the same thing --
 that would depend on the specific etiology of the problem.
 
 Sorry, perhaps Google Search would answer my question as readily as
 portage, in which case, by all means feel free to lmgtfy my ass.
 But if nobody knows the answer for sure, presumably you have the means
 to find out, Ryan?
 
 If for any reason you need a guinea-pig, I have a non-hardened
 triple-multilib (but mostly ABI_X86=64 32) workstation, here, that
 I'm not afraid to break.
 
 -gmt
 
 *Apologies for the horrific run-on sentence!

Glibc don't compile well with -fstack-protector* and that way we pass
-fno-stack-protector to the compiler when we build the lib. It is done in 
common.eblit where we check if the compiler have the ssp spec added as 
hardened and the default gcc 4.9 and 4.8.3 have.

The problem was when user did add -fstack-protector* to the cflag for the check 
didd't check that and upstream will just invalid the bug if you try to compile 
it with -fstack-protector*.
/Magnus

Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

[Magnus Granberg]

tisdag 10 juni 2014 14.22.11 skrev  Jeroen Roovers:
 On Mon, 9 Jun 2014 21:46:56 -0600
 
 Ryan Hill rh...@gentoo.org wrote:
  Yes.  But now you've got me worried.  We have to build gcc itself with
  -fno-stack-protector.  Does compiling something with that flag give
  an error on hppa?  Maybe give 4.8.2-r1 a whirl.
 
 Setting -fstack-protector on HPPA does this:
 
 warning: -fstack-protector not supported for this target [enabled by
  default]
 
 Setting -fno-stack-protector on HPPA causes no problems and is
 completely silent.
 
 
  jer
The arch that ssp will be enable by default is defined in the ebuild with
SSP_STABLE or SSP_UCLIBC_STABLE.

/Magnus

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

torsdag 09 januari 2014 23.18.28 skrev  Ryan Hill:
 On Thu, 09 Jan 2014 21:58:46 +0100
 
 Magnus Granberg zo...@gentoo.org wrote:
  Some time ago we discussed that we should enable stack smashing
  (-fstack-protector) by default.  So we opened a bug to track this [1].
  The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
  ppc, ppc64 and arm will be affected by this change.
  
  You can turn off ssp by using the nossp USE flag or by adding
  -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
  patch as Debian/Ubuntu but with some Gentoo fixes.
  
  The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
  ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
  make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
  it on or off with hardened_gcc_works() that will make some sanity checks.
 
 I went ahead and spun a new patchset for the compiler-side stuff if anyone
 wants to start playing around.
 
 - apply the eclass patch from bug #484714 (the one attached to Magnus' email
 wouldn't apply for me but maybe my mailer mangled it)
 - in gcc-4.8.2.ebuild do:
 
 -PATCH_VER=1.3
 +PATCH_VER=1.4-ssptest
 
 -PIE_VER=0.5.8
 +PIE_VER=0.5.9-ssptest
 
 BTW Magnus, thanks for doing this.
Hi
Have patched toolchain.eclass with the patch and with your change.
Updated 4.8.2 updated with the needed changes and commit it.
The use hardened  gcc-specs-ssp  append-cflags $(test-flags-CC -fno-stack-
protector) in glibc's common.eblit is fixed to.
So default ssp is out in the tree :)
/Magnus



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

torsdag 09 januari 2014 17.56.56 skrev  Ryan Hill:
 On Thu, 09 Jan 2014 21:58:46 +0100
 
 Magnus Granberg zo...@gentoo.org wrote:
  -   use hardened  make_gcc_hard
  +   if ( tc_version_is_at_least 4.8 || use hardened )  ! use vanilla ;
  then
 
 s/4.8/4.8.2
 
 Or should we wait until the next release (4.8.3 or 4.9.0)?  I think I'd
 prefer it but I don't have a good reason.
 
 What gcc-config profiles get installed after this patch?
We have only one now. But we can add a nossp but
i would only use it for debuging and it don't mix well with distcc.
The GCC_SPECS is not trasfered betvine the host and guest.

/Magnus



signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

Hi

Some time ago we discussed that we should enable stack smashing 
(-fstack-protector) by default.  So we opened a bug to track this [1].  
The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, 
ppc64 and arm will be affected by this change. 

You can turn off ssp by using the nossp USE flag or by adding 
-fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same 
patch as Debian/Ubuntu but with some Gentoo fixes.

The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and 
ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will 
make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn 
it on or off with hardened_gcc_works() that will make some sanity checks.

/Magnus
2013-12-31  Magnus Granberg  zo...@gentoo.org

	# 484714
	We Add -fstack-protector as default

--- a/eclass/toolchain.eclass	2013-12-30 21:21:05.431832881 +0100
+++ b/eclass/toolchain.eclass	2013-12-31 11:34:00.720993536 +0100
@@ -473,7 +473,9 @@ toolchain_src_prepare() {
 	do_gcc_PIE_patches
 	epatch_user
 
-	use hardened  make_gcc_hard
+	if ( tc_version_is_at_least 4.8 || use hardened )  ! use vanilla ; then
+		make_gcc_hard
+	fi
 
 	# install the libstdc++ python into the right location
 	# http://gcc.gnu.org/PR51368
@@ -606,6 +608,12 @@ do_gcc_PIE_patches() {
 		epatch ${WORKDIR}/piepatch/def
 	fi
 
+	BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}
+}
+
+# configure to build with the hardened GCC specs as the default
+make_gcc_hard() {
+	
 	# we want to be able to control the pie patch logic via something other
 	# than ALL_CFLAGS...
 	sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
@@ -618,38 +626,38 @@ do_gcc_PIE_patches() {
 -i ${S}/gcc/Makefile.in
 	fi
 
-	BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}
-}
-
-# configure to build with the hardened GCC specs as the default
-make_gcc_hard() {
-	# defaults to enable for all hardened toolchains
-	local gcc_hard_flags=-DEFAULT_RELRO -DEFAULT_BIND_NOW
-
-	if hardened_gcc_works ; then
-		einfo Updating gcc to use automatic PIE + SSP building ...
-		gcc_hard_flags+= -DEFAULT_PIE_SSP
-	elif hardened_gcc_works pie ; then
-		einfo Updating gcc to use automatic PIE building ...
-		ewarn SSP has not been enabled by default
-		gcc_hard_flags+= -DEFAULT_PIE
-	elif hardened_gcc_works ssp ; then
-		einfo Updating gcc to use automatic SSP building ...
-		ewarn PIE has not been enabled by default
-		gcc_hard_flags+= -DEFAULT_SSP
+	# defaults to enable for all toolchains
+	local gcc_hard_flags=
+	if use hardened ; then
+		if hardened_gcc_works ; then
+			einfo Updating gcc to use automatic PIE + SSP building ...
+			gcc_hard_flags+= -DEFAULT_PIE_SSP
+		elif hardened_gcc_works pie ; then
+			einfo Updating gcc to use automatic PIE building ...
+			ewarn SSP has not been enabled by default
+			gcc_hard_flags+= -DEFAULT_PIE
+		elif hardened_gcc_works ssp ; then
+			einfo Updating gcc to use automatic SSP building ...
+			ewarn PIE has not been enabled by default
+			gcc_hard_flags+= -DEFAULT_SSP
+		else
+			# do nothing if hardened is't supported, but don't die either
+			ewarn hardened is not supported for this arch in this gcc version
+			return 0
+		fi
+		# rebrand to make bug reports easier
+		BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
 	else
-		# do nothing if hardened isnt supported, but dont die either
-		ewarn hardened is not supported for this arch in this gcc version
-		ebeep
-		return 0
+		if hardened_gcc_works ssp ; then
+			einfo Updating gcc to use automatic SSP building ...
+			gcc_hard_flags+= -DEFAULT_SSP
+		fi
 	fi
 
 	sed -i \
 		-e /^HARD_CFLAGS = /s|=|= ${gcc_hard_flags} | \
 		${S}/gcc/Makefile.in || die
 
-	# rebrand to make bug reports easier
-	BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
 }
 
 # This is a historical wart.  The original Gentoo/amd64 port used:

Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Magnus Granberg]

torsdag 09 januari 2014 22.57.09 skrev  Pacho Ramos:
 El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió:
  Hi
  
  Some time ago we discussed that we should enable stack smashing
  (-fstack-protector) by default.  So we opened a bug to track this [1].
  The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
  ppc, ppc64 and arm will be affected by this change.
  
  You can turn off ssp by using the nossp USE flag or by adding
  -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
  patch as Debian/Ubuntu but with some Gentoo fixes.
  
  The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
  ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
  make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
  it on or off with hardened_gcc_works() that will make some sanity checks.
  
  /Magnus
 
 What are the advantages of disabling SSP to deserve that special
 handling via USE flag or easily disabling it appending the flag?
 
 Thanks a lot for the info :)

If you want Gcc not to build stuff with ssp as default you turn on the nossp 
flag and rebuild Gcc.

/Magnus

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

onsdag 11 september 2013 00.07.29 skrev  Ryan Hill:
 On Tue, 10 Sep 2013 18:41:34 -0400
 
 Richard Yao r...@gentoo.org wrote:
  A few thoughts:
  
  1. The kernel expects -fno-stack-protector to be the default. What will
  the effect be on kernel configuration once -fstack-protector is the
  default?
 The kernel has supported building with -fstack-protector since 2.6.19, (at
 least on x86/x86-64).  It's controlled by CONFIG_CC_STACKPROTECTOR and if
 it's disabled then -fno-stack-protector is explicitly added to the command
 line.
On Hardened we disable -fstack-protector* when building kernel and it is done 
with some gcc spec rules that we patch gcc with and it have been working long 
before gcc 4.X versions. It can be turned on with the kernel config option 
CONFIG_CC_STACKPROTECTOR.
/Magnus

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

onsdag 11 september 2013 04.49.55 skrev  Duncan:

 (Tho jer points out that the parisc arch, among others, won't work with
 that flag at all, and warns to that effect.  So I guess the patch will
 etiher be ifdeffed not to apply on such archs or will be conditionally
 applied in the first place.  The former is I believe preferred as
 conditional patching is considered subpar.)

We only enable -fstack-protector* if the arch is set in SSP_STABLE or 
SSP_UCLIBC_STABLE in the ebuild. For uclibc and ssp it need to be newer then 
.32 and have nptl enable.
/Magnus

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

måndag 09 september 2013 21.00.12 skrev  Ryan Hill:
 On Mon, 9 Sep 2013 08:21:35 -0400
 
 Rich Freeman ri...@gentoo.org wrote:
  On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill dirtye...@gentoo.org wrote:
   So does anyone have any objections to making -fstack-protector the
   default?
   Now is the time to speak up.
  
  So, in this world of all-or-nothing we want people who realize that
  100% protection might not be possible to raise an objection so that we
  end up with 0% protection instead?
 
 No, all I've heard so far is support and wanted to give anyone with an
 opposing viewpoint a chance to speak up.  I support it, but if there are
 any problems we might run into it's best we know about them beforehand, no?
  I wasn't looking for a reason to veto it.
 
  Why not just do the sensible thing (IMHO) and make it a default, and
  then if it doesn't work for an individual package deal with it on an
  individual basis?  We already encourage maintainers to try to get
  custom CFLAGS to work when practical, but when not practical we filter
  them.  I don't see stack protection as any different.  If there is a
  fix, then fix it, and if not, then disable it.  I don't see a lack of
  stack-protection as a reason to keep something out of the tree.
 
 Rich, that's exactly what I'm saying.
 
 We have to make an effort to fix things properly, like we do with any
 supported feature.  That's something I see as one of the key strengths of
 this group we have.  Obviously there are cases where a fix isn't possible
 (glibc and gcc itself are prime examples) and we need to disable it. 
 That's fine.  But we need to discourage people sweeping problems under the
 rug because they're inconvenient, especially when those problems may
 indicate security issues.
 
 I'm just trying to set proper expectations - that this change may break
 people's packages, and they may have to do some work to find out why and how
 to fix it.  I don't like creating more work for people, so I want to be
 sure there is consensus on this first.  So far it sounds like there is.

I did build most of the packages (~14000 packages) in tree when we move from 
gcc 3.X to 4.X with stack protection and some packages didn't work but we fix 
it or added work work arounds to them.  So in short most of the package work 
is allready done. 
/Magnus

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?

[Magnus Granberg]

tisdag 03 september 2013 22.41.14 skrev  Alan McKinnon:

 I *do* like colorized text on my terminal, but I do believe we ought to
 keep defaults sane - the minimum that could possibly work. Everything
 extra should be optional

What about NOCOLOR=false in make.conf see man make.conf for more info.
/Magnus

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Magnus Granberg]

fredag 21 oktober 2011 15.25.54 skrev  Duncan:
 Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:
  On Thursday 20 October 2011 23:20:35 Duncan wrote:
  Magnus G suggests possibly adding PIE to amd64, which is already PIC,
  
  this isn't quite right.  amd64 shared objects (i.e. libraries) are PIC.
  the applications are not.
 
 Thanks for the correction.  I knew the library think but supposed that
 was the difference between PIC/PIE, the E/executable for executables
 only, the more generic C/code for the feature applied to shared objects.
 
 Seems there's a bit more to it than that.  Thanks again, I can look it up
 now that I know to do so.
 
  usually these packages are multimedia related.  like ffmpeg iirc.  so i
  think the impact is much greater than your estimate here.

I don't have any probs with ffmpeg. We disable the asm stuff only for x86 and
not amd64 and that is the case on alot of the multimedia related packages.
Most problem we have now is the packages in app-emulation

 I figured mm, but also assumed strip-flags-like exceptions (probably
 controlled via USE flag) for packages where the default was really
 costly.  But now that I think of it, implementing that as arch defaults
 while allowing overrides isn't quite the simple matter it is for user-set
 CFLAGS, etc, and strip-flags, etc.
We allready use pic USE flag, filter-flags -fPIE or gcc-specs-pie to disable 
or do stuff so the package works.

 
 I assume it can still be done, but am not in a position to estimate
 whether it'd be worth the cost to implement.
 
  What about x32, tho?  Does it get PIC by default too
  
  x32 is same as x86_64 wrt PIC
 
 Good to know.  Thanks.

/Magnus

Re: [gentoo-dev] Moving more hardening features to default?

[Magnus Granberg]

torsdag 20 oktober 2011 13.17.33 skrev  Mike Frysinger:
 On Thursday 20 October 2011 12:47:27 Rich Freeman wrote:
  I was trying to draw a contrast between passive things like
  stack-protection and things that really get in your face like MAC.
 
 the trouble was in the context quoting then ... it sounded like you were
 proposing PaX by default
 
 i am a fan of things that just work though which is why i was happy to
 merge the fortify source code.  most of that checking is done at compile
 time, so the runtime overhead is generally small.  and in terms of packages
 that did break, it was (more often than not) because they were broken
 already but we never noticed.
 -mike

Hi

Debian has start to add some hardened features but take a look at ubuntu
https://wiki.ubuntu.com/Security/Features

Adding ssp support to main would not be a problem for most package works with 
it. We use same patch as ubuntu's toolchain to enable ssp, but we enable 
-fstack-protector-all instead of -fstack-protector.  You will, however, have 
some performance penalty enabling it.

Adding PIE to main is much harder than ssp.  On x86 it will have a high 
performance penalty and a lot of trouble with asm code.  The only arch I would 
add PIE on is amd64 where it will have only a minor performance penalty and we 
already have shared libs compile with PIC.  The biggest problem we have with 
PIE on amd64 is asm code in the apps where upstream is not that interested in 
making the asm PIC aware.  It hards to keep the patches up to date when they 
are not maintained upstream.

There are about 30 packages which have problems with PIE.  We either add patch 
to these or else use filter-flags on them.

my 2c
/Magnus (Zorry)

Re: [gentoo-dev] Re: News item for hardened profile about gcc.

[Magnus Granberg]

On Sunday 24 October 2010 10.04.34 Kfir Lavi wrote:
 On Sun, Oct 24, 2010 at 3:34 AM, Duncan 1i5t5.dun...@cox.net wrote:
  Magnus Granberg posted on Sun, 24 Oct 2010 03:01:40 +0200 as excerpted:
   Display-If-Install: sys-devel/gcc-4.4
  
  Typo:
  
  Display-If-Installed:
   ^^
  
  Meanwhile, the title reflects hardened profiles, but the updated
  conditions aren't viewed only on hardened.  The no-support-for-gcc-4
  policy would seem reasonable for most profiles (don't know about the
  exotic archs).  Either the title should be updated to reflect that it
  applies in general (not just on hardened), or the condition to display
  only on hardened should be maintained.  Either way, making it clearer in
  the body as well would be wise, so people seeing it only on hardened (if
  it applies only to them, for example) will have less chance of missing
  that, if they have regular installs as well.
  
  But I don't remember whether multiple conditions are ANDed or ORed; they
  should be ANDed here, if it's to apply to ONLY hardened with gcc-4.4
  installed.
  
  --
  Duncan - List replies preferred.   No HTML msgs.
  Every nonfree program has a lord, a master --
  and if you use the program, he is your master.  Richard Stallman
 
 Hi all,
 After reading this post I went to wikipedia to read about  the SSP.
 http://en.wikipedia.org/wiki/Buffer_overflow_protection
 At the paragraph GCC Stack-Smashing Protector (ProPolice), its written
 
 It was implemented as a patch to GCC 3.x; a less intrusive
 reimplementation is included in the GCC 4.1 release. Currently, SSP is
 standard in OpenBSD, FreeBSD (since 8.0), Ubuntu (since 8.04 LTS[3]),
 and DragonFly BSD. It is also available in NetBSD (enabled by default
 on x86), Debian and Gentoo, disabled by default.
 
 Now this should be changed, if the SSP flag is becoming default.
 
 Regards,
 Kfir
Updated the news item.
Thanks for the notes Duncan.
@Kfir  It is only the hardened gcc that have the SSP enable as default.
We can add that Gentoo (Hardened) have it enable.

/Magnus
/Magnus
Title: Info about GCC on Hardened profiles
Author: Magnus Granberg zo...@gentoo.org
Content-Type: text/plain
Posted: 2010-10-27
Revision: 3
News-Item-Format: 1.0
Display-If-Installed: sys-devel/gcc-4.4 and hardened

GCC 4.4.4-r2 is now stable in the hardened profiles (on x86 and
amd64 as of 2010-10-24, other architectures will follow later).
Starting from this version, SSP support is enabled by default for the
architectures it is supported on (namely x86, amd64, ppc, ppc64 and
arm). Previously, GCC 4.3.4 had SSP support but it was not enabled
by default.

Older GCC versions in the hardened profiles, such as the
GCC 3.x series will be obsoleted, problems arising on those versions,
but not applying to GCC 4.4.4-r2 will not be fixed, so please update
to the new version.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: News item for hardened profile about gcc.

[Magnus Granberg]

On Sunday 24 October 2010 12.04.13 Ulrich Mueller wrote:
  On Sun, 24 Oct 2010, Magnus Granberg wrote:
  Display-If-Installed: sys-devel/gcc-4.4 and hardened
 
 If I understand portage's logic correctly, then this header will not
 work. But you can use Display-If-Installed for the dependency atom and
 Display-If-Profile for the profile. Headers of different type will be
 linked by a logical and.
 
  Revision: 3
 
 This should still be 1. Revision should be increased only for changes
 to an already committed news item, not during discussion.
 
 Ulrich
Updated
Thanks Ulrich for the notes.

/Magnus
Title: Info about GCC on Hardened profiles
Author: Magnus Granberg zo...@gentoo.org
Content-Type: text/plain
Posted: 2010-10-27
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-devel/gcc-4.4
Display-If-Profile: hardened/linux

GCC 4.4.4-r2 is now stable in the hardened profiles (on x86 and
amd64 as of 2010-10-24, other architectures will follow later).
Starting from this version, SSP support is enabled by default for the
architectures it is supported on (namely x86, amd64, ppc, ppc64 and
arm). Previously, GCC 4.3.4 had SSP support but it was not enabled
by default.

Older GCC versions in the hardened profiles, such as the
GCC 3.x series will be obsoleted, problems arising on those versions,
but not applying to GCC 4.4.4-r2 will not be fixed, so please update
to the new version.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] News item for hardened profile about gcc.

[Magnus Granberg]

On Sunday 24 October 2010 19.00.44 7v5w7go9ub0o wrote:
 On 10/23/10 20:28, Magnus Granberg wrote:
  Hi
  
  Was thinking to post a news item for the hardened profile about the
  new GCC 4.4.4-r2  that have been stabled on x86 and amd64.
 
 Thank you for this milestone!
 
 We have enable SSP support by default on this and on newer versions
 for arches where it is supported...
 
 As I read the above quote, 4.4.5 and 4.5.x also have SSP support enabled by
 default; is this what was meant?
 
 Thanks Again
Yes it what it says.
/Magnus

[gentoo-dev] News item for hardened profile about gcc.

[Magnus Granberg]

Hi

Was thinking to post a news item for the hardened profile about the new GCC 
4.4.4-r2  that have been stabled on x86 and amd64.

Hardened at gentoo.org
/Magnus (Zorry) 
Title: Info on GCC 4.4.4-r2 and GCC 3.X on Hardened profiles
Author: Magnus Granberg zo...@gentoo.org
Content-Type: text/plain
Posted: 2010-10-27
Revision: 1
News-Item-Format: 1.0
Display-If-Profile: hardened/linux

You may have noticed that GCC 4.4.4-r2 has gone stable on x86 and
amd64. The other archs will follow later. We have enable SSP support
by default on this and on newer versions for arches where it is
supported, namely on x86, amd64, ppc, ppc64 and arm. The previous
version GCC 4.3.4 had SSP, but it was not enabled by default.
Older gcc's like 3.X versions will be obsoleted and we will not fix
any bugs that work on GCC-4.4.4-r2 or newer, but fail with gcc 3.X.

Re: [gentoo-dev] Re: News item for hardened profile about gcc.

[Magnus Granberg]

On Sunday 24 October 2010 02.44.00 Diego Elio Pettenò wrote:
 Il giorno dom, 24/10/2010 alle 02.28 +0200, Magnus Granberg ha scritto:
  You may have noticed that GCC 4.4.4-r2 has gone stable on x86 and
  amd64. The other archs will follow later. We have enable SSP support
  by default on this and on newer versions for arches where it is
  supported, namely on x86, amd64, ppc, ppc64 and arm. The previous
  version GCC 4.3.4 had SSP, but it was not enabled by default.
  Older gcc's like 3.X versions will be obsoleted and we will not fix
  any bugs that work on GCC-4.4.4-r2 or newer, but fail with gcc 3.X.
 
 I'd suggest updating it to
 
 Display-If-Installed: sys-devel/gcc-4.4
 
 GCC 4.4.4-r2 is now stable (on x86 and amd64 as of 2010-10-24, other
 architectures will follow later). Starting from this version, SSP
 support is enabled by default for the architectures it is supported on
 (namely x86, amd64, ppc, ppc64 and arm). Previously, GCC 4.3.4 had SSP
 support but it was not enabled by default.
 
 Older GCC versions, such as the GCC 3.x series will be obsoleted;
 problems arising on those versions, but not applying to GCC 4.4.4-r2
 will not be fixed, so please update to the new version.
Thanks for the notes
Have updated the news item with that changes.

/Magnus (Zorry)
Title: Info on GCC 4.4.4-r2 and GCC 3.X on Hardened profiles
Author: Magnus Granberg zo...@gentoo.org
Content-Type: text/plain
Posted: 2010-10-27
Revision: 1.1
News-Item-Format: 1.0
Display-If-Install: sys-devel/gcc-4.4

GCC 4.4.4-r2 is now stable (on x86 and amd64 as of 2010-10-24, other
architectures will follow later). Starting from this version, SSP
support is enabled by default for the architectures it is supported on
(namely x86, amd64, ppc, ppc64 and arm). Previously, GCC 4.3.4 had SSP
support but it was not enabled by default.

Older GCC versions, such as the GCC 3.x series will be obsoleted;
problems arising on those versions, but not applying to GCC 4.4.4-r2
will not be fixed, so please update to the new version.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] suspicious code snipped in gcc-4.5* ebuilds

[Magnus Granberg]

On Tuesday 05 October 2010 18.52.29 Petteri Räty wrote:
 On 10/05/2010 02:32 PM, Paweł Hajdan, Jr. wrote:
  I was just looking at some random ebuilds recently, and noticed this
  snippet in gcc-4.5* ebuilds:
  
  SSP_STABLE=amd64 x86 ppc ppc64 arm
  # uclibc need tls and nptl support for SSP support
  SSP_UCLIBC_STABLE=
  
  Please note how the #-starting comment is inside the SSP_STABLE variable
  declaration. It looks very obvious when seen in a syntax-coloring editor.
  
  I'm not sure if it breaks, as uclibc, need, tls etc. are not valid
  arch names, but it's still probably not intended.
 
 Open a bug?
 
 Regards,
 Petteri
allready fixed in cvs and it was not intended.
/Magnus

Re: [gentoo-dev] Is Gentoo a Phoenix?

[Magnus Granberg]

lördag 03 april 2010 12.19.19 skrev Tobias Scherbaum:
   - hardened-sources are nowadays only available in an experimental
   overlay, lots of users keep asking what's happening to the
   hardened-sources on both the -dev but also the -hardened mailinglist.
   Yeah, we do have people working on hardened stuff, but if people just
   take what's happening in the portage tree they might think that the
   hardened stuff they're relying on for their business isn't supported
   any longer.
 
  With Zorry we just got a new recruit for working on hardened things,
  especially toolchain. It's not as dead as you make it sound ...
 
 Good to see there's something happening in hardened - but still, the
 user outside of Gentoo still only is seeing: Oh, no hardened-sources
 update for nearly a year.
 
How long did it take for Hardened GCC to move to 4.X?  And we are still 
lacking SSP support in the tree. We have lost almost all dev's in the herd the 
past years.  As for hardened-sources we are working on it but that work has 
not hit the tree yet and that not a good situation. It will hit the tree soner 
or later. We work on our free time to and we don't have all the free time in 
the world to work on it. There is a long todo list. It is very time comsuming 
work on the toolchain, kernel, docs, bugs, recruit and help users at the same 
time. As tree dev that do all the work but we have users and some devs that 
help out too and that we are thankful for ther help. Hopefully we have 
something on the  hardened-sources after next meeting. 

@ Paweł Hajdan, Jr. you could ask in hardened-ker...@gentoo.org what thay need 
for help or join #gentoo-hardened @ freenode.net
And the hardened-sources in the hardened-development overlay have some 
regreesions that we are working on to fix.
Sorry if i bing roude.

Hardened at gentoo.org
Magnus Granberg (Zorry) zo...@gentoo.org

Re: [gentoo-dev] Re: gcc 4.3.2 security updates

[Magnus Granberg]

On Sunday 11 January 2009 09.39.08 Mike Frysinger wrote:
 On Saturday 10 January 2009 23:52:15 Magnus Granberg wrote:
  On Sunday 11 January 2009 04.26.00 Mike Frysinger wrote:
   On Saturday 10 January 2009 19:03:17 Ryan Hill wrote:
On Sat, 10 Jan 2009 16:22:50 -0500 Mike Frysinger wrote:
 not to be out done, gcc-4.3.2-r3 will include changes like some
 other distros are now carrying:
  - the -Wformat-security flag is enabled by default
  - the -D_FORTIFY_SOURCE=2 flag is enabled by default

 if you dont want this stuff, you can use the flag
 -Wno-format-security and the flag -U_FORTIFY_SOURCE respectively
   
I'm really hoping this isn't a stable candidate. :P
  
   gcc-4.3.2-r0 is still the stable candidate.  nothing has changed.
 
  Any patches ready?

 patches for what ?
 -mike

For the FORTIFY and Wformat thing but i will see when it hit the tree.

[gentoo-dev] Re: gcc 4.3.2 security updates

[Magnus Granberg]

On Sunday 11 January 2009 01.06.45 Ciaran McCreesh wrote:
 On Sat, 10 Jan 2009 18:03:17 -0600

 Ryan Hill dirtye...@gentoo.org wrote:
  I'm really hoping this isn't a stable candidate. :P

 Is an earlier gcc 4.3 a stable candidate, or have those plans been
 abandoned?

 (I'm wondering whether it's worth the pain of dealing with 4.1's lack
 of tr1 regex support...)

We will get more bugs if we enable FORTIFY_SOURCE for the stable canididet of 
gcc 4.3 like /usr/include/bits/fcntl2.h:51: error: call 
to '__open_missing_mode' declared with attribute error: open with O_CREAT in 
second argument needs 3 arguments
GLIBC won't even compile with it.
/Zorry

Re: [gentoo-dev] Re: gcc 4.3.2 security updates

[Magnus Granberg]

On Sunday 11 January 2009 04.26.00 Mike Frysinger wrote:
 On Saturday 10 January 2009 19:03:17 Ryan Hill wrote:
  On Sat, 10 Jan 2009 16:22:50 -0500 Mike Frysinger wrote:
   not to be out done, gcc-4.3.2-r3 will include changes like some other
   distros are now carrying:
- the -Wformat-security flag is enabled by default
- the -D_FORTIFY_SOURCE=2 flag is enabled by default
  
   if you dont want this stuff, you can use the flag
   -Wno-format-security and the flag -U_FORTIFY_SOURCE respectively
 
  I'm really hoping this isn't a stable candidate. :P

 gcc-4.3.2-r0 is still the stable candidate.  nothing has changed.
 -mike

Any patches ready?
/Zorry