Stop building -ds-1.2.xml data streams #11990
Conversation
This patch moves the call function upgrade_ds_to_scap_13 to compose_ds because building SCAP 1.3 data streams becomes the only option.
We don't need to upgrade content to SCAP 1.3, we can create an SCAP 1.3 data stream directly.
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
Start a new ephemeral environment with changes proposed in this pull request: Fedora Environment Oracle Linux 8 Environment |
|
🤖 A k8s content image for this PR is available at: Click here to see how to deploy itIf you alread have Compliance Operator deployed: Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and: |
|
Code Climate has analyzed commit 60333ec and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 59.4% (0.0% change). View more on Code Climate. |
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
Description:
This change will stop building the -ds-1.2.xml data streams.
These data streams are marked as SCAP 1.2 data streams, but they aren't SCAP 1.2 compatible, because they contain OVAL 5.11 which isn't a part of SCAP 1.2 line of standards.
These data streams differ in the value of
scap-versionandschematron-versionattributes and they don't have separate component for the remote checks used in rulessecurity_patches_up_to_date, the remote OVAL check is referenced directly in the rule. Otherwise they are the same as the -ds.xml files.Users should use
-ds.xmlfiles instead. They're SCAP 1.3 data streams. SCAP 1.3 is widely adopted and we package the SCAP 1.3 data streams in downstream.For more details, please read commit messages of each commit.
Rationale:
Simplify, streamline, stop producing legacy artifacts.