Hello folks,
----- Original Message -----
From: "Martin Preisler" <mpreisle(a)redhat.com>
To: "SCAP Security Guide" <scap-security-guide(a)lists.fedorahosted.org>
Sent: Thursday, April 9, 2015 2:34:38 PM
Subject: Re: Shared Checks/Fixes ...
----- Original Message -----
> From: "Simon Lukasik" <isimluk(a)fedoraproject.org>
> To: "SCAP Security Guide"
<scap-security-guide(a)lists.fedorahosted.org>
> Sent: Thursday, April 9, 2015 10:09:39 AM
> Subject: Re: Shared Checks/Fixes ...
>
> [snip]
>
> I propose
>
> * to remove symlinks
> * to amend build process to look into shared directory if fix/check is
> missing in current directory
JFYI the aforementioned change has been now implemented for OVAL checks for
RHEL/6, RHEL/7, and Fedora products. The underlying pull request for further
review and testing is available here:
[1]
https://github.com/OpenSCAP/scap-security-guide/pull/566
Testing / review appreciated.
To the idea behind that change, the RHEL/6, RHEL/7, and Fedora final OVAL
definition file build process has been amended to not rely on symbolic links
(which has shown to be not portable solution), and instead of that is using
an intermediary build directory (placed during build into
"build/$(PROD)_checks"
directory to get the final list of OVAL checks to be included for that product).
Also the information previously tracked via symlink presence is now stored in
the <platform> element of particular OVAL shorthand format implementation
(e.g. if at least one of the <platform> elements contains
"multi_platform_all",
"multi_platform_rhel", or "Red Hat Enterprise Linux 6" and product we
are
building for is "rhel6", then the underlying OVAL check will / would be
included).
Important Note: The currently existing symlinks in RHEL/6/input/checks,
RHEL/7/input/checks,
and Fedora/input/checks directories have been kept intact (since I needed
them to verify if the count of included checks before and after would
match).
They will be removed in some of the future PRs (once the [1] change is
merged
upstream).
Feel free to give [1] further testing / review, so we can fix issues, should
there arise some.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Of course, once merged, the appropriate change should be performed for the shared/
remediation fixes too. But due the existing scope of this change already, have
decided
to split this into multiple PRs.
>
> That should be the easiest path that enables flexibility and lower maint
> costs going forward.
+1
--
Martin Preisler
Security Technologies | Red Hat, Inc.
--
SCAP Security Guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/