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

[C Anthony Risinger]

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.

C Anthony