Background
PR #3712 added a zizmor GitHub Actions security-scanning workflow (CI gate at min-severity: high / min-confidence: medium) plus a matching pre-commit hook. The 3 high-severity unpinned-uses findings that were blocking CI have been fixed (pinned astral-sh/setup-uv and openapi-generators/openapitools-generator-action to SHAs). This issue tracks what's left.
Remaining lower-severity zizmor findings (below the CI gate)
Running zizmor --no-progress .github/workflows/ (no severity/confidence filter) after the high-severity fixes still reports:
41 findings (31 suppressed): 0 informational, 0 low, 10 medium, 0 high
All 10 unsuppressed findings are excessive-permissions (medium confidence): several jobs in .github/workflows/ci.yml, .github/workflows/openapi-diff.yml, and .github/workflows/publish-pages.yml rely on the default (overly broad) GITHUB_TOKEN permissions because no explicit permissions: block is set at the workflow or job level. None of these are high severity, so they don't block CI or pre-commit.ci today, but tightening them (e.g. permissions: contents: read at minimum, adding pages: write/id-token: write only where actually needed) would reduce the blast radius of a compromised action.
Full findings detail (locations/rules) available by re-running:
GH_TOKEN=$(gh auth token) uvx zizmor --no-progress .github/workflows/
Separate: uv.lock lockfile-hygiene regression (jinxed/ansicon marker)
uv.lock's jinxed package entry lost the sys_platform == 'win32' marker on its ansicon sub-dependency when this PR's uv lock was regenerated (confirmed by diffing git show origin/main:uv.lock vs the current branch — on main, the entry reads { name = "ansicon", marker = "sys_platform == 'win32'" }; on this branch it's just { name = "ansicon" }). This means ansicon now installs unconditionally on all platforms instead of only Windows.
uv.lock: jinxed's dependency on ansicon lost its sys_platform == 'win32' marker during this PR's relock (compare to main) — ansicon (https://pypi.org/project/ansicon/) is a pure-Python universal wheel with no OS-specific code, so this won't break non-Windows builds, but it's a lockfile-hygiene regression worth a closer look at why uv's marker propagation changed here.
Background
PR #3712 added a zizmor GitHub Actions security-scanning workflow (CI gate at
min-severity: high/min-confidence: medium) plus a matching pre-commit hook. The 3 high-severityunpinned-usesfindings that were blocking CI have been fixed (pinnedastral-sh/setup-uvandopenapi-generators/openapitools-generator-actionto SHAs). This issue tracks what's left.Remaining lower-severity zizmor findings (below the CI gate)
Running
zizmor --no-progress .github/workflows/(no severity/confidence filter) after the high-severity fixes still reports:All 10 unsuppressed findings are
excessive-permissions(medium confidence): several jobs in.github/workflows/ci.yml,.github/workflows/openapi-diff.yml, and.github/workflows/publish-pages.ymlrely on the default (overly broad)GITHUB_TOKENpermissions because no explicitpermissions:block is set at the workflow or job level. None of these are high severity, so they don't block CI or pre-commit.ci today, but tightening them (e.g.permissions: contents: readat minimum, addingpages: write/id-token: writeonly where actually needed) would reduce the blast radius of a compromised action.Full findings detail (locations/rules) available by re-running:
Separate:
uv.locklockfile-hygiene regression (jinxed/ansicon marker)uv.lock'sjinxedpackage entry lost thesys_platform == 'win32'marker on itsansiconsub-dependency when this PR'suv lockwas regenerated (confirmed by diffinggit show origin/main:uv.lockvs the current branch — onmain, the entry reads{ name = "ansicon", marker = "sys_platform == 'win32'" }; on this branch it's just{ name = "ansicon" }). This meansansiconnow installs unconditionally on all platforms instead of only Windows.uv.lock:jinxed's dependency onansiconlost itssys_platform == 'win32'marker during this PR's relock (compare tomain) —ansicon(https://pypi.org/project/ansicon/) is a pure-Python universal wheel with no OS-specific code, so this won't break non-Windows builds, but it's a lockfile-hygiene regression worth a closer look at why uv's marker propagation changed here.