Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

Danny Haynes
Administrator
Hi Jan,

I just looked into the bug issue tracker you created and it looks like you found my original post about why we made the change from minOccurs="0" to minOccurs="1" in the object.  I would just emphasize that this change was made in an update release (https://oval.mitre.org/language/about/versioning.html), which allows for changes that break backward compatibility, and had approval from the OVAL Board.  

Would it be possible to update the 5.10 content to include the following, prior to the filepath entity, to make it validate under both 5.10 and beyond?

  <name operation="pattern match"/>
  <epoch operation="pattern match"/>
  <version operation="pattern match"/>
  <release operation="pattern match"/>
  <arch operation="pattern match"/>

I suspect that you could potentially do this in an automated fashion.

Thanks,

Danny

>-----Original Message-----
>From: Jan Lieskovsky [mailto:[hidden email]]
>Sent: Friday, March 06, 2015 12:43 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
>Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object>
>minOccurs='1' change for epoch, version, release, and arch entities introduced in
>5.10.1 OVAL language version
>
>Hello folks,
>
>  based on the guidance:
>  [1] https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
>reporting-a-bug-or-getting-help
>
>how to report a bug against current version of the OVAL language standard
>I have filed the following bug for the OVAL Board's consideration:
>  [2] https://github.com/OVALProject/Language/issues/238
>
>Kindly review it && let me know if it's missing any official requirement(s)
>so they can be provided yet (mainly if the schema implementation change
>is required too).
>
>Thank you && Regards, Jan.
>--
>Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
>P.S.: The underlying issue has been originally brought to us by David Solin
>      for review. After testing && review we can confirm its presence and
>      therefore filed [2] request for the consideration of the change.
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-
>[hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

joval
This reminded me of issue #246 (which I just filed), which I believe may actually be a very similar case.

Personally, I don’t see anything wrong with object entities that have minOccurs=“0”.  From the perspective of a content author, it’s simpler than using a filter, and committing the entity is like a shorthand for the pattern match work-around.  Tools should be schema-aware, so I also don’t see why exactly this should be prohibited.

Regards,
—David Solin
[hidden email]



> On Mar 18, 2015, at 1:47 PM, Haynes, Dan <[hidden email]> wrote:
>
> Hi Jan,
>
> I just looked into the bug issue tracker you created and it looks like you found my original post about why we made the change from minOccurs="0" to minOccurs="1" in the object.  I would just emphasize that this change was made in an update release (https://oval.mitre.org/language/about/versioning.html), which allows for changes that break backward compatibility, and had approval from the OVAL Board.  
>
> Would it be possible to update the 5.10 content to include the following, prior to the filepath entity, to make it validate under both 5.10 and beyond?
>
>  <name operation="pattern match"/>
>  <epoch operation="pattern match"/>
>  <version operation="pattern match"/>
>  <release operation="pattern match"/>
>  <arch operation="pattern match"/>
>
> I suspect that you could potentially do this in an automated fashion.
>
> Thanks,
>
> Danny
>
>> -----Original Message-----
>> From: Jan Lieskovsky [mailto:[hidden email]]
>> Sent: Friday, March 06, 2015 12:43 PM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
>> Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object>
>> minOccurs='1' change for epoch, version, release, and arch entities introduced in
>> 5.10.1 OVAL language version
>>
>> Hello folks,
>>
>> based on the guidance:
>> [1] https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
>> reporting-a-bug-or-getting-help
>>
>> how to report a bug against current version of the OVAL language standard
>> I have filed the following bug for the OVAL Board's consideration:
>> [2] https://github.com/OVALProject/Language/issues/238
>>
>> Kindly review it && let me know if it's missing any official requirement(s)
>> so they can be provided yet (mainly if the schema implementation change
>> is required too).
>>
>> Thank you && Regards, Jan.
>> --
>> Jan iankko Lieskovsky / Red Hat Security Technologies Team
>>
>> P.S.: The underlying issue has been originally brought to us by David Solin
>>     for review. After testing && review we can confirm its presence and
>>     therefore filed [2] request for the consideration of the change.
>>
>> To unsubscribe, send an email message to [hidden email] with
>> SIGNOFF OVAL-DEVELOPER-LIST
>> in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-
>> [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

Martin Preisler
----- Original Message -----

> From: "David Solin" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 18, 2015 8:58:55 PM
> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object>
> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities
> introduced in 5.10.1 OVAL language versi
>
> This reminded me of issue #246 (which I just filed), which I believe may
> actually be a very similar case.
>
> Personally, I don’t see anything wrong with object entities that have
> minOccurs=“0”.  From the perspective of a content author, it’s simpler than
> using a filter, and committing the entity is like a shorthand for the
> pattern match work-around.  Tools should be schema-aware, so I also don’t
> see why exactly this should be prohibited.

+1

Supporting both minOccurs="0" and minOccurs="1" is most likely no added work
for tool authors.

--
Martin Preisler
Security Technologies | Red Hat, Inc.

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

joval
As an aside, the phrase below from my email should begin “omitting...”, not “committing...”.  (My wording was victimized by auto-correct).

—David Solin



> On Mar 18, 2015, at 4:18 PM, Martin Preisler <[hidden email]> wrote:
>
>>  committing the entity is like a shorthand for the
>> pattern match work-around

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

Jan Lieskovsky
In reply to this post by Danny Haynes
----- Original Message -----
> From: "Dan Haynes" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 18, 2015 7:47:42 PM
> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object>
> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities
> introduced in 5.10.1 OVAL language versi
>
> Hi Jan,

Hello Danny,

  thank you for your reply && review of the proposal.

>
> I just looked into the bug issue tracker you created and it looks like you
> found my original post about why we made the change from minOccurs="0" to
> minOccurs="1" in the object.

Correct. If I understood it right the main reason for introduction of that change
was to prevent cases when the pre OVAL-5.10.1 standard "it does open the
opportunity for content authors to create rpmverifyfile_objects and
rpmverifypackage_objects without any entities."

Therefore the 'minOccurs=1' requirement has been introduced to enforce directly
in the standard that the content will be written in such a way it won't cause
OVAL scanner tool to crash or consume extensive system resources & possibly hang.

I can understand this motivation. But the question I am trying to raise in ticket:
  [1] https://github.com/OVALProject/Language/issues/238

being if it was really necessary to introduce the 'minOccurs=1' requirement on
all of the 'name, epoch, version, release, and arch' entities. In other words
if it was not sufficient to enforce 'minOccurs=1' requirement to be present
in at least one of them. E.g. the requirement to state to define a valid
rpmverifyfile_object / rpmverifypackage_object the content needs to have at least
one of 'name, epoch, version, release, or arch' entities specified / present.

Yet in different way why it was not sufficient to place OR operator between
those five elements (e.g. name_is_present or epoch_is_present or version_is_present
or release_is_present or arch_is_present. At least one from all of these five
entities needs to be present in order the corresponding object to be considered
valid)? Instead of requiring all five of them (in some sort of the definition, e.g.
at least via pattern match to be present)? If I can use an analogy I would compare
with unix:file_object:
  [2] https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#file_object

For this object also 'filepath, path, filename' entities are required. But as far
as I can tell it's implemented / enforced in the way that under condition 'filepath'
element / entity is defined / present, 'path' and 'filename' entities don't need
to be. And vice versa, when 'path' and 'filename' entities are present (where 'filename'
can be specified via '<xsi:nil>'), 'filepath' doesn't need to be present any more.
In my understanding 'filepath' and 'path + filename' entities are alternative entity definitions
for unix:file_object.

The question is why rpmverifyfile_object and rpmverifypackage_object couldn't be defined
in the very same way (IOW an alternation operation to be put between the five entities
instead of strictly requiring all five of them to be present at least once in some form).

On the other hand I agree that to uniquely identify RPM package on the system to specify
just 'name', or just 'version', or 'arch' isn't sufficient. But if the content authors
wanted to uniquely identify particular RPM object on the system, they could still use
all five of the entities - they weren't forbidden to do that even with the pre OVAL 5.10.1
versions.

To summary I understand the motivation / effort the standard to enforce such requirements
so only valid objects would be collected on the system. But what I am wondering being
why it was necessary to require all five entities to be present rather to make them
alternative names / equivalents like it's done in unix:file_object definition / standard
specification.

>  I would just emphasize that this change was
> made in an update release
> (https://oval.mitre.org/language/about/versioning.html), which allows for
> changes that break backward compatibility, and had approval from the OVAL
> Board.

Agree here too. IOW I understand that in order the standard / specification
to evolve to meet changing requirements there need to be incompatible changes
present (there needs to be a way how to address the changing environment).
It was not meant as an argument why such a change shouldn't be introduced.
If I mentioned it in [1] ticket, it was just margin note (not a justification
why such change shouldn't be introduced). Sorry if the description in [1]
sounded / could be percepted in that way. The possible compatibility break
was not the primary concern.

>
> Would it be possible to update the 5.10 content to include the following,
> prior to the filepath entity, to make it validate under both 5.10 and
> beyond?
>
>   <name operation="pattern match"/>
>   <epoch operation="pattern match"/>
>   <version operation="pattern match"/>
>   <release operation="pattern match"/>
>   <arch operation="pattern match"/>
>
> I suspect that you could potentially do this in an automated fashion.

Yes, there's workaround how to make former OVAL 5.10 content to work
properly also with OVAL 5.10.1+ schemas. And we are actually using it
already.

The primary concern was different - as you list above the former OVAL 5.10
content to continue work properly also with OVAL 5.10.1+ schemas, multiple
'pattern match' operations need to be added for the case the content wants
to scan more than just a one concrete RPM package on the system. Since
'pattern match' is expensive operation, my primary concern was if there won't
be performance penalty (longer evaluation time for particular rule) just due
the need to introduce multiple 'pattern match' statements.

From what I was able to test (on the specific system + scanner + content combination)
the performance penalty doesn't seem to be that dramatic.

But having this testing data available I am not able to tell if the (in our case)
observed behaviour is just exceptional (the system doesn't have "too much" packages installed,
scanner is pretty well optimized, and the content doesn't utilize rpmverifyfile_object /
rpmverifypackage_objects OVAL objects in a way involving multiple system RPM packages
too much) or if this would be general case (in other words on every system with
every scanner, and every content introduction of this change when processing content
involving more than one RPM package the performance penalty won't be that much,
and therefore the OVAL 5.10.1+ is safe change to be enforced by the standard).

But from the quick (abstracting out from the the concrete ToE case) theoretic analysis
it implies to me that the enforcement to use four more 'pattern match' operations
to evaluate the same content (which previously required just one 'pattern match' operation)
in the case corresponding rpmverifyfile_object / rpmverifypackage_object OVAL objects
involve more than just concrete RPM package on the system, might lead to performance
penalty (longer rule evaluation effective time) in some cases / in some environments
(concrete system + scanner + content combination).

Unfortunately as already mentioned earlier I am not able to prove this performance penalty
is a real concern and how big in per cents (on the system + scanner + content combination
I was testing the performance penalty wasn't such a dramatic increase it wouldn't be
acceptable. Especially when this means now only valid rpmverifyfile_object / rpmverifypackage_object
OVAL objects can be collected on the system).

But I suppose there might be system + scanner + content combinations, where the OVAL 5.10.1+
'minOccurs=1' change will introduce performance penalty [longer evaluation time for selected
rules], and in these environments to support the OVAL 5.10.1+ change it won't be just question
of adding couple more of 'pattern match' statements, but might be also matter of additional
tasks like content rewrite or scanner optimization.

Therefore to avoid this my proposal is either to revert the change introduced in [1], or
modify the current 'name, epoch, version, release, and arch' behaviour to make the requirement
to require at least one of the five entities to be present (IOW make them alternatives),
not all of them to be present simultaneously.

Thank you && Regards, Jan.
--
Jan iankko Lieskosvky / Red Hat Security Technologies Team

>
> Thanks,
>
> Danny
>
> >-----Original Message-----
> >From: Jan Lieskovsky [mailto:[hidden email]]
> >Sent: Friday, March 06, 2015 12:43 PM
> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
> >Revert the <rpmverifyfile_object> minOccurs='1' and
> ><rpmverifypackage_object>
> >minOccurs='1' change for epoch, version, release, and arch entities
> >introduced in
> >5.10.1 OVAL language version
> >
> >Hello folks,
> >
> >  based on the guidance:
> >  [1] https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
> >reporting-a-bug-or-getting-help
> >
> >how to report a bug against current version of the OVAL language standard
> >I have filed the following bug for the OVAL Board's consideration:
> >  [2] https://github.com/OVALProject/Language/issues/238
> >
> >Kindly review it && let me know if it's missing any official requirement(s)
> >so they can be provided yet (mainly if the schema implementation change
> >is required too).
> >
> >Thank you && Regards, Jan.
> >--
> >Jan iankko Lieskovsky / Red Hat Security Technologies Team
> >
> >P.S.: The underlying issue has been originally brought to us by David Solin
> >      for review. After testing && review we can confirm its presence and
> >      therefore filed [2] request for the consideration of the change.
> >
> >To unsubscribe, send an email message to [hidden email] with
> >SIGNOFF OVAL-DEVELOPER-LIST
> >in the BODY of the message.  If you have difficulties, write to
> >OVAL-DEVELOPER-
> >[hidden email].
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

joval
Or… we could keep the minOccurs=“1” requirement for the name entity, and allow minOccurs=“0” for e, v, r and arch … which I guess is how I thought it worked in OVAL 5.10.1 (without troubling to actually look at ‘name’).

David Solin
[hidden email]



> On Mar 19, 2015, at 5:32 AM, Jan Lieskovsky <[hidden email]> wrote:
>
> ----- Original Message -----
>> From: "Dan Haynes" <[hidden email]>
>> To: [hidden email]
>> Sent: Wednesday, March 18, 2015 7:47:42 PM
>> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object>
>> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities
>> introduced in 5.10.1 OVAL language versi
>>
>> Hi Jan,
>
> Hello Danny,
>
>  thank you for your reply && review of the proposal.
>
>>
>> I just looked into the bug issue tracker you created and it looks like you
>> found my original post about why we made the change from minOccurs="0" to
>> minOccurs="1" in the object.
>
> Correct. If I understood it right the main reason for introduction of that change
> was to prevent cases when the pre OVAL-5.10.1 standard "it does open the
> opportunity for content authors to create rpmverifyfile_objects and
> rpmverifypackage_objects without any entities."
>
> Therefore the 'minOccurs=1' requirement has been introduced to enforce directly
> in the standard that the content will be written in such a way it won't cause
> OVAL scanner tool to crash or consume extensive system resources & possibly hang.
>
> I can understand this motivation. But the question I am trying to raise in ticket:
>  [1] https://github.com/OVALProject/Language/issues/238
>
> being if it was really necessary to introduce the 'minOccurs=1' requirement on
> all of the 'name, epoch, version, release, and arch' entities. In other words
> if it was not sufficient to enforce 'minOccurs=1' requirement to be present
> in at least one of them. E.g. the requirement to state to define a valid
> rpmverifyfile_object / rpmverifypackage_object the content needs to have at least
> one of 'name, epoch, version, release, or arch' entities specified / present.
>
> Yet in different way why it was not sufficient to place OR operator between
> those five elements (e.g. name_is_present or epoch_is_present or version_is_present
> or release_is_present or arch_is_present. At least one from all of these five
> entities needs to be present in order the corresponding object to be considered
> valid)? Instead of requiring all five of them (in some sort of the definition, e.g.
> at least via pattern match to be present)? If I can use an analogy I would compare
> with unix:file_object:
>  [2] https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#file_object
>
> For this object also 'filepath, path, filename' entities are required. But as far
> as I can tell it's implemented / enforced in the way that under condition 'filepath'
> element / entity is defined / present, 'path' and 'filename' entities don't need
> to be. And vice versa, when 'path' and 'filename' entities are present (where 'filename'
> can be specified via '<xsi:nil>'), 'filepath' doesn't need to be present any more.
> In my understanding 'filepath' and 'path + filename' entities are alternative entity definitions
> for unix:file_object.
>
> The question is why rpmverifyfile_object and rpmverifypackage_object couldn't be defined
> in the very same way (IOW an alternation operation to be put between the five entities
> instead of strictly requiring all five of them to be present at least once in some form).
>
> On the other hand I agree that to uniquely identify RPM package on the system to specify
> just 'name', or just 'version', or 'arch' isn't sufficient. But if the content authors
> wanted to uniquely identify particular RPM object on the system, they could still use
> all five of the entities - they weren't forbidden to do that even with the pre OVAL 5.10.1
> versions.
>
> To summary I understand the motivation / effort the standard to enforce such requirements
> so only valid objects would be collected on the system. But what I am wondering being
> why it was necessary to require all five entities to be present rather to make them
> alternative names / equivalents like it's done in unix:file_object definition / standard
> specification.
>
>> I would just emphasize that this change was
>> made in an update release
>> (https://oval.mitre.org/language/about/versioning.html), which allows for
>> changes that break backward compatibility, and had approval from the OVAL
>> Board.
>
> Agree here too. IOW I understand that in order the standard / specification
> to evolve to meet changing requirements there need to be incompatible changes
> present (there needs to be a way how to address the changing environment).
> It was not meant as an argument why such a change shouldn't be introduced.
> If I mentioned it in [1] ticket, it was just margin note (not a justification
> why such change shouldn't be introduced). Sorry if the description in [1]
> sounded / could be percepted in that way. The possible compatibility break
> was not the primary concern.
>
>>
>> Would it be possible to update the 5.10 content to include the following,
>> prior to the filepath entity, to make it validate under both 5.10 and
>> beyond?
>>
>>  <name operation="pattern match"/>
>>  <epoch operation="pattern match"/>
>>  <version operation="pattern match"/>
>>  <release operation="pattern match"/>
>>  <arch operation="pattern match"/>
>>
>> I suspect that you could potentially do this in an automated fashion.
>
> Yes, there's workaround how to make former OVAL 5.10 content to work
> properly also with OVAL 5.10.1+ schemas. And we are actually using it
> already.
>
> The primary concern was different - as you list above the former OVAL 5.10
> content to continue work properly also with OVAL 5.10.1+ schemas, multiple
> 'pattern match' operations need to be added for the case the content wants
> to scan more than just a one concrete RPM package on the system. Since
> 'pattern match' is expensive operation, my primary concern was if there won't
> be performance penalty (longer evaluation time for particular rule) just due
> the need to introduce multiple 'pattern match' statements.
>
> From what I was able to test (on the specific system + scanner + content combination)
> the performance penalty doesn't seem to be that dramatic.
>
> But having this testing data available I am not able to tell if the (in our case)
> observed behaviour is just exceptional (the system doesn't have "too much" packages installed,
> scanner is pretty well optimized, and the content doesn't utilize rpmverifyfile_object /
> rpmverifypackage_objects OVAL objects in a way involving multiple system RPM packages
> too much) or if this would be general case (in other words on every system with
> every scanner, and every content introduction of this change when processing content
> involving more than one RPM package the performance penalty won't be that much,
> and therefore the OVAL 5.10.1+ is safe change to be enforced by the standard).
>
> But from the quick (abstracting out from the the concrete ToE case) theoretic analysis
> it implies to me that the enforcement to use four more 'pattern match' operations
> to evaluate the same content (which previously required just one 'pattern match' operation)
> in the case corresponding rpmverifyfile_object / rpmverifypackage_object OVAL objects
> involve more than just concrete RPM package on the system, might lead to performance
> penalty (longer rule evaluation effective time) in some cases / in some environments
> (concrete system + scanner + content combination).
>
> Unfortunately as already mentioned earlier I am not able to prove this performance penalty
> is a real concern and how big in per cents (on the system + scanner + content combination
> I was testing the performance penalty wasn't such a dramatic increase it wouldn't be
> acceptable. Especially when this means now only valid rpmverifyfile_object / rpmverifypackage_object
> OVAL objects can be collected on the system).
>
> But I suppose there might be system + scanner + content combinations, where the OVAL 5.10.1+
> 'minOccurs=1' change will introduce performance penalty [longer evaluation time for selected
> rules], and in these environments to support the OVAL 5.10.1+ change it won't be just question
> of adding couple more of 'pattern match' statements, but might be also matter of additional
> tasks like content rewrite or scanner optimization.
>
> Therefore to avoid this my proposal is either to revert the change introduced in [1], or
> modify the current 'name, epoch, version, release, and arch' behaviour to make the requirement
> to require at least one of the five entities to be present (IOW make them alternatives),
> not all of them to be present simultaneously.
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskosvky / Red Hat Security Technologies Team
>
>>
>> Thanks,
>>
>> Danny
>>
>>> -----Original Message-----
>>> From: Jan Lieskovsky [mailto:[hidden email]]
>>> Sent: Friday, March 06, 2015 12:43 PM
>>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>> Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
>>> Revert the <rpmverifyfile_object> minOccurs='1' and
>>> <rpmverifypackage_object>
>>> minOccurs='1' change for epoch, version, release, and arch entities
>>> introduced in
>>> 5.10.1 OVAL language version
>>>
>>> Hello folks,
>>>
>>> based on the guidance:
>>> [1] https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
>>> reporting-a-bug-or-getting-help
>>>
>>> how to report a bug against current version of the OVAL language standard
>>> I have filed the following bug for the OVAL Board's consideration:
>>> [2] https://github.com/OVALProject/Language/issues/238
>>>
>>> Kindly review it && let me know if it's missing any official requirement(s)
>>> so they can be provided yet (mainly if the schema implementation change
>>> is required too).
>>>
>>> Thank you && Regards, Jan.
>>> --
>>> Jan iankko Lieskovsky / Red Hat Security Technologies Team
>>>
>>> P.S.: The underlying issue has been originally brought to us by David Solin
>>>     for review. After testing && review we can confirm its presence and
>>>     therefore filed [2] request for the consideration of the change.
>>>
>>> To unsubscribe, send an email message to [hidden email] with
>>> SIGNOFF OVAL-DEVELOPER-LIST
>>> in the BODY of the message.  If you have difficulties, write to
>>> OVAL-DEVELOPER-
>>> [hidden email].
>>
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

Jan Lieskovsky
----- Original Message -----
> From: "David Solin" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, March 19, 2015 1:23:42 PM
> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object>
> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities
> introduced in 5.10.1 OVAL language versi
>
> Or… we could keep the minOccurs=“1” requirement for the name entity, and
> allow minOccurs=“0” for e, v, r and arch …

That might be another alternative how to solve this, yes. And maybe the least
invasive one.

> which I guess is how I thought it
> worked in OVAL 5.10.1 (without troubling to actually look at ‘name’).

Yes. I also assumed prior to 5.10.1 version 'name' was required to be present
/ defined at least once. But that doesn't seem to be the case. According to:
  https://oval.mitre.org/language/version5.10/ovaldefinition/documentation/linux-definitions-schema.html#rpmverifyfile_object

it seems in that version all five (n, v, e, r & a) are allowed not to be
present at all (so the original doubt of possibility to define invalid objects is
valid).

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

>
> David Solin
> [hidden email]
>
>
>
> > On Mar 19, 2015, at 5:32 AM, Jan Lieskovsky <[hidden email]> wrote:
> >
> > ----- Original Message -----
> >> From: "Dan Haynes" <[hidden email]>
> >> To: [hidden email]
> >> Sent: Wednesday, March 18, 2015 7:47:42 PM
> >> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version
> >> 5.11.1: Revert the <rpmverifyfile_object>
> >> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for
> >> epoch, version, release, and arch entities
> >> introduced in 5.10.1 OVAL language versi
> >>
> >> Hi Jan,
> >
> > Hello Danny,
> >
> >  thank you for your reply && review of the proposal.
> >
> >>
> >> I just looked into the bug issue tracker you created and it looks like you
> >> found my original post about why we made the change from minOccurs="0" to
> >> minOccurs="1" in the object.
> >
> > Correct. If I understood it right the main reason for introduction of that
> > change
> > was to prevent cases when the pre OVAL-5.10.1 standard "it does open the
> > opportunity for content authors to create rpmverifyfile_objects and
> > rpmverifypackage_objects without any entities."
> >
> > Therefore the 'minOccurs=1' requirement has been introduced to enforce
> > directly
> > in the standard that the content will be written in such a way it won't
> > cause
> > OVAL scanner tool to crash or consume extensive system resources & possibly
> > hang.
> >
> > I can understand this motivation. But the question I am trying to raise in
> > ticket:
> >  [1] https://github.com/OVALProject/Language/issues/238
> >
> > being if it was really necessary to introduce the 'minOccurs=1' requirement
> > on
> > all of the 'name, epoch, version, release, and arch' entities. In other
> > words
> > if it was not sufficient to enforce 'minOccurs=1' requirement to be present
> > in at least one of them. E.g. the requirement to state to define a valid
> > rpmverifyfile_object / rpmverifypackage_object the content needs to have at
> > least
> > one of 'name, epoch, version, release, or arch' entities specified /
> > present.
> >
> > Yet in different way why it was not sufficient to place OR operator between
> > those five elements (e.g. name_is_present or epoch_is_present or
> > version_is_present
> > or release_is_present or arch_is_present. At least one from all of these
> > five
> > entities needs to be present in order the corresponding object to be
> > considered
> > valid)? Instead of requiring all five of them (in some sort of the
> > definition, e.g.
> > at least via pattern match to be present)? If I can use an analogy I would
> > compare
> > with unix:file_object:
> >  [2]
> >  https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#file_object
> >
> > For this object also 'filepath, path, filename' entities are required. But
> > as far
> > as I can tell it's implemented / enforced in the way that under condition
> > 'filepath'
> > element / entity is defined / present, 'path' and 'filename' entities don't
> > need
> > to be. And vice versa, when 'path' and 'filename' entities are present
> > (where 'filename'
> > can be specified via '<xsi:nil>'), 'filepath' doesn't need to be present
> > any more.
> > In my understanding 'filepath' and 'path + filename' entities are
> > alternative entity definitions
> > for unix:file_object.
> >
> > The question is why rpmverifyfile_object and rpmverifypackage_object
> > couldn't be defined
> > in the very same way (IOW an alternation operation to be put between the
> > five entities
> > instead of strictly requiring all five of them to be present at least once
> > in some form).
> >
> > On the other hand I agree that to uniquely identify RPM package on the
> > system to specify
> > just 'name', or just 'version', or 'arch' isn't sufficient. But if the
> > content authors
> > wanted to uniquely identify particular RPM object on the system, they could
> > still use
> > all five of the entities - they weren't forbidden to do that even with the
> > pre OVAL 5.10.1
> > versions.
> >
> > To summary I understand the motivation / effort the standard to enforce
> > such requirements
> > so only valid objects would be collected on the system. But what I am
> > wondering being
> > why it was necessary to require all five entities to be present rather to
> > make them
> > alternative names / equivalents like it's done in unix:file_object
> > definition / standard
> > specification.
> >
> >> I would just emphasize that this change was
> >> made in an update release
> >> (https://oval.mitre.org/language/about/versioning.html), which allows for
> >> changes that break backward compatibility, and had approval from the OVAL
> >> Board.
> >
> > Agree here too. IOW I understand that in order the standard / specification
> > to evolve to meet changing requirements there need to be incompatible
> > changes
> > present (there needs to be a way how to address the changing environment).
> > It was not meant as an argument why such a change shouldn't be introduced.
> > If I mentioned it in [1] ticket, it was just margin note (not a
> > justification
> > why such change shouldn't be introduced). Sorry if the description in [1]
> > sounded / could be percepted in that way. The possible compatibility break
> > was not the primary concern.
> >
> >>
> >> Would it be possible to update the 5.10 content to include the following,
> >> prior to the filepath entity, to make it validate under both 5.10 and
> >> beyond?
> >>
> >>  <name operation="pattern match"/>
> >>  <epoch operation="pattern match"/>
> >>  <version operation="pattern match"/>
> >>  <release operation="pattern match"/>
> >>  <arch operation="pattern match"/>
> >>
> >> I suspect that you could potentially do this in an automated fashion.
> >
> > Yes, there's workaround how to make former OVAL 5.10 content to work
> > properly also with OVAL 5.10.1+ schemas. And we are actually using it
> > already.
> >
> > The primary concern was different - as you list above the former OVAL 5.10
> > content to continue work properly also with OVAL 5.10.1+ schemas, multiple
> > 'pattern match' operations need to be added for the case the content wants
> > to scan more than just a one concrete RPM package on the system. Since
> > 'pattern match' is expensive operation, my primary concern was if there
> > won't
> > be performance penalty (longer evaluation time for particular rule) just
> > due
> > the need to introduce multiple 'pattern match' statements.
> >
> > From what I was able to test (on the specific system + scanner + content
> > combination)
> > the performance penalty doesn't seem to be that dramatic.
> >
> > But having this testing data available I am not able to tell if the (in our
> > case)
> > observed behaviour is just exceptional (the system doesn't have "too much"
> > packages installed,
> > scanner is pretty well optimized, and the content doesn't utilize
> > rpmverifyfile_object /
> > rpmverifypackage_objects OVAL objects in a way involving multiple system
> > RPM packages
> > too much) or if this would be general case (in other words on every system
> > with
> > every scanner, and every content introduction of this change when
> > processing content
> > involving more than one RPM package the performance penalty won't be that
> > much,
> > and therefore the OVAL 5.10.1+ is safe change to be enforced by the
> > standard).
> >
> > But from the quick (abstracting out from the the concrete ToE case)
> > theoretic analysis
> > it implies to me that the enforcement to use four more 'pattern match'
> > operations
> > to evaluate the same content (which previously required just one 'pattern
> > match' operation)
> > in the case corresponding rpmverifyfile_object / rpmverifypackage_object
> > OVAL objects
> > involve more than just concrete RPM package on the system, might lead to
> > performance
> > penalty (longer rule evaluation effective time) in some cases / in some
> > environments
> > (concrete system + scanner + content combination).
> >
> > Unfortunately as already mentioned earlier I am not able to prove this
> > performance penalty
> > is a real concern and how big in per cents (on the system + scanner +
> > content combination
> > I was testing the performance penalty wasn't such a dramatic increase it
> > wouldn't be
> > acceptable. Especially when this means now only valid rpmverifyfile_object
> > / rpmverifypackage_object
> > OVAL objects can be collected on the system).
> >
> > But I suppose there might be system + scanner + content combinations, where
> > the OVAL 5.10.1+
> > 'minOccurs=1' change will introduce performance penalty [longer evaluation
> > time for selected
> > rules], and in these environments to support the OVAL 5.10.1+ change it
> > won't be just question
> > of adding couple more of 'pattern match' statements, but might be also
> > matter of additional
> > tasks like content rewrite or scanner optimization.
> >
> > Therefore to avoid this my proposal is either to revert the change
> > introduced in [1], or
> > modify the current 'name, epoch, version, release, and arch' behaviour to
> > make the requirement
> > to require at least one of the five entities to be present (IOW make them
> > alternatives),
> > not all of them to be present simultaneously.
> >
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskosvky / Red Hat Security Technologies Team
> >
> >>
> >> Thanks,
> >>
> >> Danny
> >>
> >>> -----Original Message-----
> >>> From: Jan Lieskovsky [mailto:[hidden email]]
> >>> Sent: Friday, March 06, 2015 12:43 PM
> >>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >>> Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
> >>> Revert the <rpmverifyfile_object> minOccurs='1' and
> >>> <rpmverifypackage_object>
> >>> minOccurs='1' change for epoch, version, release, and arch entities
> >>> introduced in
> >>> 5.10.1 OVAL language version
> >>>
> >>> Hello folks,
> >>>
> >>> based on the guidance:
> >>> [1]
> >>> https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
> >>> reporting-a-bug-or-getting-help
> >>>
> >>> how to report a bug against current version of the OVAL language standard
> >>> I have filed the following bug for the OVAL Board's consideration:
> >>> [2] https://github.com/OVALProject/Language/issues/238
> >>>
> >>> Kindly review it && let me know if it's missing any official
> >>> requirement(s)
> >>> so they can be provided yet (mainly if the schema implementation change
> >>> is required too).
> >>>
> >>> Thank you && Regards, Jan.
> >>> --
> >>> Jan iankko Lieskovsky / Red Hat Security Technologies Team
> >>>
> >>> P.S.: The underlying issue has been originally brought to us by David
> >>> Solin
> >>>     for review. After testing && review we can confirm its presence and
> >>>     therefore filed [2] request for the consideration of the change.
> >>>
> >>> To unsubscribe, send an email message to [hidden email] with
> >>> SIGNOFF OVAL-DEVELOPER-LIST
> >>> in the BODY of the message.  If you have difficulties, write to
> >>> OVAL-DEVELOPER-
> >>> [hidden email].
> >>
> >
> > To unsubscribe, send an email message to [hidden email] with
> > SIGNOFF OVAL-DEVELOPER-LIST
> > in the BODY of the message.  If you have difficulties, write to
> > [hidden email].
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message.  If you have difficulties, write to
> [hidden email].
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities introduced in 5.10.1 OVAL language versi

Martin Preisler
In reply to this post by joval
----- Original Message -----

> From: "David Solin" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, March 19, 2015 1:23:42 PM
> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1: Revert the <rpmverifyfile_object>
> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for epoch, version, release, and arch entities
> introduced in 5.10.1 OVAL language versi
>
> Or… we could keep the minOccurs=“1” requirement for the name entity, and
> allow minOccurs=“0” for e, v, r and arch … which I guess is how I thought it
> worked in OVAL 5.10.1 (without troubling to actually look at ‘name’).

Sounds good to me. I don't think this change prohibits any reasonable use
by content authors.

--
Martin Preisler
Security Technologies | Red Hat, Inc.

> David Solin
> [hidden email]
>
>
>
> > On Mar 19, 2015, at 5:32 AM, Jan Lieskovsky <[hidden email]> wrote:
> >
> > ----- Original Message -----
> >> From: "Dan Haynes" <[hidden email]>
> >> To: [hidden email]
> >> Sent: Wednesday, March 18, 2015 7:47:42 PM
> >> Subject: Re: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version
> >> 5.11.1: Revert the <rpmverifyfile_object>
> >> minOccurs='1' and <rpmverifypackage_object> minOccurs='1' change for
> >> epoch, version, release, and arch entities
> >> introduced in 5.10.1 OVAL language versi
> >>
> >> Hi Jan,
> >
> > Hello Danny,
> >
> >  thank you for your reply && review of the proposal.
> >
> >>
> >> I just looked into the bug issue tracker you created and it looks like you
> >> found my original post about why we made the change from minOccurs="0" to
> >> minOccurs="1" in the object.
> >
> > Correct. If I understood it right the main reason for introduction of that
> > change
> > was to prevent cases when the pre OVAL-5.10.1 standard "it does open the
> > opportunity for content authors to create rpmverifyfile_objects and
> > rpmverifypackage_objects without any entities."
> >
> > Therefore the 'minOccurs=1' requirement has been introduced to enforce
> > directly
> > in the standard that the content will be written in such a way it won't
> > cause
> > OVAL scanner tool to crash or consume extensive system resources & possibly
> > hang.
> >
> > I can understand this motivation. But the question I am trying to raise in
> > ticket:
> >  [1] https://github.com/OVALProject/Language/issues/238
> >
> > being if it was really necessary to introduce the 'minOccurs=1' requirement
> > on
> > all of the 'name, epoch, version, release, and arch' entities. In other
> > words
> > if it was not sufficient to enforce 'minOccurs=1' requirement to be present
> > in at least one of them. E.g. the requirement to state to define a valid
> > rpmverifyfile_object / rpmverifypackage_object the content needs to have at
> > least
> > one of 'name, epoch, version, release, or arch' entities specified /
> > present.
> >
> > Yet in different way why it was not sufficient to place OR operator between
> > those five elements (e.g. name_is_present or epoch_is_present or
> > version_is_present
> > or release_is_present or arch_is_present. At least one from all of these
> > five
> > entities needs to be present in order the corresponding object to be
> > considered
> > valid)? Instead of requiring all five of them (in some sort of the
> > definition, e.g.
> > at least via pattern match to be present)? If I can use an analogy I would
> > compare
> > with unix:file_object:
> >  [2]
> >  https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#file_object
> >
> > For this object also 'filepath, path, filename' entities are required. But
> > as far
> > as I can tell it's implemented / enforced in the way that under condition
> > 'filepath'
> > element / entity is defined / present, 'path' and 'filename' entities don't
> > need
> > to be. And vice versa, when 'path' and 'filename' entities are present
> > (where 'filename'
> > can be specified via '<xsi:nil>'), 'filepath' doesn't need to be present
> > any more.
> > In my understanding 'filepath' and 'path + filename' entities are
> > alternative entity definitions
> > for unix:file_object.
> >
> > The question is why rpmverifyfile_object and rpmverifypackage_object
> > couldn't be defined
> > in the very same way (IOW an alternation operation to be put between the
> > five entities
> > instead of strictly requiring all five of them to be present at least once
> > in some form).
> >
> > On the other hand I agree that to uniquely identify RPM package on the
> > system to specify
> > just 'name', or just 'version', or 'arch' isn't sufficient. But if the
> > content authors
> > wanted to uniquely identify particular RPM object on the system, they could
> > still use
> > all five of the entities - they weren't forbidden to do that even with the
> > pre OVAL 5.10.1
> > versions.
> >
> > To summary I understand the motivation / effort the standard to enforce
> > such requirements
> > so only valid objects would be collected on the system. But what I am
> > wondering being
> > why it was necessary to require all five entities to be present rather to
> > make them
> > alternative names / equivalents like it's done in unix:file_object
> > definition / standard
> > specification.
> >
> >> I would just emphasize that this change was
> >> made in an update release
> >> (https://oval.mitre.org/language/about/versioning.html), which allows for
> >> changes that break backward compatibility, and had approval from the OVAL
> >> Board.
> >
> > Agree here too. IOW I understand that in order the standard / specification
> > to evolve to meet changing requirements there need to be incompatible
> > changes
> > present (there needs to be a way how to address the changing environment).
> > It was not meant as an argument why such a change shouldn't be introduced.
> > If I mentioned it in [1] ticket, it was just margin note (not a
> > justification
> > why such change shouldn't be introduced). Sorry if the description in [1]
> > sounded / could be percepted in that way. The possible compatibility break
> > was not the primary concern.
> >
> >>
> >> Would it be possible to update the 5.10 content to include the following,
> >> prior to the filepath entity, to make it validate under both 5.10 and
> >> beyond?
> >>
> >>  <name operation="pattern match"/>
> >>  <epoch operation="pattern match"/>
> >>  <version operation="pattern match"/>
> >>  <release operation="pattern match"/>
> >>  <arch operation="pattern match"/>
> >>
> >> I suspect that you could potentially do this in an automated fashion.
> >
> > Yes, there's workaround how to make former OVAL 5.10 content to work
> > properly also with OVAL 5.10.1+ schemas. And we are actually using it
> > already.
> >
> > The primary concern was different - as you list above the former OVAL 5.10
> > content to continue work properly also with OVAL 5.10.1+ schemas, multiple
> > 'pattern match' operations need to be added for the case the content wants
> > to scan more than just a one concrete RPM package on the system. Since
> > 'pattern match' is expensive operation, my primary concern was if there
> > won't
> > be performance penalty (longer evaluation time for particular rule) just
> > due
> > the need to introduce multiple 'pattern match' statements.
> >
> > From what I was able to test (on the specific system + scanner + content
> > combination)
> > the performance penalty doesn't seem to be that dramatic.
> >
> > But having this testing data available I am not able to tell if the (in our
> > case)
> > observed behaviour is just exceptional (the system doesn't have "too much"
> > packages installed,
> > scanner is pretty well optimized, and the content doesn't utilize
> > rpmverifyfile_object /
> > rpmverifypackage_objects OVAL objects in a way involving multiple system
> > RPM packages
> > too much) or if this would be general case (in other words on every system
> > with
> > every scanner, and every content introduction of this change when
> > processing content
> > involving more than one RPM package the performance penalty won't be that
> > much,
> > and therefore the OVAL 5.10.1+ is safe change to be enforced by the
> > standard).
> >
> > But from the quick (abstracting out from the the concrete ToE case)
> > theoretic analysis
> > it implies to me that the enforcement to use four more 'pattern match'
> > operations
> > to evaluate the same content (which previously required just one 'pattern
> > match' operation)
> > in the case corresponding rpmverifyfile_object / rpmverifypackage_object
> > OVAL objects
> > involve more than just concrete RPM package on the system, might lead to
> > performance
> > penalty (longer rule evaluation effective time) in some cases / in some
> > environments
> > (concrete system + scanner + content combination).
> >
> > Unfortunately as already mentioned earlier I am not able to prove this
> > performance penalty
> > is a real concern and how big in per cents (on the system + scanner +
> > content combination
> > I was testing the performance penalty wasn't such a dramatic increase it
> > wouldn't be
> > acceptable. Especially when this means now only valid rpmverifyfile_object
> > / rpmverifypackage_object
> > OVAL objects can be collected on the system).
> >
> > But I suppose there might be system + scanner + content combinations, where
> > the OVAL 5.10.1+
> > 'minOccurs=1' change will introduce performance penalty [longer evaluation
> > time for selected
> > rules], and in these environments to support the OVAL 5.10.1+ change it
> > won't be just question
> > of adding couple more of 'pattern match' statements, but might be also
> > matter of additional
> > tasks like content rewrite or scanner optimization.
> >
> > Therefore to avoid this my proposal is either to revert the change
> > introduced in [1], or
> > modify the current 'name, epoch, version, release, and arch' behaviour to
> > make the requirement
> > to require at least one of the five entities to be present (IOW make them
> > alternatives),
> > not all of them to be present simultaneously.
> >
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskosvky / Red Hat Security Technologies Team
> >
> >>
> >> Thanks,
> >>
> >> Danny
> >>
> >>> -----Original Message-----
> >>> From: Jan Lieskovsky [mailto:[hidden email]]
> >>> Sent: Friday, March 06, 2015 12:43 PM
> >>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >>> Subject: [OVAL-DEVELOPER-LIST] FOR REVIEW - OVAL language version 5.11.1:
> >>> Revert the <rpmverifyfile_object> minOccurs='1' and
> >>> <rpmverifypackage_object>
> >>> minOccurs='1' change for epoch, version, release, and arch entities
> >>> introduced in
> >>> 5.10.1 OVAL language version
> >>>
> >>> Hello folks,
> >>>
> >>> based on the guidance:
> >>> [1]
> >>> https://github.com/OVALProject/Language/wiki#requesting-a-new-feature-
> >>> reporting-a-bug-or-getting-help
> >>>
> >>> how to report a bug against current version of the OVAL language standard
> >>> I have filed the following bug for the OVAL Board's consideration:
> >>> [2] https://github.com/OVALProject/Language/issues/238
> >>>
> >>> Kindly review it && let me know if it's missing any official
> >>> requirement(s)
> >>> so they can be provided yet (mainly if the schema implementation change
> >>> is required too).
> >>>
> >>> Thank you && Regards, Jan.
> >>> --
> >>> Jan iankko Lieskovsky / Red Hat Security Technologies Team
> >>>
> >>> P.S.: The underlying issue has been originally brought to us by David
> >>> Solin
> >>>     for review. After testing && review we can confirm its presence and
> >>>     therefore filed [2] request for the consideration of the change.

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].