Hello, we are a bit confused on what is the status with regular expressions and modifiers. A possibly outdated source [1] states that "... Perl regular expression modifiers (m, i, s, x) are not supported. These modifiers should be considered to always be 'OFF' unless specifically permitted by documentation on an OVAL Language construct." However, that page is referenced by a more up-to-date resource [2]. As numerous config files that are examined by the textfilecontent family of tests often feature case insensitivity (e.g. sshd, auditd), the case-insensitive functionality is quite important. Am I missing some other documentation resource, or should I go ahead and submit a PR with the proposal of allowing the Perl-style modifiers? Best regards, Matej [1]: https://protect-us.mimecast.com/s/5uGvCG6XLyHzOM9TK3gNg?domain=oval.mitre.org [2]: https://protect-us.mimecast.com/s/6evUCJ6KOGHjAYoHGnOHP?domain=github.com

Matej Tyc, There are a few approaches to handling this issue. In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ of interest. E.g. the textfilecontent54 object has ‘pattern’ and ‘behaviors’ which apply to the pattern. Those behaviors (ignore_case, multiline, and singleline) implement a few of the regular expression options. I have seen some content which uses character classes to achieve a more targeted effect such as being case sensitive on a portion of a pattern and insensitive in other parts. E.g. /A String [Tt]o [Mm]atch/. This is a little tedious, but, should work. Another option, which may not be fully supported by all OVAL processors would be to embed the option(s) and, thus, a little risky. For instance, this: /string to match/i Could be written as: /(?i)string to match/ From: OVAL_Developer <oval_developer-bounces@lists.cisecurity.org> On Behalf Of Matej Týc Sent: Wednesday, July 24, 2019 11:37 AM To: OVAL Developer List <oval_developer@lists.cisecurity.org> Subject: [Non-DoD Source] [OVAL DEVELOPER] OVAL >= 5.10 and regex case sensitivity All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. _____ Hello, we are a bit confused on what is the status with regular expressions and modifiers. A possibly outdated source [1] states that "... Perl regular expression modifiers (m, i, s, x) are not supported. These modifiers should be considered to always be 'OFF' unless specifically permitted by documentation on an OVAL Language construct." However, that page is referenced by a more up-to-date resource [2]. As numerous config files that are examined by the textfilecontent family of tests often feature case insensitivity (e.g. sshd, auditd), the case-insensitive functionality is quite important. Am I missing some other documentation resource, or should I go ahead and submit a PR with the proposal of allowing the Perl-style modifiers? Best regards, Matej [1]: https://protect-us.mimecast.com/s/cU9QC5ywmJHrxqBHz2NVn < https://protect-us.mimecast.com/s/J_U5C68xnLS41Q5h6cmV8?domain=oval.mitre.org > [2]: https://protect-us.mimecast.com/s/i-gsC73yoNCBQ3DUBAErG < https://protect-us.mimecast.com/s/Jsx4C82zpPtyznofMHYX1?domain=github.com >

