Date: Mon, 06 Oct 2014 11:36:45 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com, rgerhards@...adiscon.com Subject: Re: vulnerability in rsyslog On 06/10/14 08:34, Rainer Gerhards wrote: > Sorry, it looks like I don't understand your question. I think the clarification Sven is asking for is a statement like this (I'm deliberately using imaginary version numbers which do not resemble rsyslog's actual 7.x versions, to make it clear that I'm not making a statement about this particular rsyslog vuln): """ Releases 1.2.x < 1.2.4, 1.3.x < 1.3.7 and 1.4.x < 1.4.1 are vulnerable unless the vendor-supplied patch is applied. Releases < 1.2, >= 1.2.4, >= 1.3.7 and >= 1.4.1 are not vulnerable. """ In most projects' version numbering practices: * a version (release) is a fixed point that can never change (so if 1.2.3 is vulnerable to CVE-1066-1234 it will always be vulnerable to CVE-1066-1234) * a stable release series or stable branch can have later versions that are intended to supersede an earlier version completely, while having minimal changes to fix serious bugs (so the upstream project can address CVE-1066-1234 by releasing 184.108.40.206 or 1.2.4) * alternatively, the upstream project can release recommended patches to be applied by sysadmins or vendors, which might be labelled "1.2.3 patch 1" or something if the project is particularly formal, or might just be identified by git/svn/etc. commit ID * even if 1.2.3 is vulnerable and always will be, a downstream vendor like Debian or Red Hat might release a derived version like 1.2.3-4+deb7u5 which incorporates the recommended patch from the upstream project, or a patch from the vendor or a third party, and so is not vulnerable Regards, S
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.