Profile resolver not applying alterations to parameters

[Rene2mt]

Describe the bug

When using the XSLT profile resolver (v1.0.4), the produced resolved profile catalogs does not apply the changes to the param specified in the profile.

Who is the bug affecting

FedRAMP and anyone using XSLT profile resolver v1.0.4

What is affected by this bug

Tooling & API

How do we replicate this issue

NOTE - the issue is when using XSLT profile resolver (version 1.0.4)

1. Use a catalog with parameters (e.g., FedRAMP's rev resolved profile catalog)
2. Create a profile that tries to add a prop to parameters as follows:
3. Conduct profile resolution (e.g. through a tool like Oxygen XML or OSCAL-CLI)

Expected behavior (i.e. solution)

Notice that it works when the prop elements are added via <set-parameter param-id="parameter-ids">...</set-parameter> . This is the approach in gist https://gist.github.com/Rene2mt/de339c61034da0b81860ab5c13bc702a#file-sample-profile-xml-L54-L1868.

BUT it does not work when trying to use <alter control-id="control-id"><add position="starting" by-id="param-id">...</add></alter>. This is the approach in gist https://gist.github.com/Rene2mt/de339c61034da0b81860ab5c13bc702a#file-sample-profile-xml-L1872-L4256

This should work according to the profile resolution spec.

Other comments

No response

Revisions

No response

[wendellpiez]

Let's see to it that the alter usage is unit tested against this.

The lapse (or bug if you like) is in XSLT https://github.com/usnistgov/OSCAL/blob/develop/src/utils/resolver-pipeline/oscal-profile-resolve-modify.xsl, where a template matching param elements (

OSCAL/src/utils/resolver-pipeline/oscal-profile-resolve-modify.xsl

Line 52 in 8bc3c00

<xsl:template match="param" priority="2">

) fails to do what other control descendants do (template matching control//* (

OSCAL/src/utils/resolver-pipeline/oscal-profile-resolve-modify.xsl

Line 127 in 8bc3c00

<xsl:template match="control//*">

), namely looking for its matching alterations and acting on them. (It does what is called for from set-param which is why that is a workaround.)

Solution is to see to it that the param template does what is called for, not only wrt set-param but also alter (and unit test).

[wendellpiez]

BTW if (or to the extent that) this gives rise to implementation questions such as what happens when compounding settings and alterations on a single parameter ... another reason to build unit tests ... and if this is tricky, maybe forbidding addressing parameters with alter is preferable.

[galtm]

I believe #1549 fixes this issue, and I added a relevant test scenario in that pull request.

[wendellpiez]

Fantastic! thanks!

[aj-stein-nist]

I believe #1549 fixes this issue, and I added a relevant test scenario in that pull request.

Will mark this as blocked until we merge this into develop and #1549 is merged into the develop branch and then a release.

[iMichaela]

This issue is probably safe to close after a sanity check.