<div dir="ltr"><div>Branching is not a bad idea. We could also develop platform build code that could handle specific version/os use cases as another option.<br><br></div>Gabe<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 7:00 AM, Steve Grubb <span dir="ltr">&lt;<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday, April 22, 2015 10:50:36 AM Šimon Lukašík wrote:<br>
&gt; And here comes the problem, SCAP-Security-Guide contains multiple<br>
&gt; separate guidances each for a different target (RHEL6, RHEL7, or<br>
&gt; Fedora). Majority of contributors are used to build all the guidances by<br>
&gt; a single build process on RHEL6 or RHEL7.<br>
<br>
</span>Perhaps its time for a branch in SSG. One for OVAL 5.10 and one for OVAL 5.11.<br>
Then at some future point we can ship SSG and new openscap. to both RHEL6 and<br>
7. This is possible because legally there is no validated scanner for RHEL6 &amp;<br>
7. Any validation will be under some new release of SCAP because 1.2<br>
specifically limits validation to RHEL5. So, any validated scanner for RHEL6 or<br>
7 will be able to process the new content. I feel very comfortable in making<br>
this recommendation.<br>
<br>
The bridge between SCAP 1.2 and what&#39;s next will be the current generation of<br>
scanners. They can use he current OVAL 5.10 branch. I would only make<br>
important changes there as needed and focus mostly on 5.11 because that is<br>
what every product will have to certify to on RHEL6 or 7.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Steve<br>
</font></span><span class="im HOEnZb"><br>
&gt; At the time of writing neither RHEL6 nor RHEL7 tooling include support<br>
&gt; for OVAL 5.11. So, the tools on RHEL6 and RHEL7 will be limited in<br>
&gt; processing OVAL 5.11 (SSG/Fedora) content.<br>
&gt;<br>
&gt; At the same time, there is value in moving the edge and start building<br>
&gt; OVAL 5.11 (systemd) content for Fedora target. We will test systemd<br>
&gt; checks in Fedora and move them to RHEL7 STIG later on.<br>
&gt;<br>
&gt; Hence, it seems that the best way to proceed is buildtime magic: Build<br>
&gt; Fedora content only when the tools are capable building it. Downside is<br>
&gt; that RHEL6/RHEL7 contributors will not be able to build Fedora content<br>
&gt; (until OpenSCAP 1.2.2 update hits their systems)<br>
&gt;<br>
&gt; Jan Černý has already started adding systemd support to SSG/Fedora in<br>
&gt;<br>
&gt;      <a href="https://github.com/OpenSCAP/scap-security-guide/pull/527" target="_blank">https://github.com/OpenSCAP/scap-security-guide/pull/527</a><br>
&gt;<br>
&gt; Ideas?<br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
SCAP Security Guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a></div></div></blockquote></div><br></div></div></div></div>