Resolve duplicated OVAL tests created by new templating system

[yuumasato]

The template for service_enabled creates new criterions for package_installed instead of extending.

If a rule for the package installed already exists, this will end up creating two similar OVAL objects: test_service_fapolicyd_package_fapolicyd_installedand test_package_fapolicyd_installed

<ns8:rpminfo_object id="oval:ssg-obj_test_service_fapolicyd_package_fapolicyd_installed:obj:1" version="1">
    <ns8:name>fapolicyd</ns8:name>
</ns8:rpminfo_object>

<ns8:rpminfo_object id="oval:ssg-obj_test_package_fapolicyd_installed:obj:1" version="1">
    <ns8:name>fapolicyd</ns8:name>
</ns8:rpminfo_object>

Originally posted by @yuumasato in https://github.com/ComplianceAsCode/content/pull/4820

[ggbecker]

The problem of using extend definition here would be that the package name can differ from distro to distro and the rule id of that extend definition is always the same for a package installed rule, what changes is just the package name in template section for example. So it would not be that simple to just start using the extend definition. Unless a new attribute for the service templated rules is introduced to map to which rule is the counterpart installed/removed package.

[marcusburghardt]

I believe we can close this old issue. It doesn't seem still worth to work on this. Do you agree @ggbecker and @yuumasato ?

[yuumasato]

Could you clarify why it is not worth solving this?

My understanding is that this object duplication can lead to miss-alignments between package_installed, package_removed, service_enabled, service_disabled rules, and increased data stream size. (They are not critical issues, but require functional tests to catch, and it can be annoying to have follow up PRs aligning the rules).

This can probably be solved when OVAL tests,objects and states are more reusable in general. Are there plans is to track duplicates in that effort?

[jan-cerny]

My opinion is that the misalignment between package_installed, service_disabled and other similar rules should be handled on the template parameters level, it should be always carefully reviewed what options are passed to the template in rule.yml.

Reusability of the OVAL content should be achieved by intensive usage of macros, platforms and templates IMO.

So I think that the remaining problem that we have is the increased data stream size caused by this issue. I think that it's a serious problems. Large data streams are processed slowly by oscap, increase memory requirements of oscap, cause slow automatus testing etc. I think we surely need to address the large data stream size. The vision is that it could be somehow addressed by the "OVAL Object model" effort. The idea is that once the build system will understand the OVAL structure and convert it to Python objects we could implement optimizing functions that operate on the top of these objects. So we could implement some function that removes the duplicate objects from the OVAL tree.

[marcusburghardt]

Could you clarify why it is not worth solving this?

My understanding is that this object duplication can lead to miss-alignments between package_installed, package_removed, service_enabled, service_disabled rules, and increased data stream size. (They are not critical issues, but require functional tests to catch, and it can be annoying to have follow up PRs aligning the rules).

This can probably be solved when OVAL tests,objects and states are more reusable in general. Are there plans is to track duplicates in that effort?

My point is not about not doing this, but is it worth the cost-benefit? As you said it is not critical and is open for more than 4 years without any action, so it doesn't seem that is needed or relevant enough up to now. Unless someone is planning to work on it soon (I don't know anyone), I see no reason to keep it open for another 4 years. So it can be closed as "Won't fix" now. We can consult at any time and reopen closed issues if necessary.