On Wednesday, April 22, 2015 10:50:36 AM Šimon Lukašík wrote:
And here comes the problem, SCAP-Security-Guide contains multiple
separate guidances each for a different target (RHEL6, RHEL7, or
Fedora). Majority of contributors are used to build all the guidances by
a single build process on RHEL6 or RHEL7.
Perhaps its time for a branch in SSG. One for OVAL 5.10 and one for OVAL 5.11.
Then at some future point we can ship SSG and new openscap. to both RHEL6 and
7. This is possible because legally there is no validated scanner for RHEL6 &
7. Any validation will be under some new release of SCAP because 1.2
specifically limits validation to RHEL5. So, any validated scanner for RHEL6 or
7 will be able to process the new content. I feel very comfortable in making
this recommendation.
The bridge between SCAP 1.2 and what's next will be the current generation of
scanners. They can use he current OVAL 5.10 branch. I would only make
important changes there as needed and focus mostly on 5.11 because that is
what every product will have to certify to on RHEL6 or 7.
-Steve
At the time of writing neither RHEL6 nor RHEL7 tooling include
support
for OVAL 5.11. So, the tools on RHEL6 and RHEL7 will be limited in
processing OVAL 5.11 (SSG/Fedora) content.
At the same time, there is value in moving the edge and start building
OVAL 5.11 (systemd) content for Fedora target. We will test systemd
checks in Fedora and move them to RHEL7 STIG later on.
Hence, it seems that the best way to proceed is buildtime magic: Build
Fedora content only when the tools are capable building it. Downside is
that RHEL6/RHEL7 contributors will not be able to build Fedora content
(until OpenSCAP 1.2.2 update hits their systems)
Jan Černý has already started adding systemd support to SSG/Fedora in
https://github.com/OpenSCAP/scap-security-guide/pull/527
Ideas?