<HTML><BODY>
    <BR>
    <BR>
    Hi Jan,<BR>
<BR>
Thanks for your contribution!<BR>
<BR>
I do most of my building on RHEL6, so building wasn't that big of a concern for me. Although, the code currently doesn't build on RHEL5, due to some python methods not being supported in the python version available on RHEL5. But I currently don't use Windows for any building. I use it more or less for producing and editing XML/Shell content. We also use our own internal repository for code changes and checkins/checkouts become a little annoying when the symbolic links don’t carry over and have to be reproduced to build properly each time.<BR>
<BR>
Did you have a look at the commits I made on this issue?<BR>
<BR>
<a href="        https://github.com/OpenSCAP/scap-security-guide/commit/865a88f7cbac07560a8c8450f57e426cfbeff537" target="_blank">        https://github.com/OpenSCAP/scap-security-guide/commit/865a88f7cbac07560a8c8450f57e426cfbeff537</a><BR>
<BR>
The above commit removes all dependencies for links for both checks and remediations.<BR>
<BR>
The only thing left is to activate the change for each project using shared content. I have gotten a bit side tracked recently with other work and didn't have time to commit to that yet.<BR>
<BR>
The activation is simply adding parameters to the combinechecks.py and combinefixes.py commands within the makefile of a project.<BR>
<BR>
For example, in the Fedora project makefile, change the following two lines:<BR>
<BR>
$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml<BR>
<BR>
$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks  &gt; $(OUT)/unlinked-$(PROD)-oval.xml<BR>
<BR>
To state the following:<BR>
<BR>
$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml $(SHARED)/fixes/bash/<BR>
<BR>
$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks  $(SHARED)/oval 'multi_platform_fedora' 'Fedora 19' &gt; $(OUT)/unlinked-$(PROD)-oval.xml<BR>
<BR>
When the above change is done, it no longer relies on the symbolic links for checks and fixes of that project. However doing so seemed to uncover some other content issues that need to be addressed, before actually commiting. Just haven't had the time.<BR>
<BR>
Best regards,<BR>
<BR>
<BR>
Trey Henefield, CISSP<BR>
Senior IAVA Engineer<BR>
<BR>
Ultra Electronics<BR>
Advanced Tactical Systems, Inc.<BR>
4101 Smith School Road<BR>
Building IV, Suite 100<BR>
Austin, TX 78744 USA<BR>
<BR>
<a href="mailto:Trey.Henefield@ultra-ats.com">Trey.Henefield@ultra-ats.com</a><BR>
Tel: +1 512 327 6795 ext. 647<BR>
Fax: +1 512 327 8043<BR>
Mobile: +1 512 541 6450<BR>
<BR>
<a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
<BR>
-----Original Message-----<BR>
From: Jan Lieskovsky [mailto:jlieskov@redhat.com] <BR>
Sent: Friday, May 22, 2015 9:06 AM<BR>
To: Trey Henefield<BR>
Cc: SCAP Security Guide<BR>
Subject: Re: Shared Checks/Fixes ...<BR>
<BR>
<BR>
Hello Trey,<BR>
<BR>
  this change wrt to OVAL checks and RHEL/6, RHEL/7, and Fedora/ products have been implemented now (see my reply in the other thread.<BR>
The corresponding change for remediations to come yet).<BR>
<BR>
But wanted to double-check yet another point - would the decommission / replacement of symbolic links mechanism sufficient for your developer environment, or would also other changes be desired? To speak more exactly, the current Makefiles use more tools (like xmllint, xmlwf), which might be Unix specific (not available natively on other platforms).<BR>
<BR>
Can you clarify which tools are you utilizing when developing SSG content on Microsoft Windows systems? Are the tools like MinGW and / or Cygwin required to be able to develop SSG content on Microsoft Windows?<BR>
<BR>
Asking just to know if we should amend the Makefiles code to be platform aware - IOW it to start using solely only tools / commands available on that platform natively without the need to install additional ones.<BR>
<BR>
If there would be further interest for this (hopefully) sometime in the future we could explore what could be done to make the developer's life on other platforms easier too.<BR>
<BR>
Thank you &amp;&amp; Regards, Jan.<BR>
--<BR>
Jan iankko Lieskovsky / Red Hat Security Technologies Team<BR>
<BR>
----- Original Message -----<BR>
&gt; From: &quot;Trey Henefield&quot; &lt;trey.henefield@ultra-ats.com&gt;<BR>
&gt; To: &quot;scap-security-guide@lists.fedorahosted.org&quot; <BR>
&gt; &lt;scap-security-guide@lists.fedorahosted.org&gt;<BR>
&gt; Sent: Wednesday, April 8, 2015 11:13:48 PM<BR>
&gt; Subject: Shared Checks/Fixes ...<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Greetings,<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; I wanted to propose a change to the current structure in place for <BR>
&gt; shared checks (shared/oval) and fixes (shared/fixes/bash). I was <BR>
&gt; curious to get everyone’s opinion before committing.<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; So the problem I see is with the symbolic linking of checks and fixes <BR>
&gt; to the shared folder. I have found it problematic when working between <BR>
&gt; different operating systems, file systems, and version control systems.<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Rather than creating symbolic links to certain oval checks in the <BR>
&gt; shared/oval folder, we could choose to just process all oval checks in <BR>
&gt; both the project’s checks folder and the shared/oval folder.<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; However, not all checks in the current ‘shared/oval’ folder are shared <BR>
&gt; by all OS. For example, there are some that only apply to RHEL7 and <BR>
&gt; Fedora, and not RHEL6.<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Any thoughts?<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Thanks!<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Best regards,<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Trey Henefield, CISSP<BR>
&gt; <BR>
&gt; Senior IAVA Engineer<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Ultra Electronics<BR>
&gt; <BR>
&gt; Advanced Tactical Systems, Inc.<BR>
&gt; <BR>
&gt; 4101 Smith School Road<BR>
&gt; <BR>
&gt; Building IV, Suite 100<BR>
&gt; <BR>
&gt; Austin, TX 78744 USA<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <a href="mailto:Trey.Henefield@ultra-ats.com">Trey.Henefield@ultra-ats.com</a><BR>
&gt; <BR>
&gt; Tel: +1 512 327 6795 ext. 647<BR>
&gt; <BR>
&gt; Fax: +1 512 327 8043<BR>
&gt; <BR>
&gt; Mobile: +1 512 541 6450<BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; <BR>
&gt; Disclaimer<BR>
&gt; The information contained in this communication from <BR>
&gt; <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a> sent at 2015-04-08 17:13:55 is private<BR>
&gt; and may be legally privileged or export controlled. It is intended <BR>
&gt; solely for use by <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a> and<BR>
&gt; others authorized to receive it. If you are not <BR>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a> you are hereby notified<BR>
&gt; that any disclosure, copying, distribution or taking action in <BR>
&gt; reliance of the contents of this information is strictly prohibited and may be unlawful.<BR>
&gt; <BR>
&gt; <BR>
&gt; --<BR>
&gt; SCAP Security Guide mailing list<BR>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><BR>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><BR>
&gt; <a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><BR>

    <BR>
    <BR>
 <p><font size="1"><b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif">Disclaimer</font></b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif"><br/>
        The information contained in this communication from </font></font><font color="#666666" size="1" face="Verdana, Arial, Helvetica, sans-serif"><b>
          trey.henefield@ultra-ats.com
          </b> sent at
          2015-05-27
          09:40:10
          is private and may be legally privileged or export controlled. It is intended solely for 
          use by <b>
            scap-security-guide@lists.fedorahosted.org
            </b> and others 
          authorized to receive it. If you are not <b>
            scap-security-guide@lists.fedorahosted.org
            </b> 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.</font><br>
          <br>
    </BODY></HTML>