Document setuptools direct-CVE pkg_resources coupling in prisma-taurus history

Author: RafaelGuevaraCA

.claude/skills/prisma-taurus/vulnerability_history.md

@@ -307,6 +307,8 @@ The first attempt removed net-imap 0.5.8's gemspec + lib dir but **not** its cac
 #### setuptools-vendored findings (`Path` under `…/setuptools/_vendor/…`) are blocked by `pkg_resources` (verified 2026-06-30)
 `wheel` and `jaraco.context` are vendored *inside* setuptools, so the only way to clear them is to bump the `setuptools==` pin in `requirements.txt` to a release whose `_vendor` ships the fixed versions. **But there is a coupling that blocks this:** the first setuptools that vendors a patched `wheel` (82.0.1 vendors wheel 0.46.3 and drops `jaraco.context` entirely) is also new enough to have **removed `pkg_resources`** — and `setup.py` does `import pkg_resources` / `pkg_resources.parse_requirements(...)` at build time, with `build-artifacts.sh` running `python3 ./setup.py sdist bdist_wheel` **without build isolation**. So bumping setuptools to clear these vendored CVEs would break the wheel build. Until `setup.py` stops using `pkg_resources` (e.g. switch to `packaging.requirements`), **defer** the vendored `wheel`/`jaraco.context` findings and list them — they are low-value (one medium, one low) and not worth a build-tooling refactor inside a CVE run. Check the candidate setuptools wheel's `_vendor` contents (`unzip -l setuptools-<v>.whl | grep _vendor`) and its `pkg_resources/` presence before deciding.
 
+> **Extension (2026-07-14, scan 178):** the same coupling now also blocks a **direct setuptools CVE**, not just the vendored ones. CVE-2026-59890 (setuptools itself, `Path` `…/setuptools-<v>.dist-info`, fixed in **83.0.0**) can only be cleared by bumping the `setuptools==` pin in `requirements.txt` — but 83.0.0 is well past the 82.0.1 line that removed `pkg_resources`, so the pin bump would break the no-isolation `setup.py` wheel build exactly as above. `setup.py:16` still `import pkg_resources` (verified this run). So `setuptools`, `wheel`, and `jaraco.context` are **all three** deferred together until `setup.py` is refactored off `pkg_resources`. The real unblock (one small change clearing all three) is: rewrite `setup.py`'s `pkg_resources.parse_requirements(...)` using `packaging.requirements.Requirement`, then bump the setuptools pin. Worth doing as its own PR, not inside a CVE run.
+
 ### When a Java jar has a CVE — check the `Path` first
 - **If the `Path` is under `/root/.bzt/jmeter-taurus/` or `/root/.bzt/gatling-taurus/` → OUT OF SCOPE. Do not fix.** These jars (netty, log4j, tika, batik, xstream, jackson, logback, pebble, dnsjava, json-smart, json-path, commons-*, …) ship *inside* the JMeter/Gatling distributions. They are not individually pinned, and **bumping `JMeter.VERSION` / `Gatling.VERSION` is not an acceptable fix**: it only partially clears the CVEs (the bundled versions still lag the fixed ones), adds runtime/behavioral risk unit tests don't catch, and a JMeter bump that makes `VERSION == VERSION_LATEST` drops coverage and trips the `codecov/project` gate (see the 2026-06-18 run). List them as monitor-only.
 - **Only the jars Taurus downloads itself** (the `JarTool` subclasses in `bzt/modules/java/tools.py` — TestNG, JUnit, Hamcrest, etc.) are fixable by editing a version constant. These are JMeter-side test tooling; in practice still prefer leaving them unless there's a specific reason. If you do fix one: