On 22/06/10 15:59, C Anthony Risinger wrote:
On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee<dpmcgee@gmail.com> wrote:
On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger<anthony@extof.me> wrote:
On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae<allan@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