SCAP Security Guide v0.1.22 is now live

Jan Lieskovsky jlieskov at redhat.com
Thu May 7 18:39:17 UTC 2015


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.
> 


More information about the scap-security-guide mailing list