Ladies and gentlemen,
let me introduce a new member of this mailing list - Ilya Okomin from
We normally don't make a big deal out of new people joining the list,
but two unusual events came together. Ilya is a steady contributor to
the ComplianceAsCode project, and probably the first person outside of
the Red Hat sphere who contributed actual tests. When we got in touch
with him, it turned out that he likes the idea of deepening his
collaboration with the project.
Ilya is open to help us with PR reviews, and we he shares the long-term
goal of extending the project's CI, in this case by adding Oracle
Linux-based nodes to the node matrix.
So let's welcome Ilya to this list!
As you know, I'm still learning my way around, so forgive me if this is lore everybody already knows, but after upgrading to 0.1.45 I noticed that there are, within the RHEL7 family, about 190 rules that come up as 'notchecked' (including some new rules added in 0.1.45). As far as I have seen, the main reason a rule gets that designation, as opposed to 'notapplicable' is when there is no OVAL content available. Are these the kinds of things were a new person might be able to contribute something or are these (as I suspect) "works in progress" that someone is already dealing with?
I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.