You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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...
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
The text was updated successfully, but these errors were encountered: