Pruning

[Vladimir Giszpenc]

Hello and happy Columbus Day,

There are a few OVAL tests that look for a file and then do stuff.
Unix/file
Independent/Textfilecontent_54
Independent/XmlFileContent
Independent/Filehash

And probably a bunch of others.  It would be great if they reused some
common structure, but that is not my point so forget about that.

Right now, we are able to have a pattern for the path and a pattern for
the filename.  This does not allow for easy pruning if we don't have a
precomputed list of all directories which we can quickly grep.  Maybe
this is an implementation issue, however I would like to propose we help
reduce the searchset from all files on the filing system to something
smaller and more manageable.

If now we had

<ind-def:textfilecontent54_object id="my:obj:123" version="1">
      <ind-def:path operation="pattern match">/a/b/c/.*</ind-def:path>
      <ind-def:filename>foo</ind-def:filename>
        <ind-def:pattern operation="pattern
match">whatever</ind-def:pattern>
      <ind-def:instance datatype="int">1</ind-def:instance>
</ind-def:textfilecontent54_object>

It would be nice to say something like this instead

<ind-def:textfilecontent54_object id="my:obj:123" version="1">
      <ind-def:relative>/a/b/c/</ind-def:path>
      <ind-def:path operation="pattern match">.*</ind-def:path>
      <ind-def:filename>foo</ind-def:filename>
        <ind-def:pattern operation="pattern
match">whatever</ind-def:pattern>
      <ind-def:instance datatype="int">1</ind-def:instance>
</ind-def:textfilecontent54_object>

Change "relative" to base or whatever is more appropriate.  The idea is
that we are now only looking through part of the file system and not all
of it.  Ideally "relative" would not support pattern matching.  The
default value for "relative" is obviously / on a nix file system.

Are there down sides that I am not seeing?  How big a change is this?
Does it require a major version that will never happen?


Thank you,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

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

[bakerj]

Vlad,

Would something like this work?

<ind-def:textfilecontent54_object id="my:obj:123" version="1">
      <ind-def:behaviors recurse_direction="down" max_depth="-1"/>
      <ind-def:path>/a/b/c/</ind-def:path>
      <ind-def:filename>foo</ind-def:filename>
      <ind-def:pattern operation="pattern match">whatever</ind-def:pattern>
      <ind-def:instance datatype="int">1</ind-def:instance>
</ind-def:textfilecontent54_object>

The behaviors I added above should indicate to the interpreter that a downward recursive search is needed starting at /a/b/c/. I think this would be equivalent to feature you are suggesting.

Regards,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

>-----Original Message-----
>From: Vladimir Giszpenc [mailto:[hidden email]]
>Sent: Friday, October 09, 2009 3:41 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] Pruning
>
>Hello and happy Columbus Day,
>
>There are a few OVAL tests that look for a file and then do stuff.
>Unix/file
>Independent/Textfilecontent_54
>Independent/XmlFileContent
>Independent/Filehash
>
>And probably a bunch of others.  It would be great if they reused some
>common structure, but that is not my point so forget about that.
>
>Right now, we are able to have a pattern for the path and a pattern for
>the filename.  This does not allow for easy pruning if we don't have a
>precomputed list of all directories which we can quickly grep.  Maybe
>this is an implementation issue, however I would like to propose we help
>reduce the searchset from all files on the filing system to something
>smaller and more manageable.
>
>If now we had
>
><ind-def:textfilecontent54_object id="my:obj:123" version="1">
>      <ind-def:path operation="pattern match">/a/b/c/.*</ind-def:path>
>      <ind-def:filename>foo</ind-def:filename>
> <ind-def:pattern operation="pattern
>match">whatever</ind-def:pattern>
>      <ind-def:instance datatype="int">1</ind-def:instance>
></ind-def:textfilecontent54_object>
>
>It would be nice to say something like this instead
>
><ind-def:textfilecontent54_object id="my:obj:123" version="1">
>      <ind-def:relative>/a/b/c/</ind-def:path>
>      <ind-def:path operation="pattern match">.*</ind-def:path>
>      <ind-def:filename>foo</ind-def:filename>
> <ind-def:pattern operation="pattern
>match">whatever</ind-def:pattern>
>      <ind-def:instance datatype="int">1</ind-def:instance>
></ind-def:textfilecontent54_object>
>
>Change "relative" to base or whatever is more appropriate.  The idea is
>that we are now only looking through part of the file system and not all
>of it.  Ideally "relative" would not support pattern matching.  The
>default value for "relative" is obviously / on a nix file system.
>
>Are there down sides that I am not seeing?  How big a change is this?
>Does it require a major version that will never happen?
>
>
>Thank you,
>
>Vladimir Giszpenc
>DSCI Contractor Supporting
>US Army CERDEC S&TCD IAD Tactical Network Protection Branch
>[phone]
>
>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-
>[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].

