Describe the bug
An object that accepts oval-def:filter should have a rule asserting the referenced state is of the matching type; a filter pointing at an unrelated state is meaningless. Sixteen objects across eight schemas have no such rule, so a mistyped filter reference validates as clean.
AIX is the clearest case: 9 of its objects accept a filter and only 3 have the assertion.
Replication Steps
- Extract and compile the Schematron for one of the schemas below.
- Validate a document where the object's
oval-def:filter references a state of a different type.
- No
failed-assert is produced.
Expected behavior
Every filter-bearing object has a rule matching the shape already used elsewhere in the same schemas:
<sch:rule context="aix-def:inittab_object//oval-def:filter">
<sch:let name="reffed_state" value="ancestor::oval-def:oval_definitions/oval-def:states/*[@id=$state_ref]"/>
<sch:assert test="(($state_namespace='...#aix') and ($state_name='inittab_state'))">...</sch:assert>
</sch:rule>
Content
| Schema |
Object |
Expected state |
aix-definitions |
deviceattribute_object |
deviceattribute_state |
aix-definitions |
inittab_object |
inittab_state |
aix-definitions |
securitystanza_object |
securitystanza_state |
aix-definitions |
useraccount_object |
useraccount_state |
aix-definitions |
nfso_object |
nfso_state |
aix-definitions |
no_object |
no_state |
asa-definitions |
tcp_map_object |
tcp_map_state |
iosxe-definitions |
interface_object |
interface_state |
junos-definitions |
xml_config_object |
xml_config_state |
macos-definitions |
launchd_object |
launchd_state |
macos-definitions |
nvram512_object |
nvram512_state |
netconf-definitions |
config_object |
config_state |
panos-definitions |
config_object |
config_state |
windows-definitions |
license_object |
license_state |
windows-definitions |
peheader_object |
peheader_state |
windows-definitions |
systemmetric_object |
systemmetric_state |
The macos, netconf and panos entries overlap #339: rules exist but their contexts name objects that do not exist (macos_object, netconf_object, paloalto_object), so correcting the context supplies the missing assertion.
OVAL details
- Schema:
aix-definitions, asa-definitions, iosxe-definitions, junos-definitions, macos-definitions, netconf-definitions, panos-definitions, windows-definitions
Describe the bug
An object that accepts
oval-def:filtershould have a rule asserting the referenced state is of the matching type; a filter pointing at an unrelated state is meaningless. Sixteen objects across eight schemas have no such rule, so a mistyped filter reference validates as clean.AIX is the clearest case: 9 of its objects accept a filter and only 3 have the assertion.
Replication Steps
oval-def:filterreferences a state of a different type.failed-assertis produced.Expected behavior
Every filter-bearing object has a rule matching the shape already used elsewhere in the same schemas:
Content
aix-definitionsdeviceattribute_objectdeviceattribute_stateaix-definitionsinittab_objectinittab_stateaix-definitionssecuritystanza_objectsecuritystanza_stateaix-definitionsuseraccount_objectuseraccount_stateaix-definitionsnfso_objectnfso_stateaix-definitionsno_objectno_stateasa-definitionstcp_map_objecttcp_map_stateiosxe-definitionsinterface_objectinterface_statejunos-definitionsxml_config_objectxml_config_statemacos-definitionslaunchd_objectlaunchd_statemacos-definitionsnvram512_objectnvram512_statenetconf-definitionsconfig_objectconfig_statepanos-definitionsconfig_objectconfig_statewindows-definitionslicense_objectlicense_statewindows-definitionspeheader_objectpeheader_statewindows-definitionssystemmetric_objectsystemmetric_stateThe macos, netconf and panos entries overlap #339: rules exist but their contexts name objects that do not exist (
macos_object,netconf_object,paloalto_object), so correcting the context supplies the missing assertion.OVAL details
aix-definitions,asa-definitions,iosxe-definitions,junos-definitions,macos-definitions,netconf-definitions,panos-definitions,windows-definitions