Le Tue, May 01, 2012 at 05:22:34PM -0700, Russ Allbery a écrit :
>
> See, for example, the --help output of any recent configure script:
>
> | Some influential environment variables:
> | CC C compiler command
> | CFLAGS C compiler flags
> | LDFLAGS linker flags, e.g. -L if
Charles Plessy writes:
> This said, the point that I want to make, is that we switched from a
> situation where the actual communication channel between our and
> upstreams makefile was C(XX)FLAGS, to a situation where CPPFLAGS and
> LDFLAGS also got some data input in by our toolchain. If there
Le Mon, Apr 30, 2012 at 03:46:51PM -0700, Russ Allbery a écrit :
>
> Most C programs use Autoconf in my experience. I know that scientific
> software often doesn't, but I think scientific software is the significant
> outlier in that respect.
I see... That probably explains everything. My expe
* Charles Plessy [120430 16:26]:
> If people who are interested by improving our dozens of thousands upstream
> makefiles could spend time forwarding patches upstream by themselves, that
> would be appreciated. I have a hard time finding convincing words when I
> think
> the patch is borderline
Charles Plessy writes:
> all our packages include a way to pass build flags to the upstream build
> system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.
> It would have been trivial to pass the hardening flags automatically
> through the same communication channel.
I don't und
Le Mon, Apr 30, 2012 at 08:15:35AM -0700, Russ Allbery a écrit :
> Charles Plessy writes:
>
> > The problem is: who wants to support what and what for ? I thought that
> > the release goal was to harden Debian, not to fine-grain makefiles in
> > general.
>
> > What I see here is a system that i
Charles Plessy writes:
> The problem is: who wants to support what and what for ? I thought that
> the release goal was to harden Debian, not to fine-grain makefiles in
> general.
> What I see here is a system that is generous of other people's time.
I would have assumed you would just add CPP
Le Mon, Apr 30, 2012 at 10:46:57AM +0200, Bernhard R. Link a écrit :
> * Charles Plessy [120430 04:31]:
> >
> > When we need to modify a large number of packages in order to propagate a
> > change, isn't this meaning that we are not picking the most efficient
> > defaults ?
>
> As I wrote again,
* Charles Plessy [120430 04:31]:
> Sorry to rant again, but am I the only one thinking that we are in most of the
> case wasting everybody's time by not simply passing all the hardening flags by
> default in CFLAGS ? In my experience (and I maintain more than 100 packages),
> it is extremely rare
Le Thu, Mar 08, 2012 at 12:26:46AM +0900, Charles Plessy a écrit :
>
> Thanks (and thanks Cyril) for the hint. Still there are two things
> I do not understand:
>
> - Why and when it is a problem to add preprocessor flags in CFLAGS.
>
> - Why we chose the solution that require more extensive
* Charles Plessy [120307 16:27]:
> Thanks (and thanks Cyril) for the hint. Still there are two things
> I do not understand:
>
> - Why and when it is a problem to add preprocessor flags in CFLAGS.
Becuase CFLAGS is not meant for preprocessor flags. Adding stuff in
unexpected places might break
Charles Plessy schrieb:
> Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit :
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> Since it will be almost impossible to convert all packages before
>> Wheezy freezes, a specific sub-group of packages receives targeted
>> attention:
>>
>
Le Wed, Mar 07, 2012 at 01:05:50AM +0100, Arno Töll a écrit :
>
> On 07.03.2012 00:58, Charles Plessy wrote:
> > Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in
> > addition to CPPFLAGS ?
>
> Actually dpkg did in 1.16.1 which was reverted later (for good
> reasons). See #643632 for
Charles Plessy (07/03/2012):
> But my main question is the following:
>
> In another bug, the problem is that CPPFLAGS is ignored in upstream's
> makefile. I understand that the semantics of CFLAGS and CPPFLAGS are
> not the same, but I also note that a large number of our upstreams are
> not ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Charles,
On 07.03.2012 00:58, Charles Plessy wrote:
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in
> addition to CPPFLAGS ?
Actually dpkg did in 1.16.1 which was reverted later (for good
reasons). See #643632 for details.
You ca
Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit :
> -BEGIN PGP SIGNED MESSAGE-
>
> Since it will be almost impossible to convert all packages before
> Wheezy freezes, a specific sub-group of packages receives targeted
> attention:
>
> * All packages, which have had a
Kees Cook writes:
> I'm not sure -- I'd like it out of hardening-includes just so that the
> whole hardening-wrapper source package can be deprecated, but lintian
> needs to have a Depend on whatever ships hardening-check. I think it
> might be rather extreme to have lintian depend on devscripts,
On Fri, Mar 02, 2012 at 07:25:25PM +0100, Moritz Mühlenhoff wrote:
> Kees Cook schrieb:
> > In the mean time, I'll continue to work on the crappy
> > heuristic checks. ;)
>
> Shall we move hardening-check to devscripts, now that
> dpkg-buildflags slowly trickles into standard Debian
> developme
On Fri, Mar 02, 2012 at 07:41:25PM +0100, Julian Taylor wrote:
> On 03/02/2012 05:53 PM, Kees Cook wrote:
> > On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
> >> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> >>> Kees Cook writes:
> >>>
> Speaking to the false p
On 03/02/2012 05:53 PM, Kees Cook wrote:
> On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
>> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
>>> Kees Cook writes:
>>>
Speaking to the false positives problem, I've discussed with some people
the idea of having b
Kees Cook schrieb:
> In the mean time, I'll continue to work on the crappy
> heuristic checks. ;)
Shall we move hardening-check to devscripts, now that
dpkg-buildflags slowly trickles into standard Debian
development practice?
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-
Russ Allbery schrieb:
> Paul Wise writes:
>
>> Personally I think this is completely the wrong approach to take for
>> compiler hardening flags. The flags should be enabled by default in
>> upstream GCC and disabled by upstream software where they result in
>> problems.
>
> If we had followed tha
Nikolaus Rath schrieb:
> Moritz Muehlenhoff writes:
>> Hi,
>>
>> dpkg-buildflags allows a uniform setting of default build flags for
>> code written in C and C++.
>>
>> Using dpkg-build-flags in your rules files has a number of benefits:
>>[...]
>
> Should packages of Python extensions written i
On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> > Kees Cook writes:
> >
> > > Speaking to the false positives problem, I've discussed with some people
> > > the idea of having build flags be included in some sort of EL
On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> Kees Cook writes:
>
> > Speaking to the false positives problem, I've discussed with some people
> > the idea of having build flags be included in some sort of ELF
> > comment-like area that can be examined. That way it's becomes tri
On Thu, Mar 01, 2012 at 12:01:12PM -0400, Joey Hess wrote:
> Moritz Muehlenhoff wrote:
> > 1. dpkg-buildflags exports hardened build flags. These hardened build
> > flags mitigate/nullify some classes of security vulnerabilities and
> > make exploitation of security problems more difficult.
>
> A
Kees Cook writes:
> Speaking to the false positives problem, I've discussed with some people
> the idea of having build flags be included in some sort of ELF
> comment-like area that can be examined. That way it's becomes trivial to
> answer "how was this built?" and all these crapy heuristic che
On Thu, Mar 01, 2012 at 06:16:14PM +0100, Arno Töll wrote:
> On 01.03.2012 18:11, Arno Töll wrote:
> > The vanilla kernel itself has some ASLR protection as well,
> > although I think it is still not enabled by default in Debian (and
> > is perhaps
> ^^
>
> KiBi corre
On Thu, Mar 01, 2012 at 09:44:15AM +0100, Thijs Kinkhorst wrote:
> On Thu, March 1, 2012 00:11, Patrick Matthaei wrote:
> > Am 29.02.2012 23:57, schrieb Russ Allbery:
> >> Patrick Matthaei writes:
> >>
> >>> I fully support the hardening goal.
> >>> May it be an option to add lintian errors (also
Stefano Zacchiroli writes:
> On Wed, Feb 29, 2012 at 02:57:03PM -0800, Russ Allbery wrote:
>> It's a little tricky because hardening-check is prone to false
>> positives (through no fault of its own; it's just a limitation of what
>> one can check).
> Didn't lintian split severity/certainty leve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01.03.2012 18:11, Arno Töll wrote:
> The vanilla kernel itself has some ASLR protection as well,
> although I think it is still not enabled by default in Debian (and
> is perhaps
^^
KiBi corrected me. It is, sorry.
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 01.03.2012 17:01, Joey Hess wrote:
> Moritz Muehlenhoff wrote:
>> 1. dpkg-buildflags exports hardened build flags. These hardened
>> build flags mitigate/nullify some classes of security
>> vulnerabilities and make exploitation of security prob
Moritz Muehlenhoff wrote:
> 1. dpkg-buildflags exports hardened build flags. These hardened build
> flags mitigate/nullify some classes of security vulnerabilities and
> make exploitation of security problems more difficult.
At least temporarily. Are you familiar with Return Oriented Programming
Moritz Muehlenhoff writes:
> Hi,
>
> dpkg-buildflags allows a uniform setting of default build flags for
> code written in C and C++.
>
> Using dpkg-build-flags in your rules files has a number of benefits:
>[...]
Should packages of Python extensions written in C and using
distribute/setuptools
On Thu, March 1, 2012 00:11, Patrick Matthaei wrote:
> Am 29.02.2012 23:57, schrieb Russ Allbery:
>> Patrick Matthaei writes:
>>
>>> I fully support the hardening goal.
>>> May it be an option to add lintian errors (also non-fatal errors on
>>> ftp-master side) about missing-hardening-build in the
On Wed, Feb 29, 2012 at 02:57:03PM -0800, Russ Allbery wrote:
> It's a little tricky because hardening-check is prone to false
> positives (through no fault of its own; it's just a limitation of what
> one can check).
Didn't lintian split severity/certainty levels for use cases like this
one?
--
On 01/03/12 03:09, Jerome BENOIT wrote:
I've written conversion documentation in the Debian Wiki to provide
central step-by-step documentation:
http://wiki.debian.org/HardeningWalkthrough
In this wiki, we read: ``If you upgrade to compat level 9''
How can we safely upgrade from 8 to 9 ?
I've written conversion documentation in the Debian Wiki to provide
central step-by-step documentation:
http://wiki.debian.org/HardeningWalkthrough
In this wiki, we read: ``If you upgrade to compat level 9''
How can we safely upgrade from 8 to 9 ?
Thanks in advance,
Jerome
--
To UNSUBSC
Paul Wise writes:
> Personally I think this is completely the wrong approach to take for
> compiler hardening flags. The flags should be enabled by default in
> upstream GCC and disabled by upstream software where they result in
> problems.
If we had followed that approach, we wouldn't have been
Hi,
On Wed, Feb 29, 2012 at 9:23 PM, Paul Wise wrote:
> Personally I think this is completely the wrong approach to take for
> compiler hardening flags. The flags should be enabled by default in
> upstream GCC and disabled by upstream software where they result in
> problems. The compiler hardeni
Personally I think this is completely the wrong approach to take for
compiler hardening flags. The flags should be enabled by default in
upstream GCC and disabled by upstream software where they result in
problems. The compiler hardening flags have been tested over N years
by RHEL, Fedora, Ubuntu,
Am 29.02.2012 23:57, schrieb Russ Allbery:
> Patrick Matthäi writes:
>
>> I fully support the hardening goal.
>> May it be an option to add lintian errors (also non-fatal errors on
>> ftp-master side) about missing-hardening-build in the future?
>
>> It may be too late for Wheezy to force packag
Patrick Matthäi writes:
> I fully support the hardening goal.
> May it be an option to add lintian errors (also non-fatal errors on
> ftp-master side) about missing-hardening-build in the future?
> It may be too late for Wheezy to force packages to build with hardened
> build flags, but we shoul
Am 29.02.2012 22:52, schrieb Moritz Muehlenhoff:
> The most important reason for dpkg-buildflags is [1.] :
> One of the Wheezy release goals is to build as many packages as
> possible with a hardened toolchain by means of dpkg-buildflags:
> http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuild
44 matches
Mail list logo
