FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 11-24-2008, 01:11 AM
James Westby
 
Default FORTIFY build failures (was: conntrack 1:0.9.7-1.1ubuntu1 (Accepted))

On Sun, 2008-11-23 at 17:47 -0800, Kees Cook wrote:
> Well, as you say, it's always different. The way I've tended to triage
> them is:

This is good advice, do you think it should go on the wiki page?

> - If there is are obvious error handlers in near-by code, emulate them.
> That's what I did in my suggested patch to conntrack[1]. This is,
> obviously, the preferred method of dealing with it.

Yes, I've unfortunately tended to look at packages that have next to no
error handling, so there is no existing code to go off.

> - If there isn't an obvious way to handle the error, then stubbing out an
> empty handler is the next way to go -- fundamentally, this doesn't
> improve (or weaken) the quality of the code -- ignoring the return code
> is what's already happening, so this doesn't change anything. However,
> what it _does_ do, is allows the FORTIFY option to still be enabled,
> which means the program will gain the run-time FORTIFY protections.

Ah, there are runtime protections as well as code checks, now I see the
point.

> Also, in situations where you've had to disable FORTIFY (#3, #4), please
> document the issue in the CompilerFlags[3] wiki page (preferably also with
> a bug).
>
> And thank you to everyone who has had to deal with the fall-out of these
> options! I know they can really be an annoyance, but taken as a whole,
> Ubuntu is far better off with these flags enabled, and everyone's code
> quality goes up.

Thank you for taking leadership in these issues. While the benefits are
clear it's hard to enable things like this because of exactly these
sorts of issues, so I appreciate your effort to improve things.

Thanks,

James



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-24-2008, 03:42 PM
Kees Cook
 
Default FORTIFY build failures (was: conntrack 1:0.9.7-1.1ubuntu1 (Accepted))

Hi,

On Mon, Nov 24, 2008 at 02:11:59AM +0000, James Westby wrote:
> On Sun, 2008-11-23 at 17:47 -0800, Kees Cook wrote:
> > Well, as you say, it's always different. The way I've tended to triage
> > them is:
>
> This is good advice, do you think it should go on the wiki page?

Probably -- I'm not sure how it should be incorporated, though. The
CompilerFlags page currently has a case-by-case analysis of each kind of
warning the flags might throw. What do you think would make a readable
arrangement? I was pondering a separate page for triage, or maybe just a
stand-alone section on the page?

> Ah, there are runtime protections as well as code checks, now I see the
> point.

Right -- it basically replaces sprintf with snprintf, strcpy with strncpy,
and wraps things like 'read'. There are some situations (like the use of
"extern") that can't be checked at compile-time, etc.

-Kees

--
Kees Cook @outflux.net

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-24-2008, 03:48 PM
James Westby
 
Default FORTIFY build failures (was: conntrack 1:0.9.7-1.1ubuntu1 (Accepted))

On Mon, 2008-11-24 at 08:42 -0800, Kees Cook wrote:
> Hi,
>
> On Mon, Nov 24, 2008 at 02:11:59AM +0000, James Westby wrote:
> > On Sun, 2008-11-23 at 17:47 -0800, Kees Cook wrote:
> > > Well, as you say, it's always different. The way I've tended to triage
> > > them is:
> >
> > This is good advice, do you think it should go on the wiki page?
>
> Probably -- I'm not sure how it should be incorporated, though. The
> CompilerFlags page currently has a case-by-case analysis of each kind of
> warning the flags might throw. What do you think would make a readable
> arrangement? I was pondering a separate page for triage, or maybe just a
> stand-alone section on the page?

I think having a section at the end where we can collect advice on how
to deal with some of the failures that this causes would be good.

Thanks,

James


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-24-2008, 04:01 PM
Kees Cook
 
Default FORTIFY build failures (was: conntrack 1:0.9.7-1.1ubuntu1 (Accepted))

On Mon, Nov 24, 2008 at 04:48:29PM +0000, James Westby wrote:
> On Mon, 2008-11-24 at 08:42 -0800, Kees Cook wrote:
> > On Mon, Nov 24, 2008 at 02:11:59AM +0000, James Westby wrote:
> > > On Sun, 2008-11-23 at 17:47 -0800, Kees Cook wrote:
> > > > Well, as you say, it's always different. The way I've tended to triage
> > > > them is:
> > >
> > > This is good advice, do you think it should go on the wiki page?
> >
> > Probably -- I'm not sure how it should be incorporated, though. The
> > CompilerFlags page currently has a case-by-case analysis of each kind of
> > warning the flags might throw. What do you think would make a readable
> > arrangement? I was pondering a separate page for triage, or maybe just a
> > stand-alone section on the page?
>
> I think having a section at the end where we can collect advice on how
> to deal with some of the failures that this causes would be good.

Okay, I've shoved my original triage list in here (and cleaned it up a
little): https://wiki.ubuntu.com/CompilerFlags#Triage

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 08:00 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org