Feature 6096: Scan RHEL/CentOS hosts using OVAL definitions#6241
Feature 6096: Scan RHEL/CentOS hosts using OVAL definitions#6241juan-fdz-hawa merged 40 commits intomainfrom
Conversation
…sed software against the specified state
…_type, skip epoch when processing RPM evr strings
|
@lucasmrod - I think I got all the CentOS post-processing code, but could you please double check? Thanks |
| Arch string `json:"arch"` | ||
| } | ||
|
|
||
| func extract(src, dst string, t require.TestingT) { |
There was a problem hiding this comment.
Maybe we should move this to pkg/ to a testing package.
| ) | ||
|
|
||
| type ObjectInfoState struct { | ||
| Name *ObjectStateString `json:",omitempty"` |
There was a problem hiding this comment.
Might be obvious to others, but what does this empty json field name do?
There was a problem hiding this comment.
It depends on the object associated with the state, for example, in case the object is a dpkg package Name refers to the name of the package. It has omitempty because is not required.
There was a problem hiding this comment.
Huh... Does it default to Name if the tag itself is not specified? TIL
chiiph
left a comment
There was a problem hiding this comment.
Looks good! Have we load tested this?
No, but I expect to see the same performance characteristics as with Ubuntu - the only difference is that this will consume more memory because the OVAL files for RHEL are bigger - I'll add a bench mark test for this
|
#6096
Apologies for the huge PR - I took the opportunity to do a fair bit of clean up and add some missing tests.
This PR extends the OVAL parser/analyzer so that we can scan RHEL based systems. While working on this I discovered that the way we store RHEL software versions is a little bit inconsistent with the way Ubuntu software versions are stored (see #6236 ), that said, ignoring the Epoch didn't affect the accuracy of the results at all (probably because
epochnumbers don't change that much).Checklist for submitter
changes/and/ororbit/changes/).