On Mon, Jun 21, 2010 at 6:53 PM, Andres P <aepd87@gmail.com> wrote:
On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@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