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

[Allan McRae]

On 22/06/10 15:59, C Anthony Risinger wrote:
> On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee<dpmcgee at gmail.com>  wrote:
>> On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger<anthony at extof.me>  wrote:
>>> On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae<allan at archlinux.org>  wrote:
>>>> On 22/06/10 12:07, C Anthony Risinger wrote:
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> Then you should probably move along...
>>>>
>>>>> find /var/abs -name *CVE*
>>>> /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
>>>> /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
>>>> /var/abs/extra/alpine/CVE-2008-5514.patch
>>>> /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
>>>> /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
>>>> /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
>>>> /var/abs/core/expat/CVE-2009-3720.patch
>>>> /var/abs/core/expat/CVE-2009-3560.patch
>>>>
>>>> and these are just the patches named for the security issue they fix.
>>>>
>>>> The point is that the developers around here already patch for security
>>>> issues.  The only change that I think that a security team will achieve is
>>>> to notify me (as a developer) of issues that I have overlooked on the
>>>> upstream mailing lists and file a bug report.  It is a bonus if the issue is
>>>> pre-analyzed for me and all relevant links supplied so I can assess it
>>>> quickly myself and release a fixed package if I deem that being suitable.
>>>
>>> indeed.  2007/8/9?  are these patches from years ago, for dead
>>> software (xmms?)?  i don't know the state of the others.
>>>
>>> alright, so you're patching stuff... why?  why are such old patches
>>> not in upstream?  if things were done appropriately there wouldn't be
>>> a need for intermediary patches because glaring security holes are
>>> quickly absorbed into upstream.  or... whats the deal here?  i don't
>>> get the need to carry these around.
>>>
>>> at any rate i don't agree with it but meh, i'm just a worker bee :-)
>>
>> Do you honestly think releasing software is that easy? It *sucks*. It
>> is the least enjoyable part of being an open-source developer.
>>
>> They probably are in upstream and they haven't done a release for some
>> very good raeson, or upstream is no longer well-maintained. Does that
>> mean we should leave people vulnerable because of some party line we
>> have? Heck no.
>
> hmm, so the fundamental problem is that the word 'upstream' implies a
> unity that does not exist.  at this point i would enter conversation
> about reconciling individual 'upstreams' to a common backend, such
> that distributions/contributors/users may immediately benefit from
> each others work; a p2p application and public software broadcasting
> framework upon which distributions could be founded...
>
> a different topic :-)
>
> i suppose...  unmaintained should have patches and very small, concise
> changes to poorly maintained, and maybe even _very_ few to regularly
> maintained.  yet, most security related alerts are for higher profile
> applications; a more immediate response i would think?
>
> i simply don't want to see a collective effort to preempt upstream; i
> prefer to manually digress from vanilla, and i'm probably a minority.
>

Not really.  We do like vanilla software and aim for that in our repos. 
  But it not an unbreakable rule.

What I would like to see one day is a header on all patches detailing 
where they come from and what they do.  Something like in Debian of LFS.

Allan