On 22/06/10 15:59, C Anthony Risinger wrote:
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.
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
