-
Notifications
You must be signed in to change notification settings - Fork 99
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
Invalid UUIDs cause java.lang.IllegalArgumentException in enhanced oscal-cli #823
Comments
Thank you for the bug report, we will look into this. It would like this may be a processing model issue with the metaschema-framework version of the oscal-cli. If we do post an issue and a potential fix there, I will be sure to cross-reference them here once triage is complete. |
@Telos-sa, to triage further, can you please run the same command as before in the initial report with the following commands: oscal-cli --version And then most importantly this variation of the command. oscal-cli validate FedRAMP\ SSP\ -\ 24.03\ \(2024-10-25T133816Z\).json --show-stack-trace We do not have an error with that custom message in the relevant code base, so we need the full stack trace to determine which caller code in our libraries leverages a dependency library that emits that exception with a complete call stack in the stack trace. Thanks in advance for your help and cooperation. |
Note to team review this issue: I have marked this issue blocked until we get more feedback from the reporting party. Further triage can occur once we know more. |
@aj-stein-gsa It looks like some lines of the stack trace were omitted - any way to get it to display everything?
Here is the by-component section that is causing this error as well:
|
@Telos-sa The stack trace you provided is fine. Thanks for the quick turn around! |
The problem is in |
Changed expected behavior in unit test to provide null values in JSON and empty values in XML, which is consistent with current behavior. Improved error handling for data type conformance issues. Related to GSA/fedramp-automation#823.
Changed expected behavior in unit test to provide null values in JSON and empty values in XML, which is consistent with current behavior. Improved error handling for data type conformance issues. Related to GSA/fedramp-automation#823.
For @aj-stein-gsa need to revisit the output and confirm improved error handling in 2.3.0 or newer release of |
Tried another snapshot release of 2.3.1 and it is still reporting the same error as repeated. Will follow up in the upstream project as this is an issue with |
Will keep this in the blocked state until I determine next steps on whether this fix was in scope for a 2.3.1 fix or not. |
…more consistent error reporting for data type related errors. Addresses GSA/fedramp-automation#823
… more consistent error reporting for data type related errors. Addresses GSA/fedramp-automation#823
… more consistent error reporting for data type related errors. Addresses GSA/fedramp-automation#823
… more consistent error reporting for data type related errors. Addresses GSA/fedramp-automation#823
… more consistent error reporting for data type related errors. Addresses GSA/fedramp-automation#823
Per metaschema-framework/metaschema-java#239 the upstream project has made the error handling message more precise, including limiting the stack trace for this given scenario and identifying the precise line with the issue. % oscal-cli --version
oscal-cli 2.3.1 built at 2024-11-09 22:03 from branch 626ab999e3ff69b81b3775d22d18f834d3c92638 (626ab99) at https://github.com/metaschema-framework/oscal-cli
liboscal-java built at 2024-11-09 21:49 from branch 32b8e398eab9fedd371fc4b3f1519170fb46a1d7 (32b8e39) at https://github.com/metaschema-framework/liboscal-java
oscal v1.1.2 built at 2024-11-09 21:49 from branch 4f02dac6f698efda387cc5f55bc99581eaf494b6 (4f02dac) at https://github.com/usnistgov/OSCAL.git
metaschema-java 2.0.1 built at 2024-11-09T21:13:35+0000 from branch 964b8456020ec810a0eb885208dda4584c660f9a (964b845) at https://github.com/metaschema-framework/metaschema-java
metaschema built at 2024-11-09T21:13:35+0000 from branch b6601f7430f83f1a53a11bf32575b69e131bc912 (b6601f7) at https://github.com/metaschema-framework/metaschema.git
% oscal-cli validate ssp-all-VALID.xml
Validating 'file:/home/me/fedramp-automation/src/validations/constraints/content/ssp-all-VALID.xml' as XML.
java.io.IOException: An unexpected error occurred during parsing: Malformed data 'Arbitrary string' at 334:7. Value 'Arbitrary string' is not a valid UUID.
% oscal-cli validate ssp-all-VALID.xml --disable-schema-validation
Validating 'file:/home/me/fedramp-automation/src/validations/constraints/content/ssp-all-VALID.xml' as XML.
java.io.IOException: An unexpected error occurred during parsing: Malformed data 'Arbitrary string' at 334:7. Value 'Arbitrary string' is not a valid UUID. I will close as not planned even though it is resolved because there was no immediate change to FedRAMP data, documentation, or tools. I hope this improvement helps. |
This relates to ...
What happened?
When validating an OSCAL SSP that has invalid UUIDs with the oscal-cli v2.2.0, the validation yields an illegal argument exception:
java.lang.IllegalArgumentException: Invalid UUID string: Amazon RDS (MariaDB/MySQL/Postgres)
This should yield a validation error saying that the provided UUID did not match the regular expression for UUID data type - similar to what the base oscal-cli v1.0.3 from NIST provides:
Relevant log output
No response
How do we replicate this issue?
Validate an OSCAL SSP that has an invalid UUID format for a by-component>component-uuid element
Where, exactly?
Other relevant details
No response
The text was updated successfully, but these errors were encountered: