Hi Jan,
Thanks for your contribution!
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.
Did you have a look at the commits I made on this issue?
https://github.com/OpenSCAP/scap-security-guide/commit/865a88f7cbac07560a...
The above commit removes all dependencies for links for both checks and remediations.
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.
The activation is simply adding parameters to the combinechecks.py and combinefixes.py
commands within the makefile of a project.
For example, in the Fedora project makefile, change the following two lines:
$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml
$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks >
$(OUT)/unlinked-$(PROD)-oval.xml
To state the following:
$(SHARED)/$(TRANS)/combinefixes.py $(IN)/fixes/bash/ $(OUT)/bash-remediations.xml
$(SHARED)/fixes/bash/
$(SHARED)/$(TRANS)/combinechecks.py $(CONF) $(IN)/checks $(SHARED)/oval
'multi_platform_fedora' 'Fedora 19' >
$(OUT)/unlinked-$(PROD)-oval.xml
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.
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
Trey.Henefield(a)ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message-----
From: Jan Lieskovsky [mailto:jlieskov@redhat.com]
Sent: Friday, May 22, 2015 9:06 AM
To: Trey Henefield
Cc: SCAP Security Guide
Subject: Re: Shared Checks/Fixes ...
Hello Trey,
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.
The corresponding change for remediations to come yet).
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).
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?
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.
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.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
----- Original Message -----
From: "Trey Henefield"
<trey.henefield(a)ultra-ats.com>
To: "scap-security-guide(a)lists.fedorahosted.org"
<scap-security-guide(a)lists.fedorahosted.org>
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.
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.
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.
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.
Any thoughts?
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
Trey.Henefield(a)ultra-ats.com
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
trey.henefield(a)ultra-ats.com 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 scap-security-guide(a)lists.fedorahosted.org and
others authorized to receive it. If you are not
scap-security-guide(a)lists.fedorahosted.org 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
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
Disclaimer
The information contained in this communication from trey.henefield(a)ultra-ats.com sent at
2015-05-27 09:40:10 is confidential and may be legally privileged.
It is intended solely for use by scap-security-guide(a)lists.fedorahosted.org and others
authorized to receive it. If you are not scap-security-guide(a)lists.fedorahosted.org 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.