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

[Dan McGee]

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.

-Dan