[Open-scap] evr

[Simon Lukasik]

On 11/07/2013 01:59 PM, Maria Kedovskaya wrote:
> Hello,
> I have a question about parameter evr in dpkginfo_state and rpminfo_state. In 
> one of this states there is such caption: /This represents the epoch, version, 
> and release fields as a single version string. It has the form 
> "EPOCH:VERSION-RELEASE". Note that a null epoch (or '(none)' as returned by rpm) 
> is equivalent to '0' and would hence have the form 0:VERSION-RELEASE. 
> Comparisons involving this datatype should follow the algorithm of librpm's 
> rpmvercmp() function. 
> (/http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/linux-definitions-schema.html). 
> My question is if absence of colon is should be replaced with 0: in both of this 
> states in openscap. Now I have such result: for example the test which check 
> that httpd package is less than or equal to 17.0.7+build1-0ubuntu0.12.04.1 
> returns true if httpd version 1:24.1.0+build1-0ubuntu0.12.04.1 is installed.
> 

Hello Maria,

I have a (hopefully good) news for you. As a result of another issue, I
have improved comparisons of EntityStateEVRStringType. That patch can be
found at


https://git.fedorahosted.org/cgit/openscap.git/commit/?id=714b301a8c1bf2fe93b7a5ecf6d8b07ac85a7d77

Sorry for typos in the patch documentation, it was late night. :)

This change in OpenSCAP was needed to reflect RedHat_RPMVersionCompare
as described in the thread Dan pointed-out.


http://making-security-measurable.1364806.n2.nabble.com/Final-word-on-RPM-version-comparisions-td20286.html

Hence, now openscap now assumes epoch=0 even in the content (in
dpkginfo_state and rpminfo_state). Please note that when collecting
items from the system, OpenSCAP has been always assuming the epoch=0.

I have also included a test to our internal test-suite which asserts for
that. I used exact same epoch/version/number as you. That test can be
found at


https://git.fedorahosted.org/cgit/openscap.git/commit/?id=aa37617f7b495b29840162c5775ee20598fca0ff

But still, please note that this change has a potential for hiding a
vulnerabilities. As I pointed out in this thread on 11/08/2013.

Best regards,

-- 
Simon Lukasik
Security Technologies