Multiple schematron false-positives

[zport]

@balleman commented on Fri Apr 20 2018

The fix for #192 appears to cause schematron validation failures for some reasonable definition and system characteristics content. Examples of undesired failures include:

ind-def:textfilecontent54_state/instance = 1
ind-sc:textfilecontent54_item/instance = 1
unix-def:file_state/group_id = 0
unix-sc:file_item/group_id = 0
unix-def:file_state/user_id = 0
unix-sc:file_item/user_id = 0
win-def:lockoutpolicy_state/force_logoff = 1800
win-sc:lockoutpolicy_item/force_logoff = 1800
win-def:lockoutpolicy_state/lockout_duration = 1800
win-sc:lockoutpolicy_item/lockout_duration = 1800
win-def:passwordpolicy_state/max_passwd_age = 864000
win-sc:passwordpolicy_item/max_passwd_age = 864000

---

@solind commented on Tue May 01 2018

Thanks for referencing the fix.

[yuumasato]

Hello,
I'm facing a problem related to this issue, scapval-1.3.2 reports that group_id and user_id cannot be zero.

Should OVALProject/Language#303 be ported over to this project?

[solind]

@wmunyan I think this should be merged, as discussed during today's call.

[shawndwells]

Bump. This bug is causing RHEL content to fail NIST content validation, preventing Red Hat from publishing NIST National Checklist content for RHEL7 and RHEL 8 (released today).

--- edit ---
To clarify, NIST is rejecting the content as failing SCAPval test suite, which requires strict conformance to the schema.

[solind]

Hi @shawndwells, this is a schematron issue, not a schema issue (although I know, the schematron rules are encoded in the schema). According to the rules of OVAL governance, it will take some time for even these minor changes to become official, although since both Joval and OpenSCAP already incorporate them, the change already has enough points to be considered "stable" once it's merged.

[shawndwells]

Yikes. If understanding correctly, it'll take some time for schema/schematron to be updated, after which NIST can update their scapval tool (additional time), and then Linux vendors can resume submission of Linux checklists.

[DavidRies]

Hi @shawndwells,

Yes, it sounds like--strictly speaking--your immediate problem is a NIST process / SCAPval issue. Obviously, any vendor/tool is free to implement these fixes themselves or by using schemas published by this community in pending PRs or any of our release streams (development, stable or official).

As per our current release processes, this will be fixed and released into the development branch. Then, the fix will roll into the "stable" branch on August 1 (our next scheduled stable release date). Following that, the OVAL board may select a stable release to be the "official" OVAL release.

I'm guessing that NIST requires SCAPval to support the "official" release, but I don't really know how it works in practice. I'd also guess you could work with them to make an exception for this issue.

We have redesigned the moderation process to be faster, more transparent and more inclusive than it used to be, but it's still a community-driven standards governance process. It's slower and more deliberative than a software release process by design. For example, it has built-in community review periods, semi-annual releases, etc. and doesn't have mechanisms for rapid hotfix style releases.

It's not that I don't care about this issue or don't want to help... I'm just not sure what the OVAL community can do to directly address your problem.

Thoughts?

-David