headers
Paul Wise | 1 Mar 2012 01:23
Picon
Favicon
Gravatar

Re: Enabling hardened build flags for Wheezy

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, Gentoo and probably others. The approach
Debian is taking (as opposed to Red Hat, Fedora, Ubuntu etc) means
that software compiled outside of the packaging system will not
benefit from the compiler's hardening flags. Doing it in this way also
violates our social contract.

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Permalink | Reply | 3 comments |
headers
Fernando Lemos | 1 Mar 2012 01:28
Picon

Re: Enabling hardened build flags for Wheezy

Hi,

On Wed, Feb 29, 2012 at 9:23 PM, Paul Wise <pabs <at> debian.org> 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 hardening flags have been tested over N years
> by RHEL, Fedora, Ubuntu, Gentoo and probably others. The approach
> Debian is taking (as opposed to Red Hat, Fedora, Ubuntu etc) means
> that software compiled outside of the packaging system will not
> benefit from the compiler's hardening flags. Doing it in this way also
> violates our social contract.

Not sure it's a good idea to reignite this, specially this late into
the Wheezy development cycle (and specially in debian-devel). This has
already been discussed in detail:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Regards,
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Mar 2012 01:35
Picon
Favicon

Re: Enabling hardened build flags for Wheezy

Paul Wise <pabs <at> debian.org> 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 able to use PIE,
since it breaks various programs if you enable it this way and isn't as
widely tested.  But because we developed a generic framework to add and
remove hardening flags that the maintainer has control over and can easily
tweak for the needs of their packages, I was able to enable PIE on nearly
all of my packages and just omit it for those packages it broke.

I think that clearly demonstrates the major advantages of having an
extensible framework that we can continue to adjust and modify going
forward.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>
Permalink | Reply | 1 comment |
headers
Jerome BENOIT | 1 Mar 2012 03:09

Re: Enabling hardened build flags for Wheezy


>
> 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
Permalink | Reply | 1 comment |
headers
Miles Bader | 1 Mar 2012 06:55
Picon
Gravatar

Re: Bug#661565: ITP: nyancat -- Terminal-based Pop Tart Cat animation

Jonathan McCrohan <jmccrohan <at> gmail.com> writes:
> I certainly don't plan on uploading and abandoning this package, but
> given the high level of opposition to this ITP, guess there is little
> point pursuing it.

There's some whining by the usual sorts, but why would anyone pay
attention to them...?

-miles

--

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.
Permalink | Reply | 0 comments |
headers
Jerome BENOIT | 1 Mar 2012 07:16

Re: Enabling hardened build flags for Wheezy


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 ?

The beginning of the answer can be found in debhelper(1).

Sorry for the noise,
Jerome

>
> Thanks in advance,
> Jerome
>
>
Permalink | Reply | 0 comments |
headers
Andrew Shadura | 1 Mar 2012 09:05
Picon
Favicon
Gravatar

Re: ITP: oqapy -- Photographic workflow application

Hello,

On Thu, 01 Mar 2012 06:42:24 +0100
Vincent Vande Vyvre <vincent.vandevyvre <at> swing.be> wrote:

> This application is designed to handle large collection of image files
> with full support of metadatas include geolocalisation.

Sorry for this little pedantism, but data is already plural (singular
form is datum), so no need to add 's' to the word to pluralise it.

Please report this to upstream as I see they use 'datas' at least at
their website.

--

-- 
WBR, Andrew
Permalink | Reply | 2 comments |
headers
Stefano Zacchiroli | 1 Mar 2012 09:08
Picon
Favicon

Re: Enabling hardened build flags for Wheezy

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?

--

-- 
Stefano Zacchiroli     zack <at> {upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......    <at> zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »
Permalink | Reply | 1 comment |
headers
Francois Marier | 1 Mar 2012 09:08
Picon
Favicon
Gravatar

Bug#661771: ITP: node-libravatar -- libravatar library for NodeJS

Package: wnpp
Severity: wishlist
Owner: Francois Marier <francois <at> debian.org>

* Package name    : node-libravatar
  Version         : 1.1.0
  Upstream Author : Francois Marier <francois <at> libravatar.org>
* URL             : https://github.com/fmarier/node-libravatar
* License         : MIT
  Programming Lang: Javascript
  Description     : libravatar library for NodeJS
Permalink | Reply | 1 comment |
headers
Goswin von Brederlow | 1 Mar 2012 09:41
Picon

Re: upstart: please update to latest upstream version

Marco d'Itri <md <at> linux.it> writes:

> On Feb 29, Russell Coker <russell <at> coker.com.au> wrote:
>
>> One thing that would be really convenient in such situations is the ability to 
>> have the old and new versions of the package installed such that the new 
>> version would run the old version if appropriate.
> Yes. Except that this was not applicable to udev because the 
> system-facing interfaces too were different between different versions.
> As I already explained countless times.
> Next?

What would have been trivial to do is to have udev-x.y packages that are
coinstallable and a simple udev binary that checks the kernel version
and features and then starts the right udev-x.y. Examples for this kind
of flexibility would be xen or lvm.

But then again udev also broke udev rules so you had to change the
conffiles to match the udev version. But at least that only affected
some rules, not all of udev, and was a more gradual effect.

But you've all heard that before and (you and upstream) still ignore it
and udev will keep having these problems and keep sucking for that
reason. By now I don't expect that to change. So EOD.

Udevs shortcommings weren't the point anyway, just an example to show
that we shouldn't have all of Debian depend solely on something similar.

MfG
        Goswin
(Continue reading)

Permalink | Reply | 0 comments |

Gmane