I can see an advantage here for the project as a whole - if we have e.g.
Python checks, we could use them to to cross-test OVAL checks, that are
less flexible and are more likely to be buggy.
I think that a rule sub-directory "python" or "shell", analogously to
the current "oval" would provide a compatible way to supply the SCE
content. Then, we would need the to extend the build system to pick it
up and to deliver it to the datastream. And last but not least, we would
need a mean how to disable it, as we probably want to be sure that we
don't ship datastreams with SCE content to customers.
I don't see an easy way how to do it ATM, as the process of creating
datastreams is quite complex. We in Red Hat don't plan to work on this
in the foreseeable future. But I think that upstream would accept those
contributions if the implementation was good enough.
On 04. 08. 20 16:51, N B wrote:
The specific content I am creating is not able to be proposed upstream. I was
thinking though that the infrastructure to support it (the ability for SSG to
support other SCE and/or raw XCCDF content) might be of interest upstream to
provide future flexibility for content.
I brought up raw XCCDF since that would be another way to smuggle SCE content
in without explicit support for SCE in the build scripts.
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
