-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAP constraints conflicting in the local-definition/objects-and-methods #2059
Comments
I asked the community for input on this issue and no preference on how to address it was provided from the community. Since a patch v1.1.3 is being prepared and this bug needs to be addressed, I'll remove both conflicting constraints and who needs them can enforce them as external constraints. |
OK so to confirm, you still want feedback on this issue and no change has been made in a developer repository? (That could be with or without a pull request and I could not find anything, that is why I am asking to make sure I clearly understand the ask here.) |
@iMichaela it is unclear to me what I find no documentation on its purpose, although I see where it has a cardinality of exactly 1. It does not show in any allowed-values list where it would normally have some type of description. There is a 'method' property in the catalog syntax which has an optional So I believe it is under-defined/under-documented. At a minimum, the cardinality enforcement of the property should be removed until it is better documented and exercised. |
The allowed values listed in the error ('alt-identifier, label, marking, sort-id') are the generic allowed values made available to every OSCAL prop. This portion of the content should have the same structure and constraints as
I do not see any indication that the |
THIS is incorrect:
"assessment" is not the depreciated allowed value. "method" is. |
It appears that many of the rules for control syntax are defined in the catalog metaschema instead of the controls-common metaschema. Most of these constraints also apply to profiles ( I believe the correct resolution is to move these constraints from the |
The problem with applying these to alter in profiles is that alter is cumulative, meaning a statement added by a previous alter can be altered again. This creates a case where it may be difficult to write a constraint that checks this based on the source content, as the intermediate state is not exposed to the constraint. It's easier and probably better to apply the constraints when validating the resulting catalog. |
I am summarizing here the recommended direction to fix the bug:
|
I would prefer to comment on a PR that actually shows the changes. As I mentioned before, I believe that introducing these constraints in the profile, will cause problems. If I have a PR with these changes, I can make a test case that illustrates this. When will a PR be available to comment on? |
if it helps,
i believe this constraint is conflicting with another constraint |
@wandmagic Which other constraint is it conflicting with? |
@david-waltermire I was pairing with @wandmagic and have some questions, but this solution resolves constraint violations but could use some review, even from our side of the house. |
it conflicts with
|
The caution from @david-waltermire is fair, and I hadn't considered that when I was looking at the application of constraints. While I stand by my recommendation of moving the constraint rules into the controls-common, I also agree that any application of those constraints must be surgical, and not equally applied to everyplace that might create or manipulate control content. |
Just to be clear about my prior concerns, the surgical thing to do is fix them in the catalog model where they are. If they are moved to control common they will also apply to the profile model, which will likely cause breakage due to how alter statements work. In my view, the best course of action here is to hold this issue back from the patch release to allow for more exploration and consensus on the approach. This can be released in a later patch or minor release. I believe this is what @aj-stein-gsa was pushing for by leaving this out of his change proposal for 1.1.3. |
sounds good to me, i'm happy to implement the change once we decide what we want |
I agree with @david-waltermire, and as long as FedRAMP is aware of the bug, I can release 1.1.3 without it, BUT this bug has been raised to us (NIST) several times and we tried to get community's attention to agreeing to a direction for the fix. Since external constraints is a desired direction, we can look into it after 1.1.3, with high priority. The solution will have to be backwards compatible (like simply removing them from the models and relocating and address the conflicting constraints). Community's agreement, examples and testing are a must. |
We have developed a solid test harness for testing external constraints at FedRAMP. We would be glad to offer tuning up the OSCAL repo CI/CD with some of these improvements, including integrating the test harness for external OSCAL constraints. If NIST is amenable, we could make some PRs to do this. |
Thank you, We appreciate the support and we would like to work with the FedRAMP team as long as the harness is aligned with and is pushed to usnistgov OSCA-related repositories. There is also a timing concern - when to move the existing constraints (general ones, RMF, FedRAMP) outside the OSCAL models. The community impact will have to be analyzed first, and we will determine, in collaboration with the community members, when and how we will proceed. I envision huge impact on the entities that are not using the OSCAL schemas but rather parse the metaschema definitions to implement the constraints too. |
Describe the bug
The constraints defined for the
assessment-plan/local-definitions/object-and-methods/part/@name
andassessment-plan/local-definitions/object-and-methods/part/prop/@name
are conflicting.The following sample:
RETURNS:
When an attempt is made to fix the errors as shown below (even if it makes no sense from the data type perspective):
the following errors are returned:
A discussion on this topic exists here:
#1968
Who is the bug affecting
All SAP developers
What is affected by this bug
OSCAL Content, Modeling
How do we replicate this issue
Run validation on the provided SAP sample .
Expected behavior (i.e. solution)
To provide correct constraints
Other comments
n/a
Revisions
No response
The text was updated successfully, but these errors were encountered: