Fixing inverted fields in HTML report

[Arden97]

Description:

• Fixing a XSL template, responsible for incorrect/inverted fields in the report tables

Wrong table content examples:

Example XML object, that is processed by a template:

<ind-def:textfilecontent54_object id="oval:ssg-obj_pam_faillock_password_auth_pam_faillock_account:obj:1" version="1" comment="Check common definition of pam_faillock.so in account section of password-auth">
    <ind-def:filepath operation="pattern match">^/etc/pam.d/password-auth$</ind-def:filepath>
    <ind-def:pattern operation="pattern match" var_ref="oval:ssg-var_pam_faillock_password_auth_pam_faillock_account_regex:var:1" var_check="all"/>
    <ind-def:instance datatype="int">1</ind-def:instance>
</ind-def:textfilecontent54_object>

Rationale:

• Originaly, template would select any var_ref attribute in a textfilecontent54_object and print it's value in to the first table column
• After that, it would print other values in to the remaining columns, ignoring pattern field, for the lack of plain text value
• Fixes Filepath and Pattern are inverted in html reports #2245, RHEL-104073.

Review Hints:

• Fixed tables:

NOTE: This PR fixes described issue on Jira, but there are other issues related to this XSL template. Remaining issues, that were noticed (extra columns):

[jan-cerny]

It looks like your change fixes most of the cases of the "inverted fields" in HTML report that are caused by elements referencing variables.

[jan-cerny]

If during an evaluation of an OVAL test there were multiple variables evaluated and tested, then there are multiple oval-res:tested_variable elements. This solution prints all of them here and glues them together. That's wrong, only one of them should be printed here. Specifically, we should print here the value for the variable specified by the @var_ref attribute of the object child element. This situation happens for example in rule audit_rules_unsuccessful_file_modification_chmod.

[jan-cerny]

It seems to me that this is wrong and thanks to this being wrong the rest of the code works as expected 😄 in our example of rule accounts_passwords_pam_faillock_audit but might or might not work in other rules.

An OVAL object element (here in the $object_info variable) can have multiple child elements and all of them can have the @var_ref attribute. In the example of rule accounts_passwords_pam_faillock_audit it's never the first child, it's always the second child that has the attribute, therefore this variable is always null, and as a result the following xsl:if block isn't executed. That causes that the items are rendered correctly. But, for other rules this might not be the case, sometimes the first child references a variable using a @var_ref attribute as well.

It seems that this xsl:variable and the whole following xsl:if block can be removed completely.

[Arden97]

Yeah, I've come to the same conclusion. Last commit should take care of all mentioned issues. I've also added a check, that will print all of the referenced variables line by line, if more than one variable with the same id exist ( like with no_password_auth_for_systemaccounts rule for example).

[jan-cerny]

I have generated HTML report from my scan results using this code. Then I have reviewed the OVAL test details for many rules. I have found that all details are displayed correctly and no columns are swapped.

The CI fail on Ubuntu is caused probably by an outdated test mock but isn't caused by the contents of this PR.

[evgenyz]

@Arden97 Please create backport PR for maint-1.3 branch, we want these changes to be present in RHEL8/9 as well.