Just wondering if anyone recalls any of the history on the change from OVAL 5.9 to 5.10 regarding the rpminfo object/state? Somehow our team completely missed the addition of extended_name and filepath, as they were not listed in the changelog, and I don't see any discussions on nabble regarding filepath. https://protect-us.mimecast.com/s/YXnWCn5mLntZPZ1c9WIW3?domain=oval.mitre.org I found one discussion that mentioned the extended_name. https://protect-us.mimecast.com/s/8d6xCo2nMptVgV1Sz2AkT?domain=making-security-measurable.1364806.n2.nabble.com Emailing this primarily as FYI, incase anyone else didn't diff the schema's between 5.9 and 5.10, and overlooked this undocumented change. Also, neither of these fields are tested in the SCAP 1.2 validation suite, so it appears we may not have been the only ones who missed this requirement. Side question... the reason I found this issue, is that I was trying to find a simple method to obtain the installation directory for a given package, and I'll admit I'm a bit of a novice at actually writing content, but this doesn't seem to a simple/straightforward thing to obtain. The "filepath" appears to be generic collect all, which could be fun to parse out and make useful at all. "This field contains the absolute path of a file or directory included in the rpm." Seems a lot like the point of rpmverifyfile to me? I see there was a changelog for rpmverify regarding filepath... any chance the update to rpminfo was a typo? 29906 rpmverify: allow the filepath entity to refer to directories Hopefully going forward, when additions are made to existing oval objects/states, we will make it a bit more obvious!~~ Thanks, Jack Vander Pol

Hey Jack, Good catch! I personally didn’t notice this either — and we’re also not collecting the files for rpminfo_objects. Since the filepath field has maxOccurs=“unlimited” it seems intended to catch every file that’s part of the RPM — although the precise meaning of how it’s a “part” of that RPM isn’t really describable (like it is in the rpmverifyfile_object). Maybe someone from the OpenSCAP team can tell us why this might have been added? I copied Martin. Best regards, —David Solin > On May 31, 2018, at 9:13 AM, Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) <jack.r.vanderpol.civ@mail.mil> wrote: > > Just wondering if anyone recalls any of the history on the change from OVAL 5.9 to 5.10 regarding the rpminfo object/state? Somehow our team completely missed the addition of extended_name and filepath, as they were not listed in the changelog, and I don't see any discussions on nabble regarding filepath. > > https://protect-us.mimecast.com/s/xMddCmZ0KltoQjRHG0VZE?domain=oval.mitre.org <https://protect-us.mimecast.com/s/xMddCmZ0KltoQjRHG0VZE?domain=oval.mitre.org> > > I found one discussion that mentioned the extended_name. > > https://protect-us.mimecast.com/s/t0YwCn5mLntZR76hJ7kZ6?domain=making-security-measurable.1364806.n2.nabble.com <https://protect-us.mimecast.com/s/t0YwCn5mLntZR76hJ7kZ6?domain=making-security-measurable.1364806.n2.nabble.com> > > Emailing this primarily as FYI, incase anyone else didn't diff the schema's between 5.9 and 5.10, and overlooked this undocumented change. Also, neither of these fields are tested in the SCAP 1.2 validation suite, so it appears we may not have been the only ones who missed this requirement. > > Side question... the reason I found this issue, is that I was trying to find a simple method to obtain the installation directory for a given package, and I'll admit I'm a bit of a novice at actually writing content, but this doesn't seem to a simple/straightforward thing to obtain. The "filepath" appears to be generic collect all, which could be fun to parse out and make useful at all. > > "This field contains the absolute path of a file or directory included in the rpm." Seems a lot like the point of rpmverifyfile to me? > > I see there was a changelog for rpmverify regarding filepath... any chance the update to rpminfo was a typo? > 29906 rpmverify: allow the filepath entity to refer to directories > > Hopefully going forward, when additions are made to existing oval objects/states, we will make it a bit more obvious!~~ > > Thanks, > Jack Vander Pol > _______________________________________________ > 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>

