usnistgov/oscal-cli

Index-metadata-property-uuid error

Rene2mt opened this issue · 2 comments

Rene2mt commented

Describe the bug

OSCAL CLI is generating multiple "Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/prop[1]' and '/system-security-plan/metadata[1]/revision[1]/prop[1]'" errors.

Who is the bug affecting?

FedRAMP

What is affected by this bug?

Generating multiple false positive errors in FedRAMP templates

When does this occur?

When props in the metadata do not have UUID attribute specified

How do we replicate the issue?

Run OSCAL-CLI v0.3.3 on the template as follows

  1. Download attached sample SSP template
  2. Run command: oscal-cli ssp validate --as=xml /ssp/xml/FedRAMP-SSP-OSCAL-Template.xml
  3. See output errors:
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/prop[1]' and '/system-security-plan/metadata[1]/revision[1]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/revision[1]/prop[1]' and '/system-security-plan/metadata[1]/location[2]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/location[2]/prop[1]' and '/system-security-plan/metadata[1]/location[3]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/location[3]/prop[1]' and '/system-security-plan/metadata[1]/party[8]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[8]/prop[1]' and '/system-security-plan/metadata[1]/party[10]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[10]/prop[1]' and '/system-security-plan/metadata[1]/party[10]/prop[2]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[10]/prop[2]' and '/system-security-plan/metadata[1]/party[11]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[11]/prop[1]' and '/system-security-plan/metadata[1]/party[12]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[12]/prop[1]' and '/system-security-plan/metadata[1]/party[13]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[13]/prop[1]' and '/system-security-plan/metadata[1]/party[14]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[14]/prop[1]' and '/system-security-plan/metadata[1]/party[15]/prop[1]'
[ERROR] [/system-security-plan/metadata[1]] Index 'index-metadata-property-uuid' has duplicate key for items at paths '/system-security-plan/metadata[1]/party[15]/prop[1]' and '/system-security-plan/metadata[1]/party[16]/prop[1]

FedRAMP-SSP-OSCAL-Template.txt

Expected behavior (i.e. solution)

{A clear and concise description of what you expected to happen.}

Other Comments

{Add any other context about the problem here.}

aj-stein-nist commented

This is actually a bug in metaschema-java's handling of this constraint as used in the dependent OSCAL models in liboscal-java and OSCAL module for this version.

https://github.com/usnistgov/OSCAL/blob/11809d465c65ebbd8cdfceeaae193219ec5cabee/src/metaschema/oscal_metadata_metaschema.xml#L72-L73

Each UUID for a given prop is checked for uniqueness in the index and since there is no UUID declared, all similar props without UUID match nothing and fail this validating this constraint (as counterintuitive as that is since nothing is not a valid UUID, but this is a fixable bug for that reason).

This will be fixed when metaschema-java resolves this issue in usnistgov/metaschema-java#155, metaschema-java and liboscal-java modules will be moved up and new release drafted.

david-waltermire-nist commented

Fixed by incorporating the latest from metaschema-java (PR usnistgov/metaschema-java#171).

  • 👍1