Skip to content
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

Python binary detected multiple times when only installed once #1579

Closed
zhill opened this issue Feb 16, 2023 · 0 comments · Fixed by #1583
Closed

Python binary detected multiple times when only installed once #1579

zhill opened this issue Feb 16, 2023 · 0 comments · Fixed by #1583
Assignees
Labels
bug Something isn't working

Comments

@zhill
Copy link
Member

zhill commented Feb 16, 2023

What happened: Running syft 0.71.0 on docker.io/python:3.8.16-slim-bullseye shows two python binaries detected using metadata, but there is only one python package installed in the image.

Excerpt of the output:

   "id": "13cfac8a95b7e087",
   "name": "python",
   "version": "3.8.16",
   "type": "binary",
   "foundBy": "binary-cataloger",
   "locations": [
    {
     "path": "/usr/local/include/python3.8/patchlevel.h",
     "layerID": "sha256:39b5a69e8d44abf84aba019903294efc77e2e51ccabe6d80338ad11152e6bfb6"
    }
   ],
   "licenses": [],
   "language": "",
   "cpes": [
    "cpe:2.3:a:python_software_foundation:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/python@3.8.16",
   "metadataType": "BinaryMetadata",
   "metadata": {
    "classifier": "cpython-source",
    "realPath": "/usr/local/include/python3.8/patchlevel.h",
    "virtualPath": "/usr/local/include/python3.8/patchlevel.h"
   }
  },
  {
   "id": "b5e7b1f8cbfb8da1",
   "name": "python",
   "version": "3.8.16",
   "type": "binary",
   "foundBy": "binary-cataloger",
   "locations": [
    {
     "path": "/usr/local/lib/libpython3.8.so.1.0",
     "layerID": "sha256:39b5a69e8d44abf84aba019903294efc77e2e51ccabe6d80338ad11152e6bfb6"
    }
   ],
   "licenses": [],
   "language": "",
   "cpes": [
    "cpe:2.3:a:python_software_foundation:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/python@3.8.16",
   "metadataType": "BinaryMetadata",
   "metadata": {
    "classifier": "python-binary-lib",
    "realPath": "/usr/local/lib/libpython3.8.so.1.0",
    "virtualPath": "/usr/local/lib/libpython3.8.so.1.0"
   }
  },

However, looking in the image I see only one install of python:

root@bd9ea8bb8768:/# whereis python
python: /usr/local/bin/python /usr/local/bin/python3.8-config /usr/local/bin/python3.8 /usr/local/lib/python3.8
root@bd9ea8bb8768:/# whereis python3
python3: /usr/local/bin/python3.8-config /usr/local/bin/python3.8 /usr/local/bin/python3 /usr/local/lib/python3.8

What you expected to happen:
I expect the output to have a single "python" package binary detected using either or both of the pieces of evidence from the 'python-binary-lib' and 'cpython-source' classifiers if they are operating on the same package's metadata.

Something like:

 {
   "id": "b5e7b1f8cbfb8da1",
   "name": "python",
   "version": "3.8.16",
   "type": "binary",
   "foundBy": "binary-cataloger",
   "locations": [
    {
     "path": "/usr/local/bin/python3.8",
     "layerID": "sha256:39b5a69e8d44abf84aba019903294efc77e2e51ccabe6d80338ad11152e6bfb6"
    }
   ],
   "licenses": [],
   "language": "",
   "cpes": [
    "cpe:2.3:a:python_software_foundation:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python:3.8.16:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/python@3.8.16",
   "metadataType": "BinaryMetadata",
   "metadata": {
    "classifier": "python-binary",
    "realPath": "/usr/local/bin/python3.8",
    "virtualPath": "/usr/local/bin/python3"
   }
  },

The above is just an example of something that would make sense, not exactly what I expect to see or even be possible.

I'm not sure how to make it clear which evidence (the lib or the cpython .h stuff) was used to determine the package, but the general approach I think could be to use those classifiers to determine the version of the python binary. I'm not sure how the paths could/should line up, but I think its better to be more narrowly constrained and correct than to report multiple entries.

Steps to reproduce the issue:
syft docker.io/python:3.8.16-slim-bullseye -o json=sbom.json

Anything else we need to know?:

Environment:

  • Output of syft version:
Version:            0.71.0
JsonSchemaVersion:  6.2.0
BuildDate:          2023-02-09T19:40:41Z
GitCommit:          88c81d33edc67b0b9636d0046417a9373ac8b74f
GitDescription:     v0.71.0
Platform:           darwin/arm64
GoVersion:          go1.19.5
Compiler:           gc
  • OS (e.g: cat /etc/os-release or similar):
@zhill zhill added the bug Something isn't working label Feb 16, 2023
@kzantow kzantow self-assigned this Feb 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants