SCAP Security Guide v0.1.22 is now live

Greg Elin gregelin at gitmachines.com
Thu May 7 21:40:29 UTC 2015


Very exciting to SSG Content expanding!

Interim publishing of the built XML files sounds pretty useful. 

Greg Elin
P: 917-304-3488
E:  gregelin at gitmachines.com

Sent from my iPhone

> On May 7, 2015, at 2:39 PM, Jan Lieskovsky <jlieskov at redhat.com> wrote:
> 
> 
> Hello Martin,
> 
>  to follow up on this.
> 
> ----- Original Message -----
>> From: "Martin Preisler" <mpreisle at redhat.com>
>> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
>> Cc: "Jan Lieskovsky" <jlieskov at redhat.com>
>> Sent: Monday, May 4, 2015 7:48:02 PM
>> Subject: Re: SCAP Security Guide v0.1.22 is now live
>> 
>> ----- Original Message -----
>>> From: "Jan Lieskovsky" <jlieskov at redhat.com>
>>> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
>>> Sent: Monday, May 4, 2015 7:18:48 PM
>>> Subject: SCAP Security Guide v0.1.22 is now live
>>> 
>>> Hello folks,
>>> 
>>>  we are pleased to announce SCAP Security Guide of version 0.1.22.
>> 
>> \o/
>> 
>>> [snip]
>>> 
>>> [*]  Users are encouraged to test these && report the issues found.
>>> [**] See BUILD.md for guidance wrt to obtaining RPMs.
>> 
>> Could you please build it and attach a zip and the RPMs to the tag?
>> If we consider remote scanning use-cases these users may not have
>> all the build tools necessary to produce RPMs. They may be using
>> Windows or MacOS X or a distribution that doesn't use RPM.
>> 
>> GitHub allows making releases out of tags and attaching files to them,
>> see https://github.com/OpenSCAP/scap-workbench/releases/tag/1.1.0
>> for an example.
> 
> Right, you are correct the GitHub recently supports inclusion of also
> "binary" data to the release tags. That's not the problem though.
> 
> The issue is to ship also RPM files on GitHub together with particular
> release we would need to set up and manage signing server instance
> and set up a policy for sharing the key used to sign those RPMs (across
> all the users who can create the release).
> 
> Since this is a not trivial (and time consuming) task for now we are not
> planning to ship also RPM packages with upstream GitHub releases. But
> to make the life of content users a bit easier (hopefully), we decided to
> (together with existing source code tarball) to ship / provide also another
> tarball / zip archive with the XML files being expanded already. In other words
> tar / zip archive where the user can download all the XML OVAL / XCCDF / 
> Datastream files already built (in the form they would have been obtained after issuing
> the ```make / make dist``` command for particular product). This tarball / zip
> would produce expanded versions of XML benchmark files for all currently
> supported products (from top of head briefly mentioning RHEL/5, RHEL/6,
> RHEL/7, Fedora, Java, Firefox, and Chrome SCAP content). The zips could be
> uniquely identified with associated MD5 / SHA256 sum information coupled
> with them (provided in the same GitHub release tag directory as the expanded
> XML zip archive).
> 
> I will explore possibilities how to automatically create such a tarball,
> when preparing new upstream release.
> 
> Hope the above being helpful.
> 
> Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Technologies Team
> 
>> 
>> --
>> Martin Preisler
>> Security Technologies | Red Hat, Inc.
> -- 
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list