By default regex is casesensitive, unless the object has an option and the option for caseinsensitivity is set. Am Mi., 24. Juli 2019 um 19:39 Uhr schrieb Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) via OVAL_Developer < oval_developer@lists.cisecurity.org>: > Matej Tyc, > > > > There are a few approaches to handling this issue. > > > > In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ of > interest. E.g. the textfilecontent54 object has ‘pattern’ and ‘behaviors’ > which apply to the pattern. Those behaviors (ignore_case, multiline, and > singleline) implement a few of the regular expression options. > > > > I have seen some content which uses character classes to achieve a more > targeted effect such as being case sensitive on a portion of a pattern and > insensitive in other parts. E.g. /A String [Tt]o [Mm]atch/. This is a > little tedious, but, should work. > > > > Another option, which may not be fully supported by all OVAL processors > would be to embed the option(s) and, thus, a little risky. > > For instance, this: /string to match/i > > Could be written as: /(?i)string to match/ > > > > > > > > > > > > *From:* OVAL_Developer <oval_developer-bounces@lists.cisecurity.org> *On > Behalf Of *Matej Týc > *Sent:* Wednesday, July 24, 2019 11:37 AM > *To:* OVAL Developer List <oval_developer@lists.cisecurity.org> > *Subject:* [Non-DoD Source] [OVAL DEVELOPER] OVAL >= 5.10 and regex case > sensitivity > > > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web > browser. > ------------------------------ > > > > Hello, > > we are a bit confused on what is the status with regular expressions and > modifiers. A possibly outdated source [1] states that "... Perl regular > expression modifiers (m, i, s, x) are not supported. These modifiers > should be considered to always be 'OFF' unless specifically permitted by > documentation on an OVAL Language construct." > > However, that page is referenced by a more up-to-date resource [2]. As > numerous config files that are examined by the textfilecontent family of > tests often feature case insensitivity (e.g. sshd, auditd), the > case-insensitive functionality is quite important. Am I missing some > other documentation resource, or should I go ahead and submit a PR with > the proposal of allowing the Perl-style modifiers? > > Best regards, > Matej > > [1]: https://protect-us.mimecast.com/s/ElvgCBBXDlfL0jwtWTkDh > <https://protect-us.mimecast.com/s/nfvOCxkzYOtWDk7h8_J49> < > https://protect-us.mimecast.com/s/A8uUCDkZGpt8wqEukJCgV?domain=oval.mitre.org > <https://protect-us.mimecast.com/s/KoKNCyPAZQHBKZ8fMrs6Y?domain=oval.mitre.org> > > > [2]: > > https://protect-us.mimecast.com/s/4F9SCERXJriZOLvTBmCXH > <https://protect-us.mimecast.com/s/22WfCzp41VSjE6ksgi1fS> < > https://protect-us.mimecast.com/s/Qc57CG6XLyHzEkDCY2jFz?domain=github.com > <https://protect-us.mimecast.com/s/OBgOCADXBjCDB4wfYKYFC?domain=github.com> > > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org > > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org >

PS: in case a general caseinsensitivity is needed/wanted, i'd propose , in addition to equals/case_insensitive_equals a case_insensitive_regex operator. Am Do., 25. Juli 2019 um 20:11 Uhr schrieb Alexander Benikowski < sebal007@googlemail.com>: > By default regex is casesensitive, unless the object has an option and the > option for caseinsensitivity is set. > > Am Mi., 24. Juli 2019 um 19:39 Uhr schrieb Ulmer, John R CIV USN > SPAWARSYSCEN LANT SC (USA) via OVAL_Developer < > oval_developer@lists.cisecurity.org>: > >> Matej Tyc, >> >> >> >> There are a few approaches to handling this issue. >> >> >> >> In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ of >> interest. E.g. the textfilecontent54 object has ‘pattern’ and ‘behaviors’ >> which apply to the pattern. Those behaviors (ignore_case, multiline, and >> singleline) implement a few of the regular expression options. >> >> >> >> I have seen some content which uses character classes to achieve a more >> targeted effect such as being case sensitive on a portion of a pattern and >> insensitive in other parts. E.g. /A String [Tt]o [Mm]atch/. This is a >> little tedious, but, should work. >> >> >> >> Another option, which may not be fully supported by all OVAL processors >> would be to embed the option(s) and, thus, a little risky. >> >> For instance, this: /string to match/i >> >> Could be written as: /(?i)string to match/ >> >> >> >> >> >> >> >> >> >> >> >> *From:* OVAL_Developer <oval_developer-bounces@lists.cisecurity.org> *On >> Behalf Of *Matej Týc >> *Sent:* Wednesday, July 24, 2019 11:37 AM >> *To:* OVAL Developer List <oval_developer@lists.cisecurity.org> >> *Subject:* [Non-DoD Source] [OVAL DEVELOPER] OVAL >= 5.10 and regex case >> sensitivity >> >> >> >> All active links contained in this email were disabled. Please verify the >> identity of the sender, and confirm the authenticity of all links contained >> within the message prior to copying and pasting the address to a Web >> browser. >> ------------------------------ >> >> >> >> Hello, >> >> we are a bit confused on what is the status with regular expressions and >> modifiers. A possibly outdated source [1] states that "... Perl regular >> expression modifiers (m, i, s, x) are not supported. These modifiers >> should be considered to always be 'OFF' unless specifically permitted by >> documentation on an OVAL Language construct." >> >> However, that page is referenced by a more up-to-date resource [2]. As >> numerous config files that are examined by the textfilecontent family of >> tests often feature case insensitivity (e.g. sshd, auditd), the >> case-insensitive functionality is quite important. Am I missing some >> other documentation resource, or should I go ahead and submit a PR with >> the proposal of allowing the Perl-style modifiers? >> >> Best regards, >> Matej >> >> [1]: https://protect-us.mimecast.com/s/c_xzCrkqPytB7JYUjmGqn >> <https://protect-us.mimecast.com/s/AjrYCn5mLntRgB2i9N3np> < >> https://protect-us.mimecast.com/s/1fiYCv2xWKtkqV5C5kyeh?domain=oval.mitre.org >> <https://protect-us.mimecast.com/s/GNtLCo2nMpty5WRHzgrXa?domain=oval.mitre.org> >> > >> [2]: >> >> https://protect-us.mimecast.com/s/AALjCwpyXMSwkrmixcQJS >> <https://protect-us.mimecast.com/s/gGjkCpYoNrURq6WiYTqW5> < >> https://protect-us.mimecast.com/s/n4K-CxkzYOtWDNVCg92zN?domain=github.com >> <https://protect-us.mimecast.com/s/93LHCqxpOwHMnw3CEuQpb?domain=github.com> >> > >> _______________________________________________ >> OVAL_Developer mailing list >> OVAL_Developer@lists.cisecurity.org >> >> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org >> >

            'ignore_case' indicates whether case should be considered when matching system values against the regular expression provided by the pattern entity.

