ci: add top-level permissions: contents: read for least-privilege security

[abhi-14gyan]

Description

Add a top-level permissions: contents: read block to the CI workflow (.github/workflows/ci.yml). Without this, all jobs inherit the default GITHUB_TOKEN permissions — which on push events includes write access to contents, packages, deployments, etc. This change restricts the token to read-only by default, following the GitHub-recommended least-privilege principle.

Jobs affected (all gain explicit read-only restriction):

Job	What it does	Needs write?
test-quality	actions/checkout + ruff + pyright	No
test-all	actions/checkout + pytest + Codecov upload	No (Codecov uses its own token)
test-prototype-integration	actions/checkout + Streamlit smoke test	No
test-docker	actions/checkout + Docker build + run	No

Related Issue

Closes #154

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring / code cleanup (no functional changes)
• Test update (adding or modifying tests only)

Component(s) Affected

• Library (library/)
• Prototype / Streamlit app (prototype/)
• Data pipeline (data/)
• Analysis / Notebooks (analysis/)
• Documentation (docs/)
• CI / GitHub Actions (.github/)
• Other (please specify):

How Has This Been Tested?

• No functional changes to any workflow steps; only the token scope is restricted.
• All existing CI jobs (test-quality, test-all, test-prototype-integration, test-docker) only require read access, so no regressions expected.
• CI will validate on this PR itself.

Checklist

• I have read the CONTRIBUTING.md guide.
• My changes follow the existing code style (checked with uv run ruff check).
• I have added or updated tests as appropriate.
• All tests pass locally (uv run pytest).
• I have updated documentation if needed.

[bassosimone]

@abhi-14gyan This is a good idea, thank you. I think we did not follow this practice quite consistently here and in other codebases. My understanding is that, depending on the age of the organization, different defaults are applied and so the impact varies by organization. Does that mirror your understanding as well?

[abhi-14gyan]

@bassosimone Yes, that mirrors my understanding exactly. GitHub has changed the default GITHUB_TOKEN permissions over time:

• Organizations/repos created after February 2023 default to read-only (permissions: read-all), so the top-level permissions block is technically redundant - but still serves as explicit documentation of intent.
• Older organizations/repos (created before that date) default to read-write (permissions: write-all), which is where this change has a real security impact.
  The default can also be configured at the organization or repository level under Settings - Actions - General - Workflow permissions, so the effective behavior varies depending on whether an admin has changed it.
  Given that inconsistency, I think adding an explicit top-level permissions block is good practice regardless - it makes the workflow self-documenting and ensures least-privilege is enforced no matter what the org/repo default is set to. It also aligns with the OpenSSF Scorecard checks, which flag workflows missing explicit permissions.

[bassosimone]

After listing our project for GSoC, we received a large amount of pull requests across several repositories. We are dealing with the backlog, but this would take time. We will get back to this pull request eventually. In the meanwhile, if you are a GSoC applicant, please read our updated GSoC policy: https://github.com/m-lab/gsoc/.