On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee <dpmcgee@xxxxxxxxx> wrote: > On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger <anthony@xxxxxxxx> wrote: >> On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@xxxxxxxxxxxxx> 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
