Bug report
Bug description:
Part of #112302
Currently pip's package entry in the SBOM is quite simple, including only itself but not all the vendored projects and their licenses/IDs. See comment from @hroncok on DPO on why this is problematic: https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293/24
My proposed changes to generate_sbom.py is the following:
- Find the entry
pip/_vendor/vendor.txt in the pip wheel archive.
- Read the content, parse the requirements into names and versions.
- Ensure all entries are represented as packages in the SBOM with a
pip DEPENDS_ON <package> relationship.
This approach lets the license identifiers be specified in the SBOM like other packages but then would raise an error if pip is upgraded with a difference in vendored dependencies or versions allowing the reviewer to acknowledge any changes.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Bug report
Bug description:
Part of #112302
Currently pip's package entry in the SBOM is quite simple, including only itself but not all the vendored projects and their licenses/IDs. See comment from @hroncok on DPO on why this is problematic: https://discuss.python.org/t/create-and-distribute-software-bill-of-materials-sbom-for-python-artifacts/39293/24
My proposed changes to
generate_sbom.pyis the following:pip/_vendor/vendor.txtin the pip wheel archive.pip DEPENDS_ON <package>relationship.This approach lets the license identifiers be specified in the SBOM like other packages but then would raise an error if pip is upgraded with a difference in vendored dependencies or versions allowing the reviewer to acknowledge any changes.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs