Optional Criteria question

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

Optional Criteria question

vlad.giszpenc
Hi All,

I noticed a strange behavior in my application and discovered that it is based on strange data which is based on the OVAL schema.  If you take a look at http://people.redhat.com/mjc/oval/com.redhat.rhsa-20060726.xml, you will notice that there are no tests, objects or states.  You will also notice that there is no criteria for the definition.

The oval-definitions-schema confirms that the criteria has a minOccurs="0" and the documentation mentions that there should be a criteria unless the definition is deprecated.  This suggests that the definition is invalid but suggestions are often ignored...


I am relatively new to the discussion so please forgive me if I ask questions that have been answered.

Why not always require a criteria?  If it is deprecated, the interpreter can ignore it...  How does the interpreter evaluate a system with nothing to test?  I can see why tests are optional since you can use another criteria as a test, but you need to have at least one criteria, right?

Thank you,

Vladimir Giszpenc
DSCI Contractor Supporting CERDEC S&TCD IAD
Tactical Network Protection Branch
(732) 532-8959
[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: Optional Criteria question

Andrew Buttner
Administrator
>Why not always require a criteria?  If it is deprecated, the
>interpreter can ignore it...  How does the interpreter
>evaluate a system with nothing to test?  I can see why tests
>are optional since you can use another criteria as a test, but
>you need to have at least one criteria, right?

If we set the minoccurs of the <criteria> to 1, then a deprecated OVAL
Definition would not validate.  What is needed are some schematron
statements to say that the <criteria> element must exist unless the
deprecated attribute is set to TRUE.

I will make a note of this in our tracker and add it to the next
release of the schema.

Thanks
Drew

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: Optional Criteria question

Gary Gapinski-4
In reply to this post by vlad.giszpenc
[hidden email] wrote:
> Why not always require a criteria?  If it is deprecated, the interpreter
> can ignore it...  How does the interpreter evaluate a system with
> nothing to test?  I can see why tests are optional since you can use
> another criteria as a test, but you need to have at least one criteria,
> right?

While I am unsure of the behavior of all OVAL-consuming devices, it
seems that the best way to indicate an absence of criteria is to absent
the criteria. Evaluation of such a definition would not yield a result
(other than indeterminate).

The alternative would be a mandate that "No OVAL definition may be
uttered that lacks a criterion". Perhaps that would be worthwhile, but
it would preclude a definition for which criteria were unknown, delayed,
missing, AWOL, etc.

Regards,

Gary

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: Optional Criteria question

vlad.giszpenc
In reply to this post by Andrew Buttner
From: "Buttner, Drew" <[hidden email]>

> If we set the minoccurs of the <criteria> to 1, then a deprecated OVAL
> Definition would not validate.  What is needed are some schematron

The schematron rules will invalidate this sort of definition, but I still don't undestand why a deprecated definition can't have criteria.  It sounds like you are talking about the implementation of the interpreter.   How does

  Deprecated + (0 < Criteria Occurences) = invalid definition

I still don't get it.  Please explain.

> -----Original Message-----
> From: Gary Gapinski [mailto:[hidden email]]

> While I am unsure of the behavior of all OVAL-consuming devices, it seems that the best way to indicate an > absence of criteria is to absent the criteria. Evaluation of such a definition would not yield a result

So is a definition absent of criteria always present.  If you can read this, your machine is vulnerable.  And the way to remediate would be to turn off the machine?

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting CERDEC S&TCD IAD
Tactical Network Protection Branch
(732) 532-8959
[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: Optional Criteria question

Andrew Buttner
Administrator
>> If we set the minoccurs of the <criteria> to 1, then a
>> deprecated OVAL Definition would not validate.  What is
>> needed are some schematron
>
>The schematron rules will invalidate this sort of definition,

No, the schematron rules will say that since it is a deprecated
definition then it is valid to not have a criteria.  Therefore a
definition that is deprecate that has no criteria will be valid.  A
definition that is not deprecated that is missing a criteria will be
invalid.
 
>but I still don't undestand why a deprecated definition can't
>have criteria.

A deprecated definition CAN have a criteria but it doesn't have to.
The reason for a deprecated definition is to make note of an ID that is
no longer valid.  Maybe we found duplicate definitions and decided to
"remove" one.  We don't want the old id being reassigned.  We also want
anyone referencing that old ID to know what happened.  We might leave
the criteria in place though for historical purposes.

>It sounds like you are talking about the
>implementation of the interpreter.   How does
>
>  Deprecated + (0 < Criteria Occurences) = invalid definition
>
>I still don't get it.  Please explain.

What was meant was:

(NOT Deprecated) + (0 = Criteria Occurences) = invalid definition

or

Deprecated + (0 <= Criteria Occurences) = valid definition

Thanks
Drew

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: Optional Criteria question

Ken Lassesen-2
Related Question:

It may happen that there is an element that is identical from several
sources, I did a quick count and found the following

org.mitre           11682
gov.nist.1           4072
gov.nist.2           1536
gov.nist.3           1414
com.redhat.rhsa     5859
com.secure-elements 1355
com.threatguard     347

It would be nice to have a mechanism to identify them, with an eye
towards elimination of duplicates...


Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717   Cell: 360-509-2402  Skype:
Ken.Lassesen
IM: [hidden email]  

CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, August 23, 2007 11:44 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question

>> If we set the minoccurs of the <criteria> to 1, then a deprecated
>> OVAL Definition would not validate.  What is needed are some
>> schematron
>
>The schematron rules will invalidate this sort of definition,

No, the schematron rules will say that since it is a deprecated
definition then it is valid to not have a criteria.  Therefore a
definition that is deprecate that has no criteria will be valid.  A
definition that is not deprecated that is missing a criteria will be
invalid.
 
>but I still don't undestand why a deprecated definition can't have
>criteria.

A deprecated definition CAN have a criteria but it doesn't have to.
The reason for a deprecated definition is to make note of an ID that is
no longer valid.  Maybe we found duplicate definitions and decided to
"remove" one.  We don't want the old id being reassigned.  We also want
anyone referencing that old ID to know what happened.  We might leave
the criteria in place though for historical purposes.

>It sounds like you are talking about the
>implementation of the interpreter.   How does
>
>  Deprecated + (0 < Criteria Occurences) = invalid definition
>
>I still don't get it.  Please explain.

What was meant was:

(NOT Deprecated) + (0 = Criteria Occurences) = invalid definition

or

Deprecated + (0 <= Criteria Occurences) = valid definition

Thanks
Drew

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: Optional Criteria question

Andrew Buttner
Administrator
I agree that removing duplicates would be a very beneficial task.  This
is something we hope to do for the OVAL Repository in the future.  As
far as coordinating duplicates across different external repositories,
we will need to make a change to the language to allow this kind of
reuse to take place more efficiently.  This is a topic for Version 6 of
OVAL and something that we have in mind for the next OVAL Developer
Days.

Thanks
Drew


>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Thursday, August 23, 2007 8:00 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>
>Related Question:
>
>It may happen that there is an element that is identical from several
>sources, I did a quick count and found the following
>
>org.mitre           11682
>gov.nist.1           4072
>gov.nist.2           1536
>gov.nist.3           1414
>com.redhat.rhsa     5859
>com.secure-elements 1355
>com.threatguard     347
>
>It would be nice to have a mechanism to identify them, with an eye
>towards elimination of duplicates...
>
>Ken Lassesen,

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: Optional Criteria question

Jon Baker
Administrator
If someone wants to produce a free utility that would identify dups in
a single definition document that would go a long way to addressing
this issue. I know there are numerous duplicates with in the oval
repository alone. If they are called out I will gladly make the content
changes to deprecate unneeded dups.

Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]


 

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, August 24, 2007 7:50 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>
>I agree that removing duplicates would be a very beneficial task.
This
>is something we hope to do for the OVAL Repository in the future.  As
>far as coordinating duplicates across different external repositories,
>we will need to make a change to the language to allow this kind of
>reuse to take place more efficiently.  This is a topic for Version 6
of

>OVAL and something that we have in mind for the next OVAL Developer
>Days.
>
>Thanks
>Drew
>
>
>>-----Original Message-----
>>From: Ken Lassesen [mailto:[hidden email]]
>>Sent: Thursday, August 23, 2007 8:00 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>>
>>Related Question:
>>
>>It may happen that there is an element that is identical from several
>>sources, I did a quick count and found the following
>>
>>org.mitre           11682
>>gov.nist.1           4072
>>gov.nist.2           1536
>>gov.nist.3           1414
>>com.redhat.rhsa     5859
>>com.secure-elements 1355
>>com.threatguard     347
>>
>>It would be nice to have a mechanism to identify them, with an eye
>>towards elimination of duplicates...
>>
>>Ken Lassesen,
>
>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: Optional Criteria question

vlad.giszpenc
In reply to this post by Andrew Buttner
From: "Buttner, Drew" <[hidden email]>
> >The schematron rules will invalidate this sort of definition,
>
> No, the schematron rules will say that since it is a deprecated
> definition then it is valid to not have a criteria.  Therefore a
> definition that is deprecate that has no criteria will be valid.  A
> definition that is not deprecated that is missing a criteria will be
> invalid.

My questions were based on a definition that is *not* deprecated and has no criteria (see the original question with a link to the Red Hat repository) and a little due to the fact that I did not sleep enough.  Thanks for being understanding and sorry for the confusion.

> >but I still don't undestand why a deprecated definition can't
> >have criteria.
>
> A deprecated definition CAN have a criteria but it doesn't have to.

Allow me to rephrase my question.  I don't understand why criteria are not always required even in the case of a deprecated definition.  I understand the use of deprecating definitions.  Criteria are always useful (sometimes more useful than the description) in describing the definition.  My comment is that there may be value in always having it around, even though it is not (as) necessary for a deprecated definition.

As a note to the other discussion this started, I would like to add that dupes are not the only issue.  If definition 123 checks for RPM < 1.2-3 of foo and definition 345 checks for foo < 1.2-5, the first is obsolete and should get deprecated.

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting CERDEC S&TCD IAD
Tactical Network Protection Branch
(732) 532-8959
[hidden email]

Date: Thursday, August 23, 2007 14:45
Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
To: [hidden email]

> >It sounds like you are talking about the
> >implementation of the interpreter.   How does
> >
> >  Deprecated + (0 < Criteria Occurences) = invalid definition
> >
> >I still don't get it.  Please explain.
>
> What was meant was:
>
> (NOT Deprecated) + (0 = Criteria Occurences) = invalid definition
>
> or
>
> Deprecated + (0 <= Criteria Occurences) = valid definition
>
> Thanks
> Drew
>
> 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: Optional Criteria question

Matthew N. Wojcik
Vladimir Giszpenc wrote:

> As a note to the other discussion this started, I would like
> to add that dupes are not the only issue.  If definition 123
> checks for RPM < 1.2-3 of foo and definition 345 checks for
> foo < 1.2-5, the first is obsolete and should get deprecated.

Not necessarily.  If CVE-567 was first fixed in version 1.2-3 of the
RPM, then that first definition may be a valid test for CVE-567.
Later, CVE-890 is discovered in the same package, and the fix first
released with RPM version 1.2-5.  They are both still valid
definitions.

Some users or use cases may of course only be interested in upgrading
to the most recent, fully fixed version of the RPM, so they may not
care much about the result of the def which checks for version 1.2-3.
But it's still a valid check for CVE-567.  It might be better to say
that, for some users, the 1.2-3 definition is superceded by the 1.2-5
def.  There are definitely use cases, however, that would still require
the 1.2-3 def.

--Woj                  Matthew N. Wojcik                 [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: Optional Criteria question

vlad.giszpenc
----- Original Message -----
From: "Wojcik, Matthew N." <[hidden email]>
> Not necessarily.  If CVE-567 was first fixed in version 1.2-3 of the
> RPM, then that first definition may be a valid test for CVE-567.
> Later, CVE-890 is discovered in the same package, and the fix first
> released with RPM version 1.2-5.  They are both still valid
> definitions.

Point taken.  I agree completely.

> But it's still a valid check for CVE-567.  It might be better to say
> that, for some users, the 1.2-3 definition is superceded by the 1.2-5
> def.  There are definitely use cases, however, that would still
> requirethe 1.2-3 def.

Could we add a way to mark definitions as superceded?  An interpreter could allow users to ignore these for the appropriate use cases.


Vladimir Giszpenc
DSCI Contractor Supporting CERDEC S&TCD IAD
Tactical Network Protection Branch
(732) 532-8959
[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: Optional Criteria question

Andrew Buttner
Administrator
In reply to this post by vlad.giszpenc
>>>but I still don't understand why a deprecated definition can't
>>>have criteria.
>>
>> A deprecated definition CAN have a criteria but it doesn't have to.
>
>Allow me to rephrase my question.  I don't understand why
>criteria are not always required even in the case of a
>deprecated definition.  I understand the use of deprecating
>definitions.  Criteria are always useful (sometimes more
>useful than the description) in describing the definition.  My
>comment is that there may be value in always having it around,
>even though it is not (as) necessary for a deprecated definition.

I don't know if there is a good reason for or against.  I see your
arguments though and they are legit.  Although some might argue that a
deprecated definition simply says that "this ID was previously assigned
so don't use it again".    This is why we left it as optional.

I don't see any harm in leaving it as is, especially since we might not
know the criteria of previously deprecated definitions.  Unless there
are others that agree that all defs should have a criteria?  Are there
other opinions out there?

Thanks
Drew

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: Optional Criteria question

Ken Lassesen-2
In reply to this post by Jon Baker
Hmmm, I have something close to that already, swamped at the moment ---
but I do have flight time to NIST coming up so will sketch that in as a
todo...


Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717   Cell: 360-509-2402  Skype:
Ken.Lassesen
IM: [hidden email]  

CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Friday, August 24, 2007 5:11 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question

If someone wants to produce a free utility that would identify dups in a
single definition document that would go a long way to addressing this
issue. I know there are numerous duplicates with in the oval repository
alone. If they are called out I will gladly make the content changes to
deprecate unneeded dups.

Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]


 

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, August 24, 2007 7:50 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>
>I agree that removing duplicates would be a very beneficial task.
This
>is something we hope to do for the OVAL Repository in the future.  As
>far as coordinating duplicates across different external repositories,
>we will need to make a change to the language to allow this kind of
>reuse to take place more efficiently.  This is a topic for Version 6
of

>OVAL and something that we have in mind for the next OVAL Developer
>Days.
>
>Thanks
>Drew
>
>
>>-----Original Message-----
>>From: Ken Lassesen [mailto:[hidden email]]
>>Sent: Thursday, August 23, 2007 8:00 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>>
>>Related Question:
>>
>>It may happen that there is an element that is identical from several
>>sources, I did a quick count and found the following
>>
>>org.mitre           11682
>>gov.nist.1           4072
>>gov.nist.2           1536
>>gov.nist.3           1414
>>com.redhat.rhsa     5859
>>com.secure-elements 1355
>>com.threatguard     347
>>
>>It would be nice to have a mechanism to identify them, with an eye
>>towards elimination of duplicates...
>>
>>Ken Lassesen,
>
>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: Optional Criteria question

Ken Lassesen-2
:-)

Attach you will find the result of a bit of quick programming. Spot
checks suggests that items identify are duplicates (of course, there may
be other items that are duplicate but which were not identified).

A little sad that I came up with 3616 duplicates in 26265 Oval elements
I have in a database.


Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717   Cell: 360-509-2402  Skype:
Ken.Lassesen
IM: [hidden email]  

CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Sunday, August 26, 2007 2:24 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question

Hmmm, I have something close to that already, swamped at the moment ---
but I do have flight time to NIST coming up so will sketch that in as a
todo...


Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717   Cell: 360-509-2402  Skype:
Ken.Lassesen
IM: [hidden email]  

CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Friday, August 24, 2007 5:11 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question

If someone wants to produce a free utility that would identify dups in a
single definition document that would go a long way to addressing this
issue. I know there are numerous duplicates with in the oval repository
alone. If they are called out I will gladly make the content changes to
deprecate unneeded dups.

Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]


 

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Friday, August 24, 2007 7:50 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>
>I agree that removing duplicates would be a very beneficial task.
This
>is something we hope to do for the OVAL Repository in the future.  As
>far as coordinating duplicates across different external repositories,
>we will need to make a change to the language to allow this kind of
>reuse to take place more efficiently.  This is a topic for Version 6
of

>OVAL and something that we have in mind for the next OVAL Developer
>Days.
>
>Thanks
>Drew
>
>
>>-----Original Message-----
>>From: Ken Lassesen [mailto:[hidden email]]
>>Sent: Thursday, August 23, 2007 8:00 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] Optional Criteria question
>>
>>Related Question:
>>
>>It may happen that there is an element that is identical from several
>>sources, I did a quick count and found the following
>>
>>org.mitre           11682
>>gov.nist.1           4072
>>gov.nist.2           1536
>>gov.nist.3           1414
>>com.redhat.rhsa     5859
>>com.secure-elements 1355
>>com.threatguard     347
>>
>>It would be nice to have a mechanism to identify them, with an eye
>>towards elimination of duplicates...
>>
>>Ken Lassesen,
>
>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].

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].

OvalDup.txt (648K) Download Attachment