RHV and host support
by Watson Sato
Hello,
Security Content for el7 and el8 systems are not the same, for example,
there is support for crypto-policies in el8, and method to enable FIPS mode
is different for each.
And currently "rhv4
<https://github.com/ComplianceAsCode/content/tree/master/rhv4>" product is
focused on el7, and it is expected to be supported for quite some time.
Question: How can we better support el8 based hosts?
One way is to "split" rhv4 product into two, creating one product for el7
based hosts and another for el8 based hosts.
At the moment, the contents for RHV and RHEL are very similar, but as
content for RHV improves there may be the need for RHV specific content.
This approach would allow freedom for RHV content to grow and become
specific as needed, while sharing content with their respective base
enterprise linuxes.
Thoughts?
--
Watson Sato
Security Technologies | Red Hat, Inc
4 years
Stabilization of v0.1.48
by Watson Sato
Hello all,
Time for release of v0.1.48 is close, so the stabilization branch has been
created.
The release is scheduled to happen at the beginning of next week, at the
latest on 14.02.2020.
Last time we followed approach of merging fixes to the stabilization
branch, and them merge the stabilization branch to master.
But that showed potential to really complicate the merge of the fixes back
into master.
This approach also left master hanging out with the bugs discovered during
the stabilization phase until after the release was finished, which is not
ideal.
So this time we propose to do the fixes on master branch and cherry pick
them to the stabilization branch.
The next version milestone is 0.1.49, please use it when resolving issues
and pull requests from now.
When a PR is cherry picked into the stabilization branch, change the
milestone to 0.1.48, so that it is easy to track in which version a patch
was released.
--
Watson Sato
Security Technologies | Red Hat, Inc
4 years, 3 months
Packit and Fedora spec file of SSG
by Matěj Týč
Hello everybody,
recently, the 5000th PR [1] of the ComplianceAsCode project landed,
proposing the Packit CI support. Packit uses the Fedora spec file [2],
i.e. source of the RPM package, in the test process.
The discussion in that PR centered around handling of the spec file - it
now became possible to have it in the repository, syncing it with the
Fedora server, or Packit would pull it from the Fedora repository
whenever it is needed. Both ways have theirs pros and cons, and as you
can read in [1], some members of the community raised concerns that the
current way of how the spec file is handled encumbers the community.
So if this is also your case, please let us know how having the spec
file upstream would change the situation for you. For the sake of
completeness, nowadays we update the package every time we make an
upstream release, and we issue a build and respective update right after.
References:
[1]: https://github.com/ComplianceAsCode/content/pull/5000
[2]:
https://src.fedoraproject.org/rpms/scap-security-guide/blob/master/f/scap...
4 years, 3 months