Mr. Benikowski, That functionality is provided by the specific ‘behaviors’ in the various test/object types. For instance, as mentioned previously, the textfilecontent54 object contains the ‘pattern’ and ‘behaviors’ elements. If you look at the definition of the textfilecontent54 behaviors, you’ll see that they apply specifically to the ‘pattern’ element in the textfilecontent54 object. 'ignore_case' indicates whether case should be considered when matching system values against the regular expression provided by the pattern entity. Setting the ‘ignore_case’ behavior has the effect of adding the ‘i’ option to the regex for the object pattern element. Other similar OVAL objects work the same way. ‘Hope this helps. From: Alexander Benikowski <sebal007@googlemail.com> Sent: Thursday, July 25, 2019 2:16 PM To: Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) <john.r.ulmer6.civ@mail.mil> Cc: Matěj Týč <matyc@redhat.com>; OVAL Developer List <oval_developer@lists.cisecurity.org> Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] OVAL >= 5.10 and regex case sensitivity All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. _____ PS: in case a general caseinsensitivity is needed/wanted, i'd propose , in addition to equals/case_insensitive_equals a case_insensitive_regex operator. Am Do., 25. Juli 2019 um 20:11 Uhr schrieb Alexander Benikowski <sebal007@googlemail.com <mailto:sebal007@googlemail.com %3c Caution-mailto:sebal007@googlemail.com > < Caution-mailto:sebal007@googlemail.com > >: By default regex is casesensitive, unless the object has an option and the option for caseinsensitivity is set. Am Mi., 24. Juli 2019 um 19:39 Uhr schrieb Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) via OVAL_Developer <oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org %3c Caution-mailto:oval_developer@lists.cisecurity.org > < Caution-mailto:oval_developer@lists.cisecurity.org > >: Matej Tyc, There are a few approaches to handling this issue. In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ of interest. E.g. the textfilecontent54 object has ‘pattern’ and ‘behaviors’ which apply to the pattern. Those behaviors (ignore_case, multiline, and singleline) implement a few of the regular expression options. I have seen some content which uses character classes to achieve a more targeted effect such as being case sensitive on a portion of a pattern and insensitive in other parts. E.g. /A String [Tt]o [Mm]atch/. This is a little tedious, but, should work. Another option, which may not be fully supported by all OVAL processors would be to embed the option(s) and, thus, a little risky. For instance, this: /string to match/i Could be written as: /(?i)string to match/ From: OVAL_Developer <oval_developer-bounces@lists.cisecurity.org <mailto:oval_developer-bounces@lists.cisecurity.org %3c Caution-mailto:oval_developer-bounces@lists.cisecurity.org > < Caution-mailto:oval_developer-bounces@lists.cisecurity.org > > On Behalf Of Matej Týc Sent: Wednesday, July 24, 2019 11:37 AM To: OVAL Developer List <oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org %3c Caution-mailto:oval_developer@lists.cisecurity.org > < Caution-mailto:oval_developer@lists.cisecurity.org > > Subject: [Non-DoD Source] [OVAL DEVELOPER] OVAL >= 5.10 and regex case sensitivity All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. _____ Hello, we are a bit confused on what is the status with regular expressions and modifiers. A possibly outdated source [1] states that "... Perl regular expression modifiers (m, i, s, x) are not supported. These modifiers should be considered to always be 'OFF' unless specifically permitted by documentation on an OVAL Language construct." However, that page is referenced by a more up-to-date resource [2]. As numerous config files that are examined by the textfilecontent family of tests often feature case insensitivity (e.g. sshd, auditd), the case-insensitive functionality is quite important. Am I missing some other documentation resource, or should I go ahead and submit a PR with the proposal of allowing the Perl-style modifiers? Best regards, Matej [1]: https://protect-us.mimecast.com/s/5I-YCVO24gHpm6GTG-NEO < https://protect-us.mimecast.com/s/2RBACW6K5kHnZKJuxBpCN > < https://protect-us.mimecast.com/s/vG0OCXDXgmCLjRwhDFSGa < https://protect-us.mimecast.com/s/b02GCYEYjoSymqrtVdbPn?domain=oval.mitre.org > > [2]: https://protect-us.mimecast.com/s/HVwpCZ6GkqHWALJfxxCds < https://protect-us.mimecast.com/s/OteVC1wpgxSQxoVS1lz6M > < https://protect-us.mimecast.com/s/KW_WC2kqjztDWXMhXfhDc < https://protect-us.mimecast.com/s/HSwZC31rkBSrolnSETqkC?domain=github.com > > _______________________________________________ OVAL_Developer mailing list OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> < Caution-mailto:OVAL_Developer@lists.cisecurity.org > https://protect-us.mimecast.com/s/CzXWC4xvlEHwEOXS3jVEy < https://protect-us.mimecast.com/s/CzXWC4xvlEHwEOXS3jVEy >

             'ignore_case' indicates whether case should be considered when matching system values against the regular expression provided by the pattern entity.

