patch: updated stix2 module name

[aryabharat]

Revamped Module Name to Enhance Compatibility: misp-lib-stix2

In response to a conflict arising from the coexistence of the official stix2 package and misp-lib-stix2, we've made a strategic adjustment by updating the stix2 module name to misp_lib_stix2. This modification is pivotal to prevent clashes between the two packages, as both share the same name but contain distinct code.

By implementing this change, users can seamlessly use the stix2 and misp-stix libraries concurrently without encountering conflicts. Subsequently, we plan to initiate a separate pull request in the misp-stix package to seamlessly handle the name update.

We appreciate your attention to this matter and welcome any additional feedback or requirements you may have.

[aryabharat]

@rpiazza can you have a look at it.

[rpiazza]

Hi @aryabharat -

I'm not familiar with the MISP fork of the STIX2 API, so I don't know how different it is, and if this is the best thing to do to solve your problem. I'm not sure why the MISP STIX2 API couldn't be a dependency and then you add on top the things that are special to MISP in a different package.

But I guess it is up to CIRCL to approve :-)

[aryabharat]

@rpiazza
I've also highlighted a this concern within the official MISP misp-stix package, regarding the custom stix2 package dependency issue. GitHub Issue #58.

Your assistance in expediting the resolution process would be greatly appreciated. Could you kindly provide support to accelerate the resolution?

Thank you in advance for your prompt attention to this matter.

[chrisr3d]

I get your point on the concurrent use of both libraries, but there is no situation where you want to use them both in the same environment.

The reason why this fork exists is quite simple:
With MISP, we see users trying to ingest STIX 2.x content from different sources, which are not always validating properly their data. It causes issues on MISP.
The typical issue we faced multiple times was on the objects id validation, more specifically the UUID part. The official library has a strict UUID validation - aligned with the standard's requirement - which was quite often the reason of the error.
I mean we have no issue with this STIX standard requirement, as MISP shares the same requirement on the content that is produced by the platform. But blocking content from external producers was an issue that we had to fix, as we still wanted to be able to import the data, even though there was an invalid object id.
The fork comes here to avoid loading issues on this kind of STIX 2.x content with invalid object ids.
It is then misp-stix that handles the invalid UUIDs in order to avoid issues afterwards with the MISP validation process.

Now with that said, if you are using misp-stix, PyMISP, and/or MISP, they all come with the forked library for the reasons I explained above, and there is no need for the official library. On the other hand if you work on a STIX environment, with no MISP involved at all, there is no need for the forked library.

If you still want, for any reason, to use both libraries, I would suggest to use them separately in two different python environments, in which case the only change would be to switch between pip install stix2 and pip install misp-lib-stix2.
By the way, as the only actual change between both versions is an optional argument called interoperability which is used for object ids validation only, you can still use the forked library - if you use MISP and STIX together - and skip the argument. There will be no other different compared with the official library then.

Let me know if you have further comments

[aryabharat]

@chrisr3d
I appreciate your comprehensive explanation of the rationale behind the forked library and its importance within the MISP context. Your insights have shed light on the critical role the forked library plays in addressing issues related to STIX 2.x content with invalid object IDs.

While working with stix-slider, which relies on stix2 as a dependency, we encountered a conflict arising from the coexistence of the official stix2 package and misp-lib-stix2. Running these components in separate environments is not a practical solution for our use case.

Taking into account the challenges posed by potential conflicts, I would like to propose a suggestion for your consideration. Given the likelihood of users inadvertently installing both the official stix2 package and misp-lib-stix2 in the same environment, there exists a risk of confusion. To alleviate this concern, could we explore the possibility of updating the name of the misp-lib-stix2 package? A revised name, such as "misp-stix2" or "misp-stix2-lib," would help eliminate ambiguity and distinctly convey its association with MISP.