Fix STIX version detection from dicts #337
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
without the spec_version property ought to be correctly detected as 2.1 now.
pre-commit add-trailing-comma library. Hopefully this satisfies the travis tests for other versions of python!
Codecov Report
@@ Coverage Diff @@
## master #337 +/- ##
==========================================
+ Coverage 98.12% 98.17% +0.04%
==========================================
Files 123 124 +1
Lines 13839 14168 +329
==========================================
+ Hits 13580 13909 +329
Misses 259 259
Continue to review full report at Codecov.
|
clenk
approved these changes
Feb 13, 2020
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #318 .
In particular, 2.1 SCOs without the spec_version property ought to be correctly detected as 2.1 now. This is done based on the presence of an ID property, and that their type is in the 2.1 observable type mapping.
The functionality is factored out into a dedicated function. This allows reuse, including recursive reuse when detecting bundle spec version from the spec versions of its contents. Also added a unit test suite specifically for this capability.
Note that scanning bundle contents is not currently strictly necessary for determining bundle spec version: if spec_version is present => 2.0, else 2.1. This is trivially detectable. I thought maybe the original scan was intended for future-proofing, under the assumption that a 2.1+ bundle would never be allowed to hold SCOs of a version later than the bundle spec version. So I kept it. That implies that 2.1+ bundle spec version could be computed as the max of the spec versions of its contents, with a 2.1 minimum. In theory, maybe the correct conclusion is the bundle spec version is not less than the max contained object spec version (so could be a range of versions greater or equal), but we are currently only dealing with two versions, 2.0 and 2.1, and I think some of the bridges are best crossed when we come to them. (In fact, that may argue for not bothering with a scan at all at this point.)