Stabilization of v0.1.50
by Vojtech Polasek
Hello all,
*Release of Content version 0.1.50 is scheduled for May 15th*, so I've
created a stabilization branch for it.
Now is a good time to hunt for bugs and propose fixes for them. Starting
today, merged Pull Requests should be assigned to milestone v0.1.51. As
the branch has been created on Wednesday May 6, I also moved closed pull
requests created after this date to 0.1.51 milestone.
Bug fixes should be proposed to master and labeled "bugfix", they will
be cherry-picked to the stabilization branch.
Please note that we plan to release version 0.1.51 earlier than usual.
The release is planed on June 19th 2020 with stabilization starting on
June 5th.
Best regards,
Vojta
3 years, 11 months
The Machine Platform Great Controversy
by Matej Tyc
Hello everybody,
there are now numerous PRs upstream now that disable the machine platform
designation of certain rules - see
https://github.com/ComplianceAsCode/content/pulls?q=is%3Apr+is%3Aopen+pla...
Historically, this project uses one profile that is intended to scan both
running systems and container images. Obviously, scanning of lifeless
filesystems (a.k.a offline scanning) is limited, and the machine platform
has been used to control rule applicability to such environments (i.e.
environments other than running bare-metal systems or VMs).
This way is cheap, a bit dirty, and the following categories of rules ended
up being machine-only:
1. Rules that are not applicable in containers, or rules that represent
serious antipatterns (e.g. kernel-related rules, partition-related rules)
2. Rules that can't be checked for in offline scans due to OVAL
limitations (anything that requires the /proc filesystem)
3. Rules that represent a likely antipattern (systemd in containers)
4. Rules that OpenSCAP can't properly offline-scan.
It is quite clear that in case No. 4, removal of the machine platform is
the right thing to do, although it is likely to cause problems elsewhere.
However, it is at best questionable in case 3. For example, there is a way
to determine whether we are scanning a filesystem of a systemd-powered
container, and execute the check accordingly, but until all the bits are in
place, removing the platform from the rule will make the situation worse
for the majority of use cases.
Therefore, I suggest that we reach a consensus about what to do with those
PRs, as they are making the list of open PRs difficult to navigate in.
My proposal is to close all PRs that touch rules falling into categories
1-3, as those PRs don't make the situation any better.
3 years, 11 months
