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/865a88f7cbac07560a8c8450f57e426cfbeff537
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
[email protected]
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:[email protected]]
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" <[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.
>
>
>
> 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
>
>
>
> [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/
Disclaimer
The information contained in this communication from
[email protected] sent at 2015-05-27 09:40:10 is confidential and
may be legally privileged.
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/