[Vladimir Giszpenc]

Hi Jon,

Though we talked about it, I will post what I was looking for to the
list for all to read:

I am looking to solve the /a/b/c/.*/d/e/f problem.  This is a problem on
filing systems as well as the registry.  The idea is that you don't want
your scanner to bother with the whole filing system or registry when
looking for pattern match.  So in my example, I would root my search at
/a/b/c/ instead of the default /.

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

> -----Original Message-----
> From: Baker, Jon [mailto:[hidden email]]
> Sent: Monday, October 26, 2009 4:54 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Pruning
>
> Vlad,
>
> Would something like this work?
>
> <ind-def:textfilecontent54_object id="my:obj:123" version="1">
>       <ind-def:behaviors recurse_direction="down" max_depth="-1"/>
>       <ind-def:path>/a/b/c/</ind-def:path>
>       <ind-def:filename>foo</ind-def:filename>
>       <ind-def:pattern operation="pattern match">whatever</ind-
> def:pattern>
>       <ind-def:instance datatype="int">1</ind-def:instance>
> </ind-def:textfilecontent54_object>
>
> The behaviors I added above should indicate to the interpreter that a
> downward recursive search is needed starting at /a/b/c/. I think this
> would be equivalent to feature you are suggesting.
>
> Regards,
>
> Jon
>
> ============================================
> Jonathan O. Baker
> G022 - IA Industry Collaboration
> The MITRE Corporation
> Email: [hidden email]
>
>
> >-----Original Message-----
> >From: Vladimir Giszpenc [mailto:[hidden email]]
> >Sent: Friday, October 09, 2009 3:41 PM
> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >Subject: [OVAL-DEVELOPER-LIST] Pruning
> >
> >Hello and happy Columbus Day,
> >
> >There are a few OVAL tests that look for a file and then do stuff.
> >Unix/file
> >Independent/Textfilecontent_54
> >Independent/XmlFileContent
> >Independent/Filehash
> >
> >And probably a bunch of others.  It would be great if they reused

some
> >common structure, but that is not my point so forget about that.
> >
> >Right now, we are able to have a pattern for the path and a pattern
> for
> >the filename.  This does not allow for easy pruning if we don't have
a

> >precomputed list of all directories which we can quickly grep.  Maybe
> >this is an implementation issue, however I would like to propose we
> help
> >reduce the searchset from all files on the filing system to something
> >smaller and more manageable.
> >
> >If now we had
> >
> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
> >      <ind-def:path operation="pattern

match">/a/b/c/.*</ind-def:path>

