Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Pin GitHub Actions to SHAs and add zizmor and pip-audit

Aperta
  • Qualcosa non va?
#210 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
58/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
docker, github-actions, python
Ambito
ci-cd, devops, documentation, security

Direzione di ricerca

Read CONTRIBUTING.md first, then inspect the workflows under .github/workflows/, especially pre-commit.yaml, lint.yaml, deploy-prod.yaml, deploy-staging.yaml, docker.yaml, source.yaml, version-check.yaml, and copilot-setup-steps.yml. Review the existing pre-commit configuration and dependency lock workflow before testing with uv and pre-commit. Done means the acceptance criteria pass, including clean zizmor and pip-audit checks, documented pinning guidance in CONTRIBUTING.md, and successful workflow runs on a fork.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

tests and ci/cd

🔄 Updated for v5.0.0 (2026-10-08). Still open. Since this was written, CI moved into ci_checks.yml and the deploys into deploy_staging.yml, deploy_prod.yml and the shared pesu-dev/actions workflows (#223, #224, #232). The workflows now declare permissions: themselves, so the earlier instruction to keep zizmor's permissions audit off no longer applies. The workflow list, the secrets at risk and where each check goes are updated.

Summary

The GitHub Actions workflows use actions by mutable tag (actions/checkout@v7, docker/login-action@v4), and nothing scans the workflows or the Python dependencies for known problems. A compromised or retagged action runs with the repository's secrets: the Render API key, the Docker Hub credentials, the release bot's GitHub App key and the PESU test account. This kind of attack has happened to widely used actions. Pin actions to commit SHAs, and add automated checks: zizmor for workflow security, and pip-audit for vulnerable Python dependencies.

Background

  • The workflows are in .github/workflows/: ci_checks.yml (its Test suite & coverage job has the TEST_* secrets, a real PESU account's credentials), deploy_prod.yml (the Render API key, the Docker Hub credentials and the release bot's key), deploy_staging.yml (the Render API key) and copilot-setup-steps.yml. The deploy workflows also call shared workflows in pesu-dev/actions at @v1, which is a mutable tag too.
  • Actions in use: actions/checkout, actions/setup-python, actions/create-github-app-token, astral-sh/setup-uv (already pinned to an exact version, @v9.0.0), docker/login-action, and the shared pesu-dev/actions/.github/workflows/build_push_image.yml and deploy_render.yml, which in turn use docker/setup-qemu-action, docker/setup-buildx-action and docker/build-push-action.
  • The deploy workflows and copilot-setup-steps.yml already declare permissions:; ci_checks.yml doesn't, so zizmor's excessive-permissions audit will flag it. Fixing that is in scope: give each ci_checks.yml job the least it needs (contents: read for most), and check on a fork that every job still passes.

Proposed change

  1. Pin every uses: to a full commit SHA, with the version in a trailing comment: uses: actions/checkout@<40-char-sha> # v7.x.y. Dependabot's github-actions ecosystem (#209) updates SHA pins and their comments automatically, so these two issues go well together.
  2. zizmor:
    • add it as a pre-commit hook (it has an official one) and/or a step in the Package checks job, run with --min-severity medium;
    • fix what it finds, for example template expressions used directly in run:. Put values in env: first; most steps here already do. The shared deploy_render.yml interpolates ${{ inputs.commit_sha }} and ${{ inputs.image_url }} straight into its shell script; that fix belongs in a pesu-dev/actions PR, so link it.
  3. pip-audit:
    • a step in the Package checks job (or a new job in ci_checks.yml, added to Greenlight's needs) that runs uvx pip-audit against the locked runtime dependencies (for example uv export --no-dev --frozen | uvx pip-audit -r /dev/stdin --strict);
    • it fails on known vulnerabilities;
    • allowed exceptions go in a documented ignore list, each with a reason.
  4. Optional: CodeQL for Python through GitHub's "default setup". That's a settings change, so leave a note for maintainers rather than a workflow.

House rules for workflow changes:

  • Keep workflow comments to short one-liners, matching the existing files, and put the reasoning in the PR description.
  • Every PR check runs from .github/workflows/ci_checks.yml. The only required status check on dev is Greenlight - CI checks, which fails if any job it needs failed. Add a new job to its needs list and to CHECK_RESULTS, or the job won't block a merge, and don't rename the Greenlight job, or the required check never reports.
  • Image builds and Render deploys run through shared workflows in pesu-dev/actions (build_push_image.yml and deploy_render.yml, used at @v1). A change to them is a PR to that repository, followed by moving its v1 tag.
  • astral-sh/setup-uv publishes no floating major tag, so pin an exact version (CI uses @v9.0.0) or a commit SHA.
  • ci_checks.yml runs on pull requests, so test a workflow change by opening a pull request inside your fork (from your branch to your fork's dev), and link the green run in your PR.

Acceptance criteria

  • Every action is pinned to a SHA with a version comment
  • zizmor runs in CI and is clean, including excessive-permissions
  • pip-audit runs in CI against the locked runtime dependencies
  • CONTRIBUTING.md explains how to pin a new action

How to contribute

  • Wait until you're assigned. Comment to ask for this issue, then wait for a maintainer to assign it to you before writing any code. PRs for unassigned issues are closed without review.
  • Read CONTRIBUTING.md first. It covers forking, setting up with uv, and running the tests.
  • Branch from dev in your fork, and open the PR against dev with a Conventional Commit title and Closes #210 in the description.
  • Bump the minor version in pyproject.toml and run uv lock (CI checks this). uv run pre-commit run --all-files must pass, and coverage must stay at 100%.
  • Update the README, app/docs/ and comments in the same PR as the behaviour they describe.
  • Never log, print, store or echo a password or token, including in tests, PR descriptions and screenshots.
Lingua principale
Python
Stelle
22
Fork
29
Merge medio
22h 4m
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pesu-dev/auth

Tutte le issue di pesu-dev/auth

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.