-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include BomRef within Component hash calculation #678
base: main
Are you sure you want to change the base?
Conversation
this is considered a breaking change, as it changes existing behavior in a non-backwards-compatible way |
tests/test_real_world_examples.py
Outdated
json = json_loads(input_json.read()) | ||
|
||
bom = Bom.from_json(json) | ||
self.assertEqual(4, len(bom.components)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a disputable assertion.
the two of the components of the original BOM were duplicated in the first place, why keep them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the correct place for this to be disputed, is it part of the implementation or the spec discussion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is something that could be discussed here: https://github.com/CycloneDX/specification/discussions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where in the spec is it explained what the uniqueness criteria for components are?
And is it a bug that the libraries in other programming languages have implemented this differently, or is that also something that's an ongoing discussion?
this PR claims to solve #677
none of the added tests showcase this broken/fixed behaviour. |
this PR claims to solve #540 the original problem was
none of the added tests showcase this broken/fixed behaviour. |
1caaaf5
to
229585e
Compare
Fixes CycloneDX#540 Signed-off-by: wkoot <[email protected]>
Addresses CycloneDX#677 Signed-off-by: wkoot <[email protected]>
229585e
to
efcca53
Compare
@@ -1783,7 +1783,7 @@ def __hash__(self) -> int: | |||
self.mime_type, self.supplier, self.author, self.publisher, | |||
self.description, self.scope, tuple(self.hashes), | |||
tuple(self.licenses), self.copyright, self.cpe, | |||
self.purl, | |||
self.purl, self.bom_ref.value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see why you go with self.bom_ref.value
instead of self.bom_ref
.
BomRef.__hash__
exists and is implemented to account for the __id__
of the "empty" object entity, so that None
values are unequal.
Your implementation does not do so, and may cause unexpected behaviour here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed I had originally only added self.bom_ref
, but that would then not deduplicate the None
s. Is there a reason for the BomRef
hash to include the id? It seems superfluous when there is a unique identifier. Note also that the code claims a random UUIDv4 should have been assigned when there is no ref, but this is not actually the case
Would it be desirable to only include the |
breaking changes are embraced and not a stopper. it was just a remark. |
Fixes #540, #677