public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Mol <mikemol@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
Date: Tue, 03 Jan 2017 11:09:48 -0500	[thread overview]
Message-ID: <2819995.c2USjTAJt6@mal> (raw)
In-Reply-To: <CAGfcS_nCMLKworigSJfWbJUEtc6i241BcPGFsesC=Uxyc_ySVA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4304 bytes --]

On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@gmail.com> wrote:
> > For security's sake, even mature software needs, at minimum, routine
> > auditing. Unless someone's doing that work, the package should be
> > considered for removal. (Call that reason #    π, in honor of TeX.)
> 
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit? 

Of course not. Full security audits are stupid expensive, be it in terms of 
money, time or labor. It Would Be Nice if they at least periodically got 
subjected to -Werror -Wall from time to time, or at least a linter check, or 
some tie-in to Coverity, with the results considered, but even that's going to 
be too much to ask an upstream to accept patches for.

Besides, there are going to be vulnerabilities that come from combinations of 
packages and their environments; something that's fine on x86 might have a 
critical vulnerability on arm. Something that's fine on x86_64 might have a bug 
that only presents itself in a constrained address space like x86. Something 
that's generally fine on its own might have a subtle bug that only manifests 
when a particular version of another package's headers are present at build 
time.

It's ludicrous to be absolutist about security. As I remarked to someone the 
other day, there are always more things to fix or secure than you'll have 
resources to follow though on. If someone one think a system is as secure as 
it can possibly be, then they're not as clever as they think they are.

> We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
> 
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.

I'm sure we all remember Heartbleed.

> 
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add,

Ideas like this is one reason I'm looking for a corpus of pros and cons for 
treecleaning. I don't see it as black and white. But having ideas like these 
brought up is at least useful.

> but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

I'm not trying to drive a "clean all the things" campaign. Rather, I'm 
principally interested in having a list of the standard arguments one way or 
another, for reference in the inevitable "why should this get cleaned up? It 
works." threads.

There's an old joke that goes something like this:

> Joe is going to his first comedian's convention. He's excited to see all 
> these funny people in person.

> The opening session begins with Robert, who gets up and says, "42!" Everyone 
> busts a gut laughing. Then Susan gets up and says, "73!" Again, everyone 
> laughs.

> Joe asks the guy next to him, "What's going on? I don't get it."

> "Oh, you see, everyone's heard all the same jokes over and over, so to save 
time, they reference them by number."

> "Ah! Let me give it a try."

> Joe stands up and says, "3!" Nobody laughs. Embarassed, Joe sits back down.

> "I don't understand," Joe says to the guy next to him. Why didn't anyone 
> laugh? Was 3 a poor joke?

> "Oh, no, 3 is fine, but the key is in the timing!"

Essentially, I'm looking for the joke book. Because these recurring threads 
would be a lot more interesting and less time-consuming and frictive if 
recurring material could be quickly identified and referenced. And then someone 
who still has a point to make can say, "Well, 3 is more important than 7, and 
here's why." And then have less spilling of words and boiling of blood 
irritating everyone and hardening positions before we get to consider 
something new.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2017-01-03 16:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-31 21:54 [gentoo-dev] Packages up for grabs due to retirement Thomas Kahle
2016-12-31 23:00 ` James Le Cuirot
2017-01-01  9:42   ` Thomas Kahle
2017-01-01  9:54     ` James Le Cuirot
2017-01-01  9:48 ` [gentoo-dev] " David Seifert
2017-01-01 10:08   ` Thomas Kahle
2017-01-01 17:16 ` [gentoo-dev] " Lars Wendler
2017-01-02 19:53   ` Brian Evans
2017-01-03  9:00     ` grozin
2017-01-03 11:05       ` Michał Górny
2017-01-03 14:14         ` Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement) Michael Mol
2017-01-03 14:24           ` Damien LEVAC
2017-01-03 14:57             ` Michael Mol
2017-01-03 15:10               ` Kristian Fiskerstrand
2017-01-03 17:10                 ` Matthew Thode
2017-01-03 15:11               ` Damien LEVAC
2017-01-03 17:07                 ` Matthew Thode
2017-01-03 15:12               ` M. J. Everitt
2017-01-03 15:23               ` Rich Freeman
2017-01-03 15:41                 ` Alice Ferrazzi
2017-01-03 16:59                   ` james
2017-01-03 16:09                 ` Michael Mol [this message]
2017-01-03 16:29                   ` Rich Freeman
2017-01-06  4:27                 ` Kent Fredric
2017-01-06 14:13                   ` Michael Mol
2017-01-06 20:51                     ` William L. Thomson Jr.
2017-01-06 15:01                   ` Rich Freeman
2017-01-07  2:51                     ` M. J. Everitt
2017-01-06 17:14                   ` Alec Warner
2017-01-06 17:26                     ` Rich Freeman
2017-01-06 20:46                     ` William L. Thomson Jr.
2017-01-17 12:45                       ` Daniel Campbell
2017-01-18  7:48                         ` Sam Jorna
2017-01-07  2:58                     ` M. J. Everitt
2017-01-07  2:47                   ` M. J. Everitt
2017-01-04 10:34             ` Thomas Kahle
2017-01-03 14:31         ` [gentoo-dev] Packages up for grabs due to retirement M. J. Everitt
2017-01-03 14:34           ` Damien LEVAC
2017-01-04  3:11             ` Mart Raudsepp
2017-01-06  4:33               ` Kent Fredric
2017-01-06  6:00           ` Daniel Campbell
2017-01-06  8:04             ` Mart Raudsepp
2017-01-03 11:14       ` Lars Wendler

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=2819995.c2USjTAJt6@mal \
    --to=mikemol@gmail.com \
    --cc=gentoo-dev@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