Very exciting to SSG Content expanding! Interim publishing of the built XML files sounds pretty useful.
Greg Elin P: 917-304-3488 E: [email protected] Sent from my iPhone > On May 7, 2015, at 2:39 PM, Jan Lieskovsky <[email protected]> wrote: > > > Hello Martin, > > to follow up on this. > > ----- Original Message ----- >> From: "Martin Preisler" <[email protected]> >> To: "SCAP Security Guide" <[email protected]> >> Cc: "Jan Lieskovsky" <[email protected]> >> 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" <[email protected]> >>> To: "SCAP Security Guide" <[email protected]> >>> 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