> >      <ind-def:filename>foo</ind-def:filename>
> > <ind-def:pattern operation="pattern
> >match">whatever</ind-def:pattern>
> >      <ind-def:instance datatype="int">1</ind-def:instance>
> ></ind-def:textfilecontent54_object>
> >
> >It would be nice to say something like this instead
> >
> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
> >      <ind-def:relative>/a/b/c/</ind-def:path>
> >      <ind-def:path operation="pattern match">.*</ind-def:path>
> >      <ind-def:filename>foo</ind-def:filename>
> > <ind-def:pattern operation="pattern
> >match">whatever</ind-def:pattern>
> >      <ind-def:instance datatype="int">1</ind-def:instance>
> ></ind-def:textfilecontent54_object>
> >
> >Change "relative" to base or whatever is more appropriate.  The idea
> is
> >that we are now only looking through part of the file system and not
> all
> >of it.  Ideally "relative" would not support pattern matching.  The
> >default value for "relative" is obviously / on a nix file system.
> >
> >Are there down sides that I am not seeing?  How big a change is this?
> >Does it require a major version that will never happen?
> >
> >
> >Thank you,
> >
> >Vladimir Giszpenc
> >DSCI Contractor Supporting
> >US Army CERDEC S&TCD IAD Tactical Network Protection Branch
> >[phone]
> >
> >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-
> >[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 OVAL-
> [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].

[bakerj]

As we discussed at the conference there is an optimization opportunity here that will make the searching much more efficient. For the sound of things you and I both landed on very similar solutions too. Here is roughly what I did in the OVAL Interpreter:

Any regex that is anchored with a ^ may be reduced to two smaller strings.
    - the first string is the constant portion
    - the second string is the dynamic portion
    So if we have ^/a/b/c/.+/d/e/f
    The first string could be /a/b/c/
    The second string could be .+/d/e/f

I wrote a function to parse a regular expression and break out that first string by looking for the first regular expression element that is not escaped. All this code is of course in the OVAL Interpreter and available for those that are interested to review.

Of course if the two of use both decided that some optimization is needed here we may want to consider making a change to the OVAL Language to help everyone more easily avoid this situation. Here are a few things that come to mind for this particular issue:

- any solution we develop in the language would need to be applied to other similar structures too. For example, the Windows registry would need a similar feature too.

- content authors could still write bad content and not make use of the new language feature so interpreter developers would probably still need to develop an optimization for situations like this.

- this is one more language construct for authors to learn to use and one more to developers to support

- this probably would fit into the new choice structure we introduced for files as a third way to represent a set of files to examine.

Please note that I am not adverse to developing an elegant capability in the language to address this request. I simply want to ensure that we all are making changes and adding to the language for good reason.


Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

>-----Original Message-----
>From: Vladimir Giszpenc [mailto:[hidden email]]
>Sent: Friday, October 30, 2009 6:43 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Pruning
>
>Hi Jon,
>
>Though we talked about it, I will post what I was looking for to the
>list for all to read:
>
>I am looking to solve the /a/b/c/.*/d/e/f problem.  This is a problem on
>filing systems as well as the registry.  The idea is that you don't want
>your scanner to bother with the whole filing system or registry when
>looking for pattern match.  So in my example, I would root my search at
>/a/b/c/ instead of the default /.
>
>Thanks,
>
>Vladimir Giszpenc
>DSCI Contractor Supporting
>US Army CERDEC S&TCD IAD Tactical Network Protection Branch
>[phone]
>
>> -----Original Message-----
>> From: Baker, Jon [mailto:[hidden email]]
>> Sent: Monday, October 26, 2009 4:54 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] Pruning
>>
>> Vlad,
>>
>> Would something like this work?
>>
>> <ind-def:textfilecontent54_object id="my:obj:123" version="1">
>>       <ind-def:behaviors recurse_direction="down" max_depth="-1"/>
>>       <ind-def:path>/a/b/c/</ind-def:path>
>>       <ind-def:filename>foo</ind-def:filename>
>>       <ind-def:pattern operation="pattern match">whatever</ind-
>> def:pattern>
>>       <ind-def:instance datatype="int">1</ind-def:instance>
>> </ind-def:textfilecontent54_object>
>>
>> The behaviors I added above should indicate to the interpreter that a
>> downward recursive search is needed starting at /a/b/c/. I think this
>> would be equivalent to feature you are suggesting.
>>
>> Regards,
>>
>> Jon
>>
>> ============================================
>> Jonathan O. Baker
>> G022 - IA Industry Collaboration
>> The MITRE Corporation
>> Email: [hidden email]
>>
>>
>> >-----Original Message-----
>> >From: Vladimir Giszpenc [mailto:[hidden email]]
>> >Sent: Friday, October 09, 2009 3:41 PM
>> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> >Subject: [OVAL-DEVELOPER-LIST] Pruning
>> >
>> >Hello and happy Columbus Day,
>> >
>> >There are a few OVAL tests that look for a file and then do stuff.
>> >Unix/file
>> >Independent/Textfilecontent_54
>> >Independent/XmlFileContent
>> >Independent/Filehash
>> >
>> >And probably a bunch of others.  It would be great if they reused
>some
>> >common structure, but that is not my point so forget about that.
>> >
>> >Right now, we are able to have a pattern for the path and a pattern
>> for
>> >the filename.  This does not allow for easy pruning if we don't have
>a
>> >precomputed list of all directories which we can quickly grep.  Maybe
>> >this is an implementation issue, however I would like to propose we
>> help
>> >reduce the searchset from all files on the filing system to something
>> >smaller and more manageable.
>> >
>> >If now we had
>> >
>> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
>> >      <ind-def:path operation="pattern
>match">/a/b/c/.*</ind-def:path>
>> >      <ind-def:filename>foo</ind-def:filename>
>> > <ind-def:pattern operation="pattern
>> >match">whatever</ind-def:pattern>
>> >      <ind-def:instance datatype="int">1</ind-def:instance>
>> ></ind-def:textfilecontent54_object>
>> >
>> >It would be nice to say something like this instead
>> >
>> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
>> >      <ind-def:relative>/a/b/c/</ind-def:path>
>> >      <ind-def:path operation="pattern match">.*</ind-def:path>
>> >      <ind-def:filename>foo</ind-def:filename>
>> > <ind-def:pattern operation="pattern
>> >match">whatever</ind-def:pattern>
>> >      <ind-def:instance datatype="int">1</ind-def:instance>
>> ></ind-def:textfilecontent54_object>
>> >
>> >Change "relative" to base or whatever is more appropriate.  The idea
>> is
>> >that we are now only looking through part of the file system and not
>> all
>> >of it.  Ideally "relative" would not support pattern matching.  The
>> >default value for "relative" is obviously / on a nix file system.
>> >
>> >Are there down sides that I am not seeing?  How big a change is this?
>> >Does it require a major version that will never happen?
>> >
>> >
>> >Thank you,
>> >
>> >Vladimir Giszpenc
>> >DSCI Contractor Supporting
>> >US Army CERDEC S&TCD IAD Tactical Network Protection Branch
>> >[phone]
>> >
>> >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-
>> >[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 OVAL-
>> [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 OVAL-
>[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].

[Thomas R. Jones]

On Wed, 2009-11-11 at 08:32 -0500, Baker, Jon wrote:
> As we discussed at the conference there is an optimization opportunity here that will make the searching much more efficient. For the sound of things you and I both landed on very similar solutions too. Here is roughly what I did in the OVAL Interpreter:
>
> Any regex that is anchored with a ^ may be reduced to two smaller strings.
>     - the first string is the constant portion
>     - the second string is the dynamic portion

How does your function check the following regex?
^x86_64$

No wildcards exist; however utilizes the beginning and end-of-line
anchors. So the function must not assume that the "dynamic" variable is
populated. Nor must it assume that the "static" variable is populated as
well.

Furthermore, I explicitly check in many of my definitions for similar
expressions:
(^i386$)|(^ppc$)|(^x86_64$)|^src$)

A quick check on quality analysis. ;)