John Ulmer is quite correct — this is not an inconsistency in the documentation, or an accidental hold-over from a previous version of the language. When in doubt, you can always check the OVAL specification documentation, which should be considered authoritative. Here is a link to that: https://protect-us.mimecast.com/s/aHUFCjRgE7ixDW3uWxXqt?domain=github.com <https://protect-us.mimecast.com/s/aHUFCjRgE7ixDW3uWxXqt?domain=github.com> Appendix D deals with regular expression syntax in OVAL. In fact, the case-insensitive modifier ‘(?I)’ does appear to be explicitly permitted! But not other modifiers. This change was introduced between 5.10.1 and 5.11.2, because it’s not part of Appendinx D in the 5.10.1 specification document: https://protect-us.mimecast.com/s/wHzTCkRjG9iJAxrcV1ZBV?domain=oval.mitre.org <https://protect-us.mimecast.com/s/wHzTCkRjG9iJAxrcV1ZBV?domain=oval.mitre.org> Best regards, —David Solin > On Jul 25, 2019, at 1:43 PM, Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) via OVAL_Developer <oval_developer@lists.cisecurity.org> wrote: > > Mr. Benikowski, > > That functionality is provided by the specific ‘behaviors’ in the various test/object types. For instance, as mentioned previously, the textfilecontent54 object contains the ‘pattern’ and ‘behaviors’ elements. If you look at the definition of the textfilecontent54 behaviors, you’ll see that they apply specifically to the ‘pattern’ element in the textfilecontent54 object. > > 'ignore_case' indicates whether case should be considered when matching system values against the regular expression provided by the pattern entity. > > Setting the ‘ignore_case’ behavior has the effect of adding the ‘i’ option to the regex for the object pattern element. > > Other similar OVAL objects work the same way. > > ‘Hope this helps. > > From: Alexander Benikowski <sebal007@googlemail.com <mailto:sebal007@googlemail.com>> > Sent: Thursday, July 25, 2019 2:16 PM > To: Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) <john.r.ulmer6.civ@mail.mil <mailto:john.r.ulmer6.civ@mail.mil>> > Cc: Matěj Týč <matyc@redhat.com <mailto:matyc@redhat.com>>; OVAL Developer List <oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org>> > Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] OVAL >= 5.10 and regex case sensitivity > > All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. > > > > PS: in case a general caseinsensitivity is needed/wanted, i'd propose , in addition to equals/case_insensitive_equals a case_insensitive_regex operator. > > Am Do., 25. Juli 2019 um 20:11 Uhr schrieb Alexander Benikowski <sebal007@googlemail.com < Caution-mailto:sebal007@googlemail.com  <mailto:sebal007@googlemail.com%C2%A0%3c%C2%A0Caution-mailto:sebal007@googlemail.com%C2%A0>> >: > By default regex is casesensitive, unless the object has an option and the option for caseinsensitivity is set. > > Am Mi., 24. Juli 2019 um 19:39 Uhr schrieb Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) via OVAL_Developer <oval_developer@lists.cisecurity.org < Caution-mailto:oval_developer@lists.cisecurity.org  <mailto:oval_developer@lists.cisecurity.org%C2%A0%3c%C2%A0Caution-mailto:oval_developer@lists.cisecurity.org%C2%A0>> >: > Matej Tyc, > > There are a few approaches to handling this issue. > > In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ of interest. E.g. the textfilecontent54 object has ‘pattern’ and ‘behaviors’ which apply to the pattern. Those behaviors (ignore_case, multiline, and singleline) implement a few of the regular expression options. > > I have seen some content which uses character classes to achieve a more targeted effect such as being case sensitive on a portion of a pattern and insensitive in other parts. E.g. /A String [Tt]o [Mm]atch/. This is a little tedious, but, should work. > > Another option, which may not be fully supported by all OVAL processors would be to embed the option(s) and, thus, a little risky. > For instance, this: /string to match/i > Could be written as: /(?i)string to match/ > > > > > > From: OVAL_Developer <oval_developer-bounces@lists.cisecurity.org < Caution-mailto:oval_developer-bounces@lists.cisecurity.org  <mailto:oval_developer-bounces@lists.cisecurity.org%C2%A0%3c%C2%A0Caution-mailto:oval_developer-bounces@lists.cisecurity.org%C2%A0>> > On Behalf Of Matej Týc > Sent: Wednesday, July 24, 2019 11:37 AM > To: OVAL Developer List <oval_developer@lists.cisecurity.org < Caution-mailto:oval_developer@lists.cisecurity.org  <mailto:oval_developer@lists.cisecurity.org%C2%A0%3c%C2%A0Caution-mailto:oval_developer@lists.cisecurity.org%C2%A0>> > > Subject: [Non-DoD Source] [OVAL DEVELOPER] OVAL >= 5.10 and regex case sensitivity > > All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. > > > > Hello, > > we are a bit confused on what is the status with regular expressions and > modifiers. A possibly outdated source [1] states that "... Perl regular > expression modifiers (m, i, s, x) are not supported. These modifiers > should be considered to always be 'OFF' unless specifically permitted by > documentation on an OVAL Language construct." > > However, that page is referenced by a more up-to-date resource [2]. As > numerous config files that are examined by the textfilecontent family of > tests often feature case insensitivity (e.g. sshd, auditd), the > case-insensitive functionality is quite important. Am I missing some > other documentation resource, or should I go ahead and submit a PR with > the proposal of allowing the Perl-style modifiers? > > Best regards, > Matej > > [1]: https://protect-us.mimecast.com/s/V4ZDCxkzYOtWDY9I0Wk7i <https://protect-us.mimecast.com/s/aDBaClYkJjUYmQAcyTh3X> < https://protect-us.mimecast.com/s/iJ8tCyPAZQHBKx0fvXkS3 <https://protect-us.mimecast.com/s/6wCnCmZ0KltQ8OAI9AzEE> > < https://protect-us.mimecast.com/s/xCQxCzp41VSjE5xcW_9We <https://protect-us.mimecast.com/s/0vQWCn5mLntRg8KimYow9> < https://protect-us.mimecast.com/s/qoWYCADXBjCDBknT18Z6k?domain=oval.mitre.org <https://protect-us.mimecast.com/s/stp7Co2nMpty5OBuoRKia?domain=oval.mitre.org> > > > [2]: > https://protect-us.mimecast.com/s/VWLECBBXDlfL0YMhX-2yZ <https://protect-us.mimecast.com/s/EJPPCpYoNrURqYvi7FeQn> < https://protect-us.mimecast.com/s/koveCDkZGpt8w4nfXm4Jk <https://protect-us.mimecast.com/s/7uXZCqxpOwHMnqzIvCwEm> > < https://protect-us.mimecast.com/s/gAwJCERXJriZOEgH0jzPW <https://protect-us.mimecast.com/s/Mrg_CrkqPytB7g1fLoRj5> < https://protect-us.mimecast.com/s/kISBCG6XLyHzEv0HOd-kF?domain=github.com <https://protect-us.mimecast.com/s/HhDRCv2xWKtkqQ2sEzpC2?domain=github.com> > > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> < Caution-mailto:OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> > > https://protect-us.mimecast.com/s/8iJeCJ6KOGHjlN1c3S1y0 <https://protect-us.mimecast.com/s/Z6x_CwpyXMSwkBAhXr509> < https://protect-us.mimecast.com/s/8iJeCJ6KOGHjlN1c3S1y0 <https://protect-us.mimecast.com/s/Z6x_CwpyXMSwkBAhXr509> > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org <http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org>

