Skip to content
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

revision 2 JSON Schema errors #27

Open
dunkeki opened this issue Mar 27, 2024 · 1 comment
Open

revision 2 JSON Schema errors #27

dunkeki opened this issue Mar 27, 2024 · 1 comment

Comments

@dunkeki
Copy link

dunkeki commented Mar 27, 2024

Sorry for the use of my personal GH account, but Peraton prefers that I avoid using my work email for things :)

In any case, I'm Kirk Dunkelberger, the primary author of the Peraton TAXII server. Our server optionally performs strict validation on incoming STIX objects being posted to collections. The MITRE validator is optionally applied and, for objects with custom extensions (which the MITRE validator doesn't check), we have a second layer of validation which uses the JSON Schema pointed to by the corresponding extension-definition schema member (if present).

That's a long way around the barn to get to this issue. I've taken the extension-definition objects in BehaviorBundle and objects that reference them (in the same bundle which is something I'd like to discuss with all folk using custom extensions during Plugfest), and patched them to have absolute references for $ref fields which you caveat emptor in one of your read me files. Once your new schema are installed in the "right" spot, I know those will be corrected and those are not the point of this issue.

Yes, I'm getting to it, sorry...

There are (meta schema-based) errors in several of the schema. I'll just use the first few hex digits to identify the specific ones...

  • BBC1* has a trailing comma in the vicinity of line 38
  • 5ccc* also has a trailing comma around line 87
  • f9db* has an items member which is malformed. items is not an array, it is a single, valid schema. Remove the surrounding array to fix...
  • dbbc* has same items problem
  • c469* dittos

in fact, double check that all items elements meet the meta schema, thanks

After patching my local copies manually (I didn't think you wanted me to potentially mess up your repo), I tried to validate a single object for each. All worked with the exception of 3b75*. Both connections and score are specified as type string, but the property values (for both) were numbers in the example object. Don't know if that's my validator being too strict, but they are indeed numbers in the test object...should those properties be type number?

Thanks for hanging on through this whole thing. If you'd like to talk directly about any/all of this, I'm at the email used for creating this issue or, more formally, at kirk.dunkelberger@peraton.com. My cell is 260 409-8039 if you want to be very direct.

Thanks for all your work on these extensions. To find just these few errors in such a large body of work is impressive...

Kirk

@kkarolenko
Copy link
Collaborator

Thanks a bunch for the feedback, that's really helpful!

Regarding the trailing commas, those have been patched for our upcoming revision 3 release.
Regarding the malformed items issue, it looks like all but one schema have been patched, so I'll be sure to correct that one. Thank you!
The detection-group object has also been reworked after discussion with group members and will be deprecated.
Regarding the connections and score, it looks like we've changed connections to a number in our upcoming revision 3 release but need to update score as well. You are right, they have both been numbers in all instances and the schema should reflect that.

Thanks again for sending all of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants