Record why the starlette advisories are pinned open - #10
Merged
Conversation
Pinning CI's Python tools by hash made the resolved dependency set visible to Scorecard's vulnerability scanner for the first time, and it reports five published advisories against starlette 0.52.1, which PlatformIO pulls in. They are left open in code scanning rather than dismissed, because they are real. What was missing was the reason they are still here, written down where someone looking at the pin will find it. All five are flaws in serving HTTP: Host header validation, request path handling, StaticFiles traversal, and form field limits. PlatformIO lists starlette under "PIO Home requirements" and imports it only in platformio/home/run.py, the web UI behind `pio home`. CI runs pio test, pio run and pio check, none of which start that server; the only other reference, in platformio/compat.py, sits on the Python < 3.9 branch that 3.12 never takes. There is also nowhere to move to. Every fixed version is 1.3.1 or earlier but above 0.53, and PlatformIO 6.1.19 -- the current release -- requires starlette >=0.19,<0.53. The exit condition is PlatformIO widening that constraint, after which regenerating the lock closes the alert. The generated lock is byte-identical after this change; comments in the .in file do not reach it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pinning CI's Python tools by hash made the resolved dependency set visible to
OpenSSF Scorecard's vulnerability scanner for the first time. It now reports
five published advisories against
starlette0.52.1, which PlatformIO pulls in:PYSEC-2026-161,-248,-249,-2280and-2281.They are left open in code scanning rather than dismissed, because they are
real. What was missing is the reason they are still here, recorded where someone
reading the pin will find it.
Not reachable from anything CI runs
All five are flaws in serving HTTP — Host header validation, request path
handling,
StaticFilestraversal, and form field limits — so each needs arunning Starlette server accepting requests.
PlatformIO lists
starletteunder the comment "PIO Home requirements" inplatformio/dependencies.py, and imports it inplatformio/home/run.py, thelocal web UI behind
pio home. CI runspio test,pio runandpio check;none of them start that server. The only other reference,
platformio/compat.py, is a threadpool shim on thepython_version < 3.9branch, which CI's Python 3.12 never takes.
No version to move to
Every fix is in starlette 1.3.1 or earlier, but all are above 0.53. PlatformIO
6.1.19 — the current release — requires
starlette >=0.19,<0.53, so no fixedversion is inside the range it accepts.
The exit condition is PlatformIO widening that constraint; regenerating the lock
then closes the alerts without anyone needing to remember this.
Note on scope
Only
tools/requirements-ci.inchanges, and only its comments. The generatedlock is byte-identical afterwards, which was checked by regenerating and
diffing.
🤖 Generated with Claude Code