Closed maybe-sybr closed 4 years ago
Here's an example of the nested identifiers using archive-ext
:
import stix2.v21
ad = stix2.v21.Directory(path="archived/path")
f_obj = stix2.v21.File(name="foo", extensions={
"archive-ext": {
"contains_refs": [ad, ],
}
})
f_ref = stix2.v21.File(name="foo", extensions={
"archive-ext": {
"contains_refs": [ad.id, ],
}
})
print(f_obj.serialize(pretty=True))
print(f_ref.serialize(pretty=True))
Outputs:
{
"type": "file",
"id": "file--7e26ad71-b261-5289-a8e3-3d7126321233",
"name": "foo",
"extensions": {
"archive-ext": {
"contains_refs": [
"{\n \"type\": \"directory\",\n \"id\": \"directory--c1af83bc-164d-546d-8a73-207f7ad87324\",\n \"path\": \"archived/path\",\n \"spec_version\": \"2.1\"\n}"
]
}
},
"spec_version": "2.1"
}
{
"type": "file",
"id": "file--916b26ba-65fd-5d95-95d7-866d24c9f98e",
"name": "foo",
"extensions": {
"archive-ext": {
"contains_refs": [
"directory--c1af83bc-164d-546d-8a73-207f7ad87324"
]
}
},
"spec_version": "2.1"
}
Interestingly, this also exposes another handling bug where the referenced Directory isn't rendered by its ID! So the deterministic IDs for the Files are different, and the serialised File which referenced the Directory object was incorrectly serialised.
Thank you @maybe-sybr; both of these issues you found should now be fixed in master
and will be included in the next release.
Thanks for all these fixes, @clenk and @chisholm . Much appreciated!
As shown in the following example:
outputs:
Note that the supposedly deterministic IDs for the two serialised File SCOs are different. This is caused by the handling of instances of
_STIXBase
in thekwargs
passed to_STIXBase._generate_id()
. When (in this example), the parent directory SCO is passed to_generate_id()
, it makes a deep copy and adds that to thestreamlined_obj_vals
list which is canonicalised on a later line (which is also problematic, see #395). The deep copy of the STIX object being referenced is obviously not equivalent to the serialised reference itself, resulting in the variance in the generated ID for each object.This can could presumably be naively fixed by making
_generate_id()
aware ofReferenceProperty
s (which I'd suggest be done since it's an easy win), but that would still leave open a potential issue where aReferenceProperty
is nested within some other ID contributing property. As a concrete example, sinceFile
SCOs include their extensions as an ID contributing property, aReferenceProperty
nested within an extension (e.g. a custom extension constructed similarly to my example code in #395) would be similarly mishandled.