Skip to content

ci: add least-privilege workflow permissions (CodeQL)#99

Open
jhamon wants to merge 1 commit into
mainfrom
security/workflow-least-privilege-permissions
Open

ci: add least-privilege workflow permissions (CodeQL)#99
jhamon wants to merge 1 commit into
mainfrom
security/workflow-least-privilege-permissions

Conversation

@jhamon

@jhamon jhamon commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Resolves the two open CodeQL actions/missing-workflow-permissions alerts (#1, #2). Neither workflow declared explicit permissions, so both used the repository-default GITHUB_TOKEN scope.

Changes

  • CI.yamlpermissions: contents: read — only runs tests on pull_request / merge_group.
  • CD.yamlpermissions: contents: write — creates a git tag (git.createRef) and a GitHub Release; the PyPI publish step uses PYPI_TOKEN, not GITHUB_TOKEN.

Verification

  • YAML parses cleanly (ruby -ryaml).
  • Token scope now matches each workflow's actual operations; no behavior change.

Part of PIN-16 (security tail), child of PIN-6.

🤖 Generated with Claude Code


Note

Low Risk
Workflow-only hardening with scopes aligned to existing checkout, test, tag, and release steps; no application code changes.

Overview
Adds explicit permissions blocks to CI and CD so GITHUB_TOKEN scope matches what each workflow does, addressing CodeQL actions/missing-workflow-permissions alerts.

CI.yaml sets contents: read for pull-request and merge-group test runs. CD.yaml sets contents: write for tag and GitHub Release creation; PyPI publish still uses PYPI_TOKEN, not the default token.

Reviewed by Cursor Bugbot for commit 61bc2e5. Bugbot is set up for automated code reviews on this repo. Configure here.

Resolves CodeQL actions/missing-workflow-permissions alerts (#1, #2).
- CI.yaml: contents: read (runs tests on PR / merge_group)
- CD.yaml: contents: write (creates git tag + GitHub Release)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@jhamon

jhamon commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

PR Feedback Autofix pass

The only red check here is Run tests (ubuntu-latest, 3.9). That failure is pre-existing and unrelated to this PR — this PR only adds workflow-level permissions: blocks, which cannot affect dependency resolution. The 3.9 cell fails at poetry install because the unbounded torch >=1.13.1 constraint no longer resolves on Python 3.9 (newer torch dropped 3.9 support). All other matrix cells pass.

Filed as a follow-up: #101 (needs a support-matrix decision — drop 3.9 or cap torch — so it's out of scope for a permissions change).

Also closed #100 as a duplicate of this PR. This PR is ready for review on its own merits; the 3.9 cell will stay red until #101 lands.

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

The failing Run tests (3.9) check is pre-existing and unrelated to this PR (this PR only adds least-privilege workflow permissions). On Python 3.9, poetry install fails version-solving: torch>=1.13.1triton 3.3.1setuptools>=40.8.0, and current setuptools requires Python ≥3.10.

Deferred to #102 (broadens scope beyond this PR + needs a support-policy decision on dropping EOL Python 3.9). This PR is blocked on #102 landing (or 3.9 being dropped from the matrix) before main goes green.

— PR Feedback Autofix

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

PR Feedback Autofix — disposition: the failing Run tests (ubuntu-latest, 3.9) check is not caused by this PR. This PR only adds least-privilege permissions: blocks to the workflows; the failure is a pre-existing Poetry dependency-resolution break — because pinecone-text depends on torch (>=1.13.1), version solving failed on Python 3.9.

Tracked separately in #103 (needs a dependency decision — env marker, drop 3.9, or pin torch). Not fixable inside this PR's diff. This PR's own change is correct; the red is external.

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

Correction: the tracking issue for this pre-existing py3.9/torch CI failure is #101 (I closed #103 as a duplicate of it). This PR's workflow-permissions change is unaffected; the red is external and tracked in #101.

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

The red Run tests (ubuntu-latest, 3.9) check is not caused by this PR (which only adds least-privilege workflow permissions). It fails at the Install dependencies step: on Python 3.9, poetry can no longer resolve the unbounded torch constraint because floating setuptools@83 now requires Python ≥3.10. This is a pre-existing breakage on main, already tracked in #101.

This PR's own change is unrelated to the failing job and is ready for review. The 3.9 job will stay red until #101 is resolved (cap setuptools under a py3.9 marker, or drop py3.9 from the support matrix).

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

The red Run tests (ubuntu-latest, 3.9) check on this PR is the pre-existing torch/py3.9 resolution failure (#101), not anything in this permissions diff. Fix is up in #104 (caps torch <2.3 on py3.9). Once #104 merges and this branch is rebased, the 3.9 cell should go green here too.

@jhamon

jhamon commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

This PR's only red check (Run tests (ubuntu-latest, 3.9)) is the pre-existing py3.9 Poetry resolve failure tracked in #101 — not caused by this permissions change. It will go green once #101 is resolved (recommended path: drop py3.9, pending maintainer sign-off). PR #104 explored a torch cap but it can't make the 3.9 cell pass; see #101 for the analysis.

@jhamon

jhamon commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

The failing Run tests (ubuntu-latest, 3.9) cell is not caused by this PR's change (it only adds least-privilege workflow permissions). It's the pre-existing Python 3.9 dependency-resolution failure — torch 2.7.1 → triton 3.3.1 won't resolve on 3.9 — tracked in #101 and fixed by #104. Once #104 lands on main, rebasing this branch will clear the red cell. No change needed here; holding on #104.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant