Closed bjsmiley closed 2 months ago
incremental's pyproject.toml
just specifies the minimum version of setuptools that it will work with, in API terms. It's not necessary to bump it in order for you to have a newer setuptools in your environment. You should just tell poetry to upgrade it.
Thank you for the quick reply and suggestion. Closing this issue as it does not appear to be an issue with incremental per your answer.
I've attempted to update any packages relying on setuptools but with no luck. It also appears poetry does not allow for overriding transitive packages https://github.com/python-poetry/poetry/issues/697.
As far as I can see, that issue is more about ignoring conflicts, and I don't see any obvious conflicts in your poetry show --tree
output. Can you not do poetry add 'setuptools>=70.0.0'
to declare that your application specifically wants at least that version, which should then cause Poetry to update it (or tell you why it can't)?
Ok something fishy is definitely going on on my side. I ran your suggested command and then shared a bunch of other commands and sanity checks I ran afterwards. the tldr is the python tool safety
tells me the setuptools vuln is gone. our docker image scanner, trivy
, tells me the vuln is still there. BUT, azure image scans and vanta image scans tell me the vuln is gone. So I am going to consider this a false positive by trivy and the vuln resolved. Thank you for the assistance with this, was a big python TIL for me.
running the command:
➜ poetry add 'setuptools>=70.0.0'
Updating dependencies
Resolving dependencies... (0.3s)
No dependencies to install or update
Writing lock file
confirming everything is up to date:
➜ poetry update
Updating dependencies
Resolving dependencies... (2.8s)
No dependencies to install or update
checking what changes were made:
➜ git diff
diff --git a/tools/webscraper/poetry.lock b/tools/webscraper/poetry.lock
index b7e6e53..9c8869f 100644
--- a/tools/webscraper/poetry.lock
+++ b/tools/webscraper/poetry.lock
@@ -1536,4 +1536,4 @@ testing = ["coverage (>=5.0.3)", "zope.event", "zope.testing"]
[metadata]
lock-version = "2.0"
python-versions = ">=3.10, <3.12"
-content-hash = "e00844026257747e25e415808edb4114601511526697b67b97f35481337b059c"
+content-hash = "518935d68ca857ba9c581254332fd863089c13f81a16c870ebc0b4c765b0fd2f"
diff --git a/tools/webscraper/pyproject.toml b/tools/webscraper/pyproject.toml
index 4fa38d8..addae1c 100644
--- a/tools/webscraper/pyproject.toml
+++ b/tools/webscraper/pyproject.toml
@@ -12,6 +12,7 @@ uvicorn = "^0.27.0.post1"
python-magic = "^0.4.27"
scrapy = "^2.11.2"
scrapy-playwright = "^0.0.41"
+setuptools = ">=70.0.0"
[tool.poetry.group.dev.dependencies]
black = "^24.3.0"
Hello, I've scanned my python application for vulnerabilities and am seeing a HIGH vuln coming from setuptools as a transitive package.
If i am reading my application's dependency tree correctly, the vulnerable setuptools comes from the incremental package.
I see in the last build of incremental,
setuptools>=61.0
is used (to be fair, I am not sure what an isolated environment refers to in this context)I am not primarily a python developer so I apologize if I am on the wrong track, but if incremental is referencing a vulnerable version of setuptools, would it be possible to release a new version of incremental with setuptools upgraded to >= 70.0.0 to resolve the vuln? I appreciate any help you can offer.