On Thursday, May 31, 2018 10:13:55 AM EDT Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) wrote: > Just wondering if anyone recalls any of the history on the change from OVAL > 5.9 to 5.10 regarding the rpminfo object/state? Somehow our team > completely missed the addition of extended_name and filepath, as they were > not listed in the changelog, and I don't see any discussions on nabble > regarding filepath. You would probably want to look for an email thread titled Version 5.8 Draft 4 is now available on OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Date: 7/23/10 9:30 AM There was some discussion about how to detect authorized files. Authorized files could be considered files shipped by the vendor which in turn means they are packaged up. The idea was to allow the creation of a test that mimics "rpm -qf /path/to/file" and get a package name that it belongs to. > https://protect-us.mimecast.com/s/uQSFC82zpPt5yWYTnwkhy?domain=oval.mitre.org > rg > > I found one discussion that mentioned the extended_name. > > https://protect-us.mimecast.com/s/taHqC9rAqRfWwA2FE_Zyf?domain=making-security-measurable.1364806.n2.nabble.com > https://protect-us.mimecast.com/s/9PsdC0Ro5viXAQmF2IbCQ?domain=ity-measurable.1364806.n2.nabble.com > > Emailing this primarily as FYI, incase anyone else didn't diff the schema's > between 5.9 and 5.10, and overlooked this undocumented change. Also, > neither of these fields are tested in the SCAP 1.2 validation suite, so it > appears we may not have been the only ones who missed this requirement. > > Side question... the reason I found this issue, is that I was trying to > find a simple method to obtain the installation directory for a given > package, and I'll admit I'm a bit of a novice at actually writing content, > but this doesn't seem to a simple/straightforward thing to obtain. The > "filepath" appears to be generic collect all, which could be fun to parse > out and make useful at all. > > "This field contains the absolute path of a file or directory included in > the rpm." Seems a lot like the point of rpmverifyfile to me? No, the rpmverify is to show modifications to files, meaning they did not verify as identical to what was shipped. In the discussion it was pointed out that verify is a slow way to get to a yes/no is this file packaged or not answer. > I see there was a changelog for rpmverify regarding filepath... any chance > the update to rpminfo was a typo? No, this was done in 5.8 I think. > 29906 rpmverify: allow the filepath entity to refer to directories This would probably have been added to express that directory permissions have been modified. -Steve > Hopefully going forward, when additions are made to existing oval > objects/states, we will make it a bit more obvious!~~ > > > > Thanks, > > Jack Vander Pol

Thanks for some historical perspective on this, good to know it wasn't just a copy/paste mistake, although the change definitely happened in OVAL for 5.10. Filepath and extended name are not in 5.8 or 5.9. Wondering what else changed for 5.10 that we'll stumble into later... https://protect-us.mimecast.com/s/Tmb5C5ywmJHPrOqhzqEkj?domain=oval.mitre.org https://protect-us.mimecast.com/s/aJ9LC68xnLS64xQt61vcx?domain=oval.mitre.org Jack Vander Pol SPAWAR Systems Center Atlantic ________________________________ From: Steve Grubb [sgrubb@redhat.com] Sent: Thursday, May 31, 2018 2:25 PM To: oval_developer@lists.cisecurity.org Cc: Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] History on linux rpminfo test updates to include filepath and extended_name 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. ---- On Thursday, May 31, 2018 10:13:55 AM EDT Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) wrote: > Just wondering if anyone recalls any of the history on the change from OVAL > 5.9 to 5.10 regarding the rpminfo object/state? Somehow our team > completely missed the addition of extended_name and filepath, as they were > not listed in the changelog, and I don't see any discussions on nabble > regarding filepath. You would probably want to look for an email thread titled Version 5.8 Draft 4 is now available on OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Date: 7/23/10 9:30 AM There was some discussion about how to detect authorized files. Authorized files could be considered files shipped by the vendor which in turn means they are packaged up. The idea was to allow the creation of a test that mimics "rpm -qf /path/to/file" and get a package name that it belongs to. > https://protect-us.mimecast.com/s/x7hdC73yoNCXB93iBiKPi?domain=oval.mitre.org > rg > > I found one discussion that mentioned the extended_name. > > https://protect-us.mimecast.com/s/oCBAC82zpPt5yxnhM_gkW?domain=making-security-measurable.1364806.n2.nabble.com > https://protect-us.mimecast.com/s/tRPLC9rAqRfWwPosPq1TT?domain=ity-measurable.1364806.n2.nabble.com > > Emailing this primarily as FYI, incase anyone else didn't diff the schema's > between 5.9 and 5.10, and overlooked this undocumented change. Also, > neither of these fields are tested in the SCAP 1.2 validation suite, so it > appears we may not have been the only ones who missed this requirement. > > Side question... the reason I found this issue, is that I was trying to > find a simple method to obtain the installation directory for a given > package, and I'll admit I'm a bit of a novice at actually writing content, > but this doesn't seem to a simple/straightforward thing to obtain. The > "filepath" appears to be generic collect all, which could be fun to parse > out and make useful at all. > > "This field contains the absolute path of a file or directory included in > the rpm." Seems a lot like the point of rpmverifyfile to me? No, the rpmverify is to show modifications to files, meaning they did not verify as identical to what was shipped. In the discussion it was pointed out that verify is a slow way to get to a yes/no is this file packaged or not answer. > I see there was a changelog for rpmverify regarding filepath... any chance > the update to rpminfo was a typo? No, this was done in 5.8 I think. > 29906 rpmverify: allow the filepath entity to refer to directories This would probably have been added to express that directory permissions have been modified. -Steve > Hopefully going forward, when additions are made to existing oval > objects/states, we will make it a bit more obvious!~~ > > > > Thanks, > > Jack Vander Pol

