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