[Open-scap] Fwd: evr

[Haynes, Dan]

Thanks for the feedback Simon.  I will bring this up on the oval-developer-list and see what others think about making the epoch mandatory and possibly adding a schematron rule to make sure the epoch is explicitly stated (even if on the system it is left off and should be assumed to be "0").

Thanks,

Danny

>-----Original Message-----
>From: Simon Lukasik [mailto:slukasik at redhat.com]
>Sent: Friday, November 15, 2013 9:42 AM
>To: Haynes, Dan; Maria Kedovskaya; open-scap-list at redhat.com
>Subject: Re: [Open-scap] Fwd: evr
>
>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