Remove unnecessary Jinja2 macros in control files #13180
Conversation
ANSSI is a product agnostic profile that should include rules relevant for multiple products. There is already a mechanism that allows products to refine control file selections on their profile levels, without need to include Jinja2 macros in control files. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
Make the information in notes more generic since notes is not consumed in the building system but helps maintainers. The systems consuming ANSSI control file uses sssd and the two execptions for rhel8 and ol8 were moved to the respective profiles. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
Removed Jinja2 from notes as they are not necessary. The rule no_nis_in_nsswitch is part of obsolete rules and should not bring any harm for products consuming ANSSI control file. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
PCI-DSS is a product agnostic profile that should include rules relevant for multiple products. There is already a mechanism that allows products to refine control file selections on their profile levels, without need to include Jinja2 macros in control files. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
HIPAA is a product agnostic profile that should include rules relevant for multiple products. There is already a mechanism that allows products to refine control file selections on their profile levels, without need to include Jinja2 macros in control files. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
The macro can be removed without relevant impact on final profile. Also, by removing Jinja2 macros from control file makes it much easier for integrations that process control files, such as trestlebot. Signed-off-by: Marcus Burghardt <maburgha@redhat.com>
|
Code Climate has analyzed commit bf813f9 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 61.9% (0.0% change). View more on Code Climate. |
|
If we want this to be the case going forward, I would suggest you open a PR against the style guide add something about not using Jinja in control files. However, there are spots in the SRG GPOS where we |
Agree @Mab879 . I think it would be good as a next step to document an agreement about this and even create some tests to avoid new Jinja2 macros in control files. The case for SRG GPOS could be an exception since they usually support the creation of STIG control files. For now the macros in SRG GPOS are not impacting the integration. |
|
@ComplianceAsCode/oracle-maintainers if you could review that would be appreciated. |
| - ldap_client_tls_cacertpath | ||
|
|
||
| # Ensure nis is not used for RHEL 8 in R69 | ||
| - no_nis_in_nsswitch |
There was a problem hiding this comment.
I think this is not needed. as it was added in the "related rules" section in anssi control file
There was a problem hiding this comment.
Hi @Xeicker , previously it was included only for rhel8 and ol8 via Jinja2 in the anssi control file. So I removed the exception from the control file and included the rule directly in the product profiles. Do you think we should also include it for ol8 profiles? If so, I can quickly update it.
There was a problem hiding this comment.
Hi @Xeicker , do you think that is also necessary to update ol8 profiles in this case?
|
Merging as there has no movement on this PR in the past two-ish weeks. There should be no effective change by this PR. If we need to change things let's open another PR. I would happy to review it. |
3 participants
Description:
Product agnostic control files should include rules relevant for multiple products since there is already a mechanism that allows products to refine control file selections on their profile levels, without need to include Jinja2 macros in control files.
One side-effect of using Jinja2 macros in control files is that make it harder for integrations to process these files directly from the repository, specially when the information changed by macros is not necessary for integrations.
The issue was noticed and impacted the integration between CaC content and trestle-bot project, which is a project to transform CaC <-> OSCAL.
Rationale:
When consuming the SSG library externally it is not trivial to properly process Jinja2 macros as in the building system.
Since there is already a mechanism to refine profiles without using Jinja2, this simplification make it much easier to enable integrations.
Review Hints:
Ideally some new rules, specially for RHEL 10, should be included in the control files but it would demand all other products consuming the same control file to unselect new rules. So, to avoid issues, the rules were treated directly on the relevant products, preserving the existing behavior.
The goal was to remove Jinja2 macros from control files in order to more easily process these files with external integrations.