Actually I spoke out of turn before, Joval has collected the filepath entities for this object/item at least since 2013. There was an RpmInfoBehaviors entity added to the rpminfo_object at the same time that governs whether or not filepaths are collected — the default is to not collect them. So, I’m surprised this isn’t exercised by the validation program content, they tend to exercise behaviors pretty well in my experience. Thanks for the historical context, Steve! > On May 31, 2018, at 1:59 PM, Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) <jack.r.vanderpol.civ@mail.mil> wrote: > > Thanks for some historical perspective on this, good to know it wasn't just a copy/paste mistake, although the change definitely happened in OVAL for 5.10. Filepath and extended name are not in 5.8 or 5.9. Wondering what else changed for 5.10 that we'll stumble into later... > > https://protect-us.mimecast.com/s/YyaVCn5mLntZRJ2h9pfSd?domain=oval.mitre.org <https://protect-us.mimecast.com/s/YyaVCn5mLntZRJ2h9pfSd?domain=oval.mitre.org> > https://protect-us.mimecast.com/s/mdtmCo2nMptVy7Rhz272O?domain=oval.mitre.org <https://protect-us.mimecast.com/s/mdtmCo2nMptVy7Rhz272O?domain=oval.mitre.org> > > Jack Vander Pol > SPAWAR Systems Center Atlantic > > From: Steve Grubb [sgrubb@redhat.com <mailto:sgrubb@redhat.com>] > Sent: Thursday, May 31, 2018 2:25 PM > To: oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org> > Cc: Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) > Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] History on linux rpminfo test updates to include filepath and extended_name > > 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. > > > > > ---- > > On Thursday, May 31, 2018 10:13:55 AM EDT Vanderpol, Jack R CIV USN > SPAWARSYSCEN LANT SC (US) wrote: > > Just wondering if anyone recalls any of the history on the change from OVAL > > 5.9 to 5.10 regarding the rpminfo object/state? Somehow our team > > completely missed the addition of extended_name and filepath, as they were > > not listed in the changelog, and I don't see any discussions on nabble > > regarding filepath. > > You would probably want to look for an email thread titled > > Version 5.8 Draft 4 is now available > > on OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG <mailto:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG> Date: 7/23/10 9:30 AM > > There was some discussion about how to detect authorized files. Authorized > files could be considered files shipped by the vendor which in turn means > they are packaged up. The idea was to allow the creation of a test that > mimics "rpm -qf /path/to/file" and get a package name that it belongs to. > > > > https://protect-us.mimecast.com/s/4Ms8CpYoNrU0RjWHYUnn8?domain=oval.mitre.org <https://protect-us.mimecast.com/s/4Ms8CpYoNrU0RjWHYUnn8?domain=oval.mitre.org> > > rg > > > > I found one discussion that mentioned the extended_name. > > > > https://protect-us.mimecast.com/s/FNMCCqxpOwHyMp3HE2wYr?domain=making-security-measurable.1364806.n2.nabble.com <https://protect-us.mimecast.com/s/FNMCCqxpOwHyMp3HE2wYr?domain=making-security-measurable.1364806.n2.nabble.com> > > https://protect-us.mimecast.com/s/5mibCrkqPytRB5YfjJxAe?domain=ity-measurable.1364806.n2.nabble.com <https://protect-us.mimecast.com/s/FTwtCv2xWKtnkD5c5NZU1?domain=ity-measurable.1364806.n2.nabble.com> > > > > Emailing this primarily as FYI, incase anyone else didn't diff the schema's > > between 5.9 and 5.10, and overlooked this undocumented change. Also, > > neither of these fields are tested in the SCAP 1.2 validation suite, so it > > appears we may not have been the only ones who missed this requirement. > > > > Side question... the reason I found this issue, is that I was trying to > > find a simple method to obtain the installation directory for a given > > package, and I'll admit I'm a bit of a novice at actually writing content, > > but this doesn't seem to a simple/straightforward thing to obtain. The > > "filepath" appears to be generic collect all, which could be fun to parse > > out and make useful at all. > > > > "This field contains the absolute path of a file or directory included in > > the rpm." Seems a lot like the point of rpmverifyfile to me? > > No, the rpmverify is to show modifications to files, meaning they did not > verify as identical to what was shipped. In the discussion it was pointed out > that verify is a slow way to get to a yes/no is this file packaged or not > answer. > > > > I see there was a changelog for rpmverify regarding filepath... any chance > > the update to rpminfo was a typo? > > No, this was done in 5.8 I think. > > > 29906 rpmverify: allow the filepath entity to refer to directories > > This would probably have been added to express that directory permissions > have been modified. > > -Steve > > > Hopefully going forward, when additions are made to existing oval > > objects/states, we will make it a bit more obvious!~~ > > > > > > > > Thanks, > > > > Jack Vander Pol > > > > > > _______________________________________________ > 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>