public inbox for gentoo-qa@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: gentoo-qa@lists.gentoo.org
Subject: [gentoo-qa] Re: [gentoo-dev] Portage to die on sure-enough _FORTIFY_SOURCE overflows
Date: Tue, 28 Sep 2010 12:33:10 -0700	[thread overview]
Message-ID: <AANLkTi=iA=5pWDm3SQo2KRR_5GV6BNQaLdNDSOsFOxRB@mail.gmail.com> (raw)
In-Reply-To: <1285667008.13141.31.camel@yamato.local>

On Tue, Sep 28, 2010 at 2:43 AM, Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> Hi all,
>
> 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?

-A

>
> Thank you,
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=337031
> [2]
> http://blog.flameeyes.eu/2010/09/14/not-all-failures-are-caused-equal
> [3]
> http://blog.flameeyes.eu/2010/09/12/some-_fortify_source-far-fetched-warnings-are-funny
>
> --
> Diego Elio Pettenò — “Flameeyes”
> http://blog.flameeyes.eu/
>
> If you found a .asc file in this mail and know not what it is,
> it's a GnuPG digital signature: http://www.gnupg.org/
>
>
>
>



  reply	other threads:[~2010-09-28 19:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28  9:43 [gentoo-qa] Portage to die on sure-enough _FORTIFY_SOURCE overflows Diego Elio Pettenò
2010-09-28 19:33 ` Alec Warner [this message]
2010-09-28 22:35   ` [gentoo-qa] Re: [gentoo-dev] " Diego Elio Pettenò

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=iA=5pWDm3SQo2KRR_5GV6BNQaLdNDSOsFOxRB@mail.gmail.com' \
    --to=antarus@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=gentoo-qa@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox