Re: [gentoo-qa] Re: [gentoo-dev] Portage to die on sure-enough _FORTIFY_SOURCE overflows

[Mike Frysinger]

On Tuesday, September 28, 2010 15:33:10 Alec Warner wrote:
> On Tue, Sep 28, 2010 at 2:43 AM, Diego Elio Pettenò wrote:
> > since the last time I asked Zac about this it came back to bite me[1]
> > this time I'm going to send the announce to the list first, and if
> > nobody can actually come up with a good reason not to, I'm going to ask
> > Zac tomorrow to re-enable the feature.
> >
> > What is this about? Portage already reports some of the overflow
> > warnings coming from the glibc fortified sources (-D_FORTIFY_SOURCE=2
> > -O2 — enabled since gcc 4.3.3-r1 and even stronger with gcc 4.5 and
> > glibc 2.12+, afaict), but they really are divided into two categories:
> >
> > - might overflow (depends on combination of parameters and variables the
> > compiler can't completely untangle);
> > - _will_ overflow (whenever that code path is hit, an overflow will
> > happen).
> >
> > The former we should highlight but not die upon; the latter, though...
> >
> > As Mike and me expressed on the linked bug, code that is built with that
> > warning is code that is going to crash as surely as
> >
> > char *foo = NULL;
> > foo[3] = 'a';
> >
> > which could result in nasty surprises for users (see [2] for the whole
> > reasoning).
> >
> > Now, we've not seen "proper" false positives (in the Portage sense I
> > mean — because even if the C library hits a false positive, it _will_
> > crash with an abort() from its own code!), but Kumba pointed me at a
> > case that wasn't entirely clear, and took a bit of detective work to
> > track down [3] so you could have users report issues you cannot easily
> > identify or reproduce. I cannot make promises, but if all else fail I'll
> > see to be around to help you with those cases.
> >
> > So if you want to have your say, gentoo-qa is there for that.
>
> So do you expect:
>
> 1. Developers to fix these bugs?
> 2. Report them upstream?
> 3. Remove packages?
>
> Its not clear to me what your purpose is.  It is likely that many
> developers will be unable to do 1.  Does that concern you?  Should
> developers ask QA for help on packages?

developers are expected to get their package fixed.  how they get that done is 
up to them.

as Diego said, this isnt a matter of "i see a compile warning, so lets abort 
the install".  the code in question _will_ call abort() all by itself if you 
attempt to execute it.
-mike