Thank you John for your fast reply! As you point out, the problem with behaviors is that they apply to the whole pattern, while some config files have case-insensitive keys, but not values, e.g. the sshd config file. The decomposition of strings into sequences of character classes is of course a solution, but things get more complicated if you intend to store string components in external variables that provide less flexibility. Anyway, it is good to know that the documentation is up-to-date. On 24. 07. 19 19:36, Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (USA) wrote: > > Matej Tyc, > > There are a few approaches to handling this issue. > > In some OVAL objects, there are ‘behaviors’ associated the ‘pattern’ > of interest.  E.g. the textfilecontent54 object has ‘pattern’ and > ‘behaviors’ which apply to the pattern. Those behaviors (ignore_case, > multiline, and singleline) implement a few of the regular expression > options. > > I have seen some content which uses character classes to achieve a > more targeted effect such as being case sensitive on a portion of a > pattern and insensitive in other parts. E.g. /A String [Tt]o > [Mm]atch/.  This is a little tedious, but, should work. > > Another option, which may not be fully supported by all OVAL > processors would be to embed the option(s) and, thus, a little risky. > > For instance, this: /string to match/i > > Could be written as: /(?i)string to match/ > >  ... >

Oh, so that's great, thanks David for pointing this out! On 25. 07. 19 21:12, David Solin wrote: > John Ulmer is quite correct — this is not an inconsistency in the > documentation, or an accidental hold-over from a previous version of > the language. > > When in doubt, you can always check the OVAL specification > documentation, which should be considered authoritative.  Here is a > link to that: > https://protect-us.mimecast.com/s/0OUWCW6K5kHnvpQFK7PM2?domain=github.com > <https://protect-us.mimecast.com/s/_8OZCR6KZ2H38KpF9fS7n?domain=github.com> > > Appendix D deals with regular expression syntax in OVAL.  In fact, the > case-insensitive modifier ‘(?I)’ does appear to be explicitly > permitted!  But not other modifiers. > > This change was introduced between 5.10.1 and 5.11.2, because it’s not > part of Appendinx D in the 5.10.1 specification document: > https://protect-us.mimecast.com/s/heH9CXDXgmCL36gTkQ43Y?domain=oval.mitre.org > <https://protect-us.mimecast.com/s/G9wTCVO24gHp14EhzW2Kl?domain=oval.mitre.org> > > Best regards, > —David Solin > > >> On Jul 25, 2019, at 1:43 PM, Ulmer, John R CIV USN SPAWARSYSCEN LANT >> SC (USA) via OVAL_Developer <oval_developer@lists.cisecurity.org >> <mailto:oval_developer@lists.cisecurity.org>> wrote: >> >> ... > > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org