[arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.

[C Anthony Risinger]

On Mon, Jun 21, 2010 at 6:53 PM, Andres P <aepd87 at gmail.com> wrote:
> On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony at extof.me> wrote:
>> He said from git/svn... ie backporting, not contributing.
>>
>
> ...?
>
> Once they're in svn they're confined to abs? Besides, it's not like there's
> anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor
> Arch's svn repo, etc.
>
> Andres P

i'm not trying to discourage anyone from pursuing an 'arch security
team', or whatever you want to call it.  as someone who makes their
living writing softwares, you cannot just whip up comprehensive
patches for any old project; it takes a significant amount of time to
learn the codebase.

now the alternative; pulling in obscure fixes from here and there that
you don't even really understand to repair problems that may only
exist for a short while, or may not even been real problems is a
fool's errand.  how do you know _why_ upstream wrote the code the way
they did?  are you sure it's really a bug/hole?  are you sure when you
backport stuff from trunk/head you won't be introducing more/worse
holes?  are you sure the backported commit doesn't depend on other
commits that currently only exist in trunk?  do you trust other
distros, ie not authors, to make these decisions for you?

one of my favorite things about Arch is not just following the latest
releases of upstream, but trying to follow the latest _configuration_
of upstream as well.  no one knows a software's internals better than
the people who wrote it; let me decide how to make it fit in my
environment, because _i_ know that better.

dropping privileges and things like that _is_ good practice... but as
i said in the other thread: _ultimately_, security is the duty of
those deploying to production, not those writing software or packaging
it for a generic audience.  sure, you could run every application in
an LXC container by default with a private rootfs/namespaces, and slap
some smack policies or grsecurity or whatever fancy pants layers of
indirection you conceive... but should the other 99% of users have to
deal with that level of paranoia, and have to undo all that junk when
it's not what they need? no.

upstream may allow the ability to automatically run in a
chroot/container/etc., but it's never the default.  why?  it's not
their job to know how you intend to deploy.  it's not Arch's job
either.

my point of this ramble if there is one, is that personally, i don't
want _anyone_ other than upstream to make security decisions regarding
their software.  if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long.
even if an security hole is found i _don't_ want the fix to be
included by default, unless it came from upstream in the form of a new
release, which Arch would just pick up as usual.

thus, in my opinion, an 'arch security team' would be most effective
by limiting itself to:

1) alerting others that wish to be alerted of any
known/potential/outstanding holes
2) making sure upstream is aware, and getting an ETA of inclusion into mainline
3) adding many wiki pages on how to lock down daemons/applications +
best practices
4) making sane recommendations to the development team that does _not_
include patches of any kind or wild changes to default configurations

if they stick to that, i'm all about it; otherwise, they're just in the way.

C Anthony