[Open-scap] Fwd: evr

[Simon Lukasik]

On 11/15/2013 01:28 AM, Haynes, Dan wrote:
> I looked into this a little bit and found this oval-developer-list thread (http://making-security-measurable.1364806.n2.nabble.com/Final-word-on-RPM-version-comparisions-td20286.html#a20288) where Javier, from Debian, said that if it was no epoch, “0” should be assumed.  However, it looks like the link he provided is no longer available.  I did a quick search and found this documentation (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version), which states:
> 
> “This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then theupstream_version may not contain any colons.  It is provided to allow mistakes in the version numbers of older versions of a package, and also a package's previous version numbering schemes, to be left behind.”
> 
> As a result, “0” should be assumed for the evr entity in dpkginfo_test too.  Since the evr entity in the linux-def:rpminfo_test has this documentation, we should probably update "evr_string" datatype documentation to reflect this information.  I have added the following OVAL Language tracker to update the documentation to reflect this here (https://github.com/OVALProject/Language/issues/175).  We may also want to add documentation stating that the “0” should be made explicit in content to guard against incorrect assumptions.  Does that seem reasonable?
> 
> Thanks,

Hello Dan,

I very well agree with your summary.

It would be great if OVAL XSD asserted for the epoch being present in
the content. The assumed 0 may not be what's content author intends.

Otherwise, OpenSCAP should include this assertion in upcoming oval-lint
tool.

Thanks!

-- 
Simon Lukasik
Security Technologies