mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-10-17 20:39:13 +00:00
ChuckBuildsandClaude Opus 5
c7de8be6f5
CodeQL reported 24 path-injection alerts across these handlers. The guard was effective -- traversal is blocked at every entry, verified on hardware -- but the shape was wrong in a way worth fixing rather than dismissing: _validate_starlark_app_path returned a bool, and the caller then rebuilt the path with `_STARLARK_APPS_DIR / app_id` using the raw value. Validate in one place, join in another, and the two have to stay in step by hand. A boolean is also not something CodeQL can follow, so the value it saw reaching the filesystem was the untrusted one -- the alerts were reporting the pattern accurately. It now returns the resolved, checked Path, and every caller uses that instead of re-joining. Seven join sites became zero; the only remaining construction from app_id is inside the validator itself. _standalone_render_starlark_app and _install_star_file validate for themselves too. Both are reachable independently of the handlers, and a path built from app_id should not be assembled anywhere without the check. Also stops three error paths returning exception text to the caller (CodeQL's 4 information-exposure alerts): a bad config.json answered with its absolute path and the parser's message. Logged in full, answered generically -- the same split the composer blueprint already makes. The pixlet subprocess is left as it is. It is list-form with no shell, whitelists config keys against ^[a-zA-Z_][a-zA-Z0-9_]*$ and drops any value containing shell metacharacters; "x; id", "x$(id)" and "x`id`" are all treated as data on hardware. Nothing to fix there. Behaviour is unchanged: same error strings for callers, same status codes. 32 Starlark tests and the full core suite (3979) pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014RRtqXDCnvnY6EQwhT5CV9