# Revisiting ownership-by-file-overlap relationships

**URL:** <https://anchorecommunity.discourse.group/t/revisiting-ownership-by-file-overlap-relationships/137>\
**Category:** General\
**Created:** [September 16, 2024, 7:05pm UTC](https://anchorecommunity.discourse.group/t/revisiting-ownership-by-file-overlap-relationships/137 "2024-09-16T19:05:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kzantow](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/kzantow/32/17_2.png) [@kzantow](https://anchorecommunity.discourse.group/u/kzantow)\
**Post date:** [September 16, 2024, 7:05pm UTC](https://anchorecommunity.discourse.group/t/revisiting-ownership-by-file-overlap-relationships/137/1 "2024-09-16T19:05:37Z")

</div>

Today, in Syft we have a number of catalogers that end up having overlap in the packages they surface and the files they read. An example of this is: a user installs `curl` with a package manager and the RPM cataloger finds this package, but the binary cataloger _also_ finds the `curl` binary and creates a second package of a different type. When this happens, Syft _by default_ will create an [`ownersip-by-file-overlap` relationship](https://github.com/anchore/syft/blob/b9efac4d78dd44f847901da3aa4ff85dd83d1edc/syft/artifact/relationship.go#L8) between these packages, and a post-cataloging process _by default_ will remove the secondary packages based on this relationship, so users don’t typically see the binary version but only the more correct package-manager version.

As far as I can tell, this deduplication is useful in order to:

- provide the best SBOM to the end user, and by association:
- avoid vulnerability false positives due to more accurate information from package manager vulnerability feeds and the versions used

Beyond these purposes, I’m having a hard time finding the value of the relationships. Maybe Syft has an option to disable the deduplication if a user _really_ wants that, but why not just have a specific function to do so without adding relationships only to later remove them?

We really want Grype to only match on the package manager versions, but there’s already [a custom function to filter these out](https://github.com/anchore/grype/blob/1fb6199dd254c213606347e2c09685bde6123e71/grype/pkg/package.go#L99), but this only works because Grype knows which feeds provide better results and making part of that determination in Syft seems like the wrong place to do it.

So, this is all pretty long-winded way of asking: should we get rid of the `ownership-by-file-overlap` relationship altogether and simply have deduplication functionality that operates without these relationships?

---

<div class="post-metadata">

**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\
**Post date:** [November 26, 2024, 10:05pm UTC](https://anchorecommunity.discourse.group/t/revisiting-ownership-by-file-overlap-relationships/137/2 "2024-11-26T22:05:40Z")

</div>

As an aside, it looks like from [Exclude-binary-overlap-by-ownership flag is not working](https://anchorecommunity.discourse.group/t/exclude-binary-overlap-by-ownership-flag-is-not-working/248) some users expect that the exclude binary files by ownership overlap will _already_ remove other packages.

> [@kzantow](#):
>
> Beyond these purposes, I’m having a hard time finding the value of the relationships. Maybe Syft has an option to disable the deduplication if a user _really_ wants that, but why not just have a specific function to do so without adding relationships only to later remove them?

I think the concern here is that if I’m on a distro that only reports vulns after they’re patched, and I install an OS package that brings with it a Python package, then GHSA on the Python package is the best source of vulnerability data I have until the distro releases a patch or changes their reporting policy.