Hello folks, ----- Original Message ----- > From: "Martin Preisler" <[email protected]> > To: "SCAP Security Guide" <[email protected]> > Sent: Thursday, April 9, 2015 2:34:38 PM > Subject: Re: Shared Checks/Fixes ... > > ----- Original Message ----- > > From: "Simon Lukasik" <[email protected]> > > To: "SCAP Security Guide" <[email protected]> > > 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
