search

oasis-open / cti-python-stix2

OASIS TC Open Repository: Python APIs for STIX 2
https://stix2.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
356 stars 113 forks source link

Deprecated custom data marking not supported #522

Open rpiazza opened 2 years ago

rpiazza commented 2 years ago

This does not parse:

{ "created": "2016-08-01T00:00:00.000Z", "definition": { "level": "Confidential" }, "definition_type": "classification", "id": "marking-definition--0ee0838b-d40a-4c01-bde5-d0e502691764", "spec_version": "2.1", "type": "marking-definition" },

chisholm commented 2 years ago

What is your error? I tried it and got ValueError: definition_type must be a valid marking type. Looks like this occurred because "classification" was not registered as a custom marking. There are only builtin registrations for tlp and statement. Did you register a custom marking type?

rpiazza commented 2 years ago

I got the same error. No - I didn't know I had to register it

I'm running the slider - it has no idea what the STIX 1.2 input will be...

I guess I can catch the error...

chisholm commented 2 years ago

Would markings with definition types not described in the spec (e.g. tlp and statement) be considered "custom" in the deprecated chapter 11 sense? I didn't see anything that said they would be. Ch. 11 describes custom properties, objects, extensions, but not markings as far as I can see. So maybe all markings should be accepted regardless of allow_custom? I wonder if this is another library bug.

I think it's certainly undesirable for people to have to register stuff in advance to ensure that a parse() call doesn't error out. With large amounts of content which you didn't create, it's hard to know what's in there and what to register. Maybe we need to create a separate issue for this.

rpiazza commented 2 years ago

This is another issue with the way "custom" was handled in STIX 2.x - Data Markings had their own facility to add a new marking type - see section 7.2.1 (notice the definition_type property SHOULD be statement or tlp).

chisholm commented 2 years ago

Yeah, so "custom" has a specific (deprecated) meaning, described in chapter 11. That adjective was never applied to "marking". There is no such thing as a "custom marking", as far as the spec is concerned. So I guess any compliant marking should be parseable, regardless of allow_custom. I'll create a separate issue.

chisholm commented 2 years ago

Created issue #523 .