Jan, I like what you are suggesting. I want to confirm two points.
First the share directory is only relevant during the build process; the look into share directory only occurs during the build when the oval source code is missing. Second, what is the chance an oval rule will have the same name/Identifier for two Linux distributions that need different tests or test criterion? Or will this not happen bc it can be handled by having one oval Id for distribution A and a second oval Id for distribution B even if rule has same name? Greg Greg Elin P: 917-304-3488 E: [email protected] Sent from my iPhone > On Apr 9, 2015, at 8:31 AM, Jan Lieskovsky <[email protected]> wrote: > > Hello Trey, > > ----- Original Message ----- >> From: "Trey Henefield" <[email protected]> >> To: "[email protected]" >> <[email protected]> >> Sent: Wednesday, April 8, 2015 11:13:48 PM >> Subject: Shared Checks/Fixes ... >> >> Greetings, >> >> >> >> I wanted to propose a change to the current structure in place for shared >> checks (shared/oval) and fixes (shared/fixes/bash). I was curious to get >> everyone’s opinion before committing. > > Thank you for opening this topic. > >> >> >> >> So the problem I see is with the symbolic linking of checks and fixes to the >> shared folder. I have found it problematic when working between different >> operating systems, file systems, and version control systems. > > Right from the beginning we knew the concept of symbolic links will > introduce issues when dealing with SSG content across multiple OS versions. > But so far there hasn't been urgent need to fix this (to be read as so far > there haven't been much reports current behaviour causing issues for > developers). > But as the count of the SCAP content products raises it's time to fix this. > >> >> >> >> Rather than creating symbolic links to certain oval checks in the shared/oval >> folder, we could choose to just process all oval checks in both the >> project’s checks folder and the shared/oval folder. > > The original idea behind introducing /shared directory was the following - > when trying to identify corresponding OVAL check for particular XCCDF rule > the following scheme should be applied: > * when there's is OVAL check for that product present in input/checks > directory for that product, this OVAL check should be used with priority, > * when there isn't, use the corresponding (equally named) OVAL check from > shared/ directory. > > During the time we advanced the idea / concept even more in the sense that > shared/ version of OVAL checks doesn't necessarily need to be working for > all of the products having these checks (that's the case below mentioning > there are shared/ OVAL checks used just for RHEL-7 & Fedora systems, while > RHEL-6 version is different / RHEL-6 product specific). > >> >> >> >> However, not all checks in the current ‘shared/oval’ folder are shared by all >> OS. For example, there are some that only apply to RHEL7 and Fedora, and not >> RHEL6. > > See the explanation above why that's the case. > >> >> >> >> Any thoughts? > > If I should attempt to summary: > * the concept of shared/ checks has proven to be beneficial (in the sense it's > less work to keep just one concrete copy updated than try to keep updated > multiple > identical copies), > * the mechanism of symbolic links is not the way to go (since it's known not > to work > e.g. on Microsoft Windows OS systems), > > So IMHO we want to keep the shared/ OVAL checks / fixes concept, but > implement it > different way. Maybe as already suggested by modificating the build process > to look > not just into CWD for OVAL check / remediation fix, but also to look into > particular > subdirectory of shared/ directory (OVAL checks vs fixes) simultaneously with > preserving > priority (if there's OVAL check / fix present for that product, use that one. > If there > isn't and there's is symlink, use the /shared version. If there isn't even > symlink, > return no check / no fix available leading to 'notchecked' state). > > HTH > > Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > P.S.: As the count of products we produce SCAP content for is only going to > raise in the future, IMHO concept of /shared directory for OVAL checks & > fixes can only save us a lot of duplicate work in the future (when > compared > to the scenario of managing multiple copies of the same file on per > product > basis). > >> >> >> >> Thanks! >> >> >> >> Best regards, >> >> >> >> >> >> Trey Henefield, CISSP >> >> Senior IAVA Engineer >> >> >> >> Ultra Electronics >> >> Advanced Tactical Systems, Inc. >> >> 4101 Smith School Road >> >> Building IV, Suite 100 >> >> Austin, TX 78744 USA >> >> >> >> [email protected] >> >> Tel: +1 512 327 6795 ext. 647 >> >> Fax: +1 512 327 8043 >> >> Mobile: +1 512 541 6450 >> >> >> >> www.ultra-ats.com >> >> >> >> >> >> >> Disclaimer >> The information contained in this communication from >> [email protected] sent at 2015-04-08 17:13:55 is private and may >> be legally privileged or export controlled. It is intended solely for use by >> [email protected] and others authorized to receive >> it. If you are not [email protected] you are hereby >> notified that any disclosure, copying, distribution or taking action in >> reliance of the contents of this information is strictly prohibited and may >> be unlawful. >> >> >> -- >> 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/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