>     So if we have ^/a/b/c/.+/d/e/f
>     The first string could be /a/b/c/
>     The second string could be .+/d/e/f
>
> I wrote a function to parse a regular expression and break out that first string by looking for the first regular expression element that is not escaped. All this code is of course in the OVAL Interpreter and available for those that are interested to review.
>
> Of course if the two of use both decided that some optimization is needed here we may want to consider making a change to the OVAL Language to help everyone more easily avoid this situation. Here are a few things that come to mind for this particular issue:
>
> - any solution we develop in the language would need to be applied to other similar structures too. For example, the Windows registry would need a similar feature too.
>
> - content authors could still write bad content and not make use of the new language feature so interpreter developers would probably still need to develop an optimization for situations like this.
>
> - this is one more language construct for authors to learn to use and one more to developers to support
>
> - this probably would fit into the new choice structure we introduced for files as a third way to represent a set of files to examine.
>
> Please note that I am not adverse to developing an elegant capability in the language to address this request. I simply want to ensure that we all are making changes and adding to the language for good reason.
>
>
> Jon
>
> ============================================
> Jonathan O. Baker
> G022 - IA Industry Collaboration
> The MITRE Corporation
> Email: [hidden email]
>
>
> >-----Original Message-----
> >From: Vladimir Giszpenc [mailto:[hidden email]]
> >Sent: Friday, October 30, 2009 6:43 AM
> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >Subject: Re: [OVAL-DEVELOPER-LIST] Pruning
> >
> >Hi Jon,
> >
> >Though we talked about it, I will post what I was looking for to the
> >list for all to read:
> >
> >I am looking to solve the /a/b/c/.*/d/e/f problem.  This is a problem on
> >filing systems as well as the registry.  The idea is that you don't want
> >your scanner to bother with the whole filing system or registry when
> >looking for pattern match.  So in my example, I would root my search at
> >/a/b/c/ instead of the default /.
> >
> >Thanks,
> >
> >Vladimir Giszpenc
> >DSCI Contractor Supporting
> >US Army CERDEC S&TCD IAD Tactical Network Protection Branch
> >[phone]
> >
> >> -----Original Message-----
> >> From: Baker, Jon [mailto:[hidden email]]
> >> Sent: Monday, October 26, 2009 4:54 PM
> >> To: [hidden email]
> >> Subject: Re: [OVAL-DEVELOPER-LIST] Pruning
> >>
> >> Vlad,
> >>
> >> Would something like this work?
> >>
> >> <ind-def:textfilecontent54_object id="my:obj:123" version="1">
> >>       <ind-def:behaviors recurse_direction="down" max_depth="-1"/>
> >>       <ind-def:path>/a/b/c/</ind-def:path>
> >>       <ind-def:filename>foo</ind-def:filename>
> >>       <ind-def:pattern operation="pattern match">whatever</ind-
> >> def:pattern>
> >>       <ind-def:instance datatype="int">1</ind-def:instance>
> >> </ind-def:textfilecontent54_object>
> >>
> >> The behaviors I added above should indicate to the interpreter that a
> >> downward recursive search is needed starting at /a/b/c/. I think this
> >> would be equivalent to feature you are suggesting.
> >>
> >> Regards,
> >>
> >> Jon
> >>
> >> ============================================
> >> Jonathan O. Baker
> >> G022 - IA Industry Collaboration
> >> The MITRE Corporation
> >> Email: [hidden email]
> >>
> >>
> >> >-----Original Message-----
> >> >From: Vladimir Giszpenc [mailto:[hidden email]]
> >> >Sent: Friday, October 09, 2009 3:41 PM
> >> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >> >Subject: [OVAL-DEVELOPER-LIST] Pruning
> >> >
> >> >Hello and happy Columbus Day,
> >> >
> >> >There are a few OVAL tests that look for a file and then do stuff.
> >> >Unix/file
> >> >Independent/Textfilecontent_54
> >> >Independent/XmlFileContent
> >> >Independent/Filehash
> >> >
> >> >And probably a bunch of others.  It would be great if they reused
> >some
> >> >common structure, but that is not my point so forget about that.
> >> >
> >> >Right now, we are able to have a pattern for the path and a pattern
> >> for
> >> >the filename.  This does not allow for easy pruning if we don't have
> >a
> >> >precomputed list of all directories which we can quickly grep.  Maybe
> >> >this is an implementation issue, however I would like to propose we
> >> help
> >> >reduce the searchset from all files on the filing system to something
> >> >smaller and more manageable.
> >> >
> >> >If now we had
> >> >
> >> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
> >> >      <ind-def:path operation="pattern
> >match">/a/b/c/.*</ind-def:path>
> >> >      <ind-def:filename>foo</ind-def:filename>
> >> > <ind-def:pattern operation="pattern
> >> >match">whatever</ind-def:pattern>
> >> >      <ind-def:instance datatype="int">1</ind-def:instance>
> >> ></ind-def:textfilecontent54_object>
> >> >
> >> >It would be nice to say something like this instead
> >> >
> >> ><ind-def:textfilecontent54_object id="my:obj:123" version="1">
> >> >      <ind-def:relative>/a/b/c/</ind-def:path>
> >> >      <ind-def:path operation="pattern match">.*</ind-def:path>
> >> >      <ind-def:filename>foo</ind-def:filename>
> >> > <ind-def:pattern operation="pattern
> >> >match">whatever</ind-def:pattern>
> >> >      <ind-def:instance datatype="int">1</ind-def:instance>
> >> ></ind-def:textfilecontent54_object>
> >> >
> >> >Change "relative" to base or whatever is more appropriate.  The idea
> >> is
> >> >that we are now only looking through part of the file system and not
> >> all
> >> >of it.  Ideally "relative" would not support pattern matching.  The
> >> >default value for "relative" is obviously / on a nix file system.
> >> >
> >> >Are there down sides that I am not seeing?  How big a change is this?
> >> >Does it require a major version that will never happen?
> >> >
> >> >
> >> >Thank you,
> >> >
> >> >Vladimir Giszpenc
> >> >DSCI Contractor Supporting
> >> >US Army CERDEC S&TCD IAD Tactical Network Protection Branch
> >> >[phone]
> >> >
> >> >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-
> >> >[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 OVAL-
> >> [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 OVAL-
> >[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].

[bakerj]

>> As we discussed at the conference there is an optimization opportunity
>here that will make the searching much more efficient. For the sound of
>things you and I both landed on very similar solutions too. Here is
>roughly what I did in the OVAL Interpreter:
>>
>> Any regex that is anchored with a ^ may be reduced to two smaller
>strings.
>>     - the first string is the constant portion
>>     - the second string is the dynamic portion
>
>How does your function check the following regex?
>^x86_64$
>
>No wildcards exist; however utilizes the beginning and end-of-line
>anchors. So the function must not assume that the "dynamic" variable is
>populated. Nor must it assume that the "static" variable is populated as
>well.
>
>Furthermore, I explicitly check in many of my definitions for similar
>expressions:
>(^i386$)|(^ppc$)|(^x86_64$)|^src$)
>
>A quick check on quality analysis. ;)
>

If there is no dynamic portion the string is the entire string is just treaded as a constant and a simple equality operation can be used for searching the system.

Jon