You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user, I would like a warning or error to be thrown when attempting to include a group.
As someone new to profile resolution, I would like explicit feedback that profile resolution cannot operate on groups.
As an example, consider the following excerpt:
<?xml version="1.0" encoding="UTF-8"?>
<profilexmlns="http://csrc.nist.gov/ns/oscal/1.0"uuid="c0dc468c-934e-4fe9-b5bf-9fc63f5a2915">
<metadata>
<title>Sample Security Profile
<em>for Demonstration</em> and Testing
</title>
<last-modified>2023-04-10T10:31:28.355446-04:00</last-modified>
<version>1.0</version>
<oscal-version>1.04</oscal-version>
<revisions/>
<remarks>
<p>The following document is used in the OSCAL Profile Tutorial and builds on the catalog created for the OSCAL Catalog Tutorial</p>
</remarks>
</metadata>
<importhref="https://raw.githubusercontent.com/usnistgov/oscal-content/main/examples/catalog/xml/basic-catalog.xml">
<include-controlswith-child-controls="yes">
<with-id>s1.1</with-id>
</include-controls>
</import>
</profile>
The above profile excerpt will not yield a resolved catalog with all of the children of the group "s1". Instead, the current behavior is to fail silently and omit the import directive entirely:
<?xml version="1.0" encoding="UTF-8"?>
<catalogxmlns="http://csrc.nist.gov/ns/oscal/1.0"uuid="00000000-0000-4000-B000-000000000000">
<metadata>
<title>Sample Security Profile
<em>for Demonstration</em> and Testing
</title>
<last-modified>2023-04-10T13:42:11.870528-04:00</last-modified>
<version>1.0</version>
<oscal-version>1.04</oscal-version>
<revisions/>
<propname="resolution-tool"value="OSCAL Profile Resolver XSLT Pipeline OPRXP"/>
<linkhref="file:/Users/naw2/Documents/repos/oscal/OSCAL_upstream/scratch/output-basic-profile-copy.xml"rel="source-profile"/>
<remarks>
<p>The following document is used in the OSCAL Profile Tutorial and builds on the catalog created for the OSCAL Catalog Tutorial</p>
</remarks>
</metadata>
</catalog>
For catalogs that rely on groups of groups (such as the above example) this can cause quite a bit of confusion.
Goals
When a user attempts to resolve a profile and an "include-controls" or "exclude-controls" block references a group, throw a warning or error that this inclusion will be ignored/is invalid.
All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
The text was updated successfully, but these errors were encountered:
@galtm comments welcome. I don't think this should be very hard in the XSLT Profile Resolver. We could generalize to throw the warning whenever a control-id fails to target a control.
We could generalize to throw the warning whenever a control-id fails to target a control.
I think this suggestion is worth doing. It would help in case of a misunderstanding as in the user story described here, as well as the case of a typo in the with-id value. This enhancement would be simplest to make on top of #1549, which is also about error handling.
User Story
As a user, I would like a warning or error to be thrown when attempting to include a group.
As someone new to profile resolution, I would like explicit feedback that profile resolution cannot operate on groups.
As an example, consider the following excerpt:
The above profile excerpt will not yield a resolved catalog with all of the children of the group "s1". Instead, the current behavior is to fail silently and omit the import directive entirely:
For catalogs that rely on groups of groups (such as the above example) this can cause quite a bit of confusion.
Goals
Dependencies
The same behavior is present on the OSCAL CLI: usnistgov/oscal-cli#126
Acceptance Criteria
The text was updated successfully, but these errors were encountered: