Skip to content

ci: the docs deploy builds with its dependencies in a job that can write to the repository #7320

Open

Description

@andygrove

What is the problem?

The docs job in ci.yml calls docs.yaml with contents: write, so the site can be pushed to asf-site. Inside docs.yaml the single build-docs job holds that write access for the whole run:

  • Both actions/checkout steps use the default persist-credentials: true, which leaves the job's GITHUB_TOKEN in the checkout's git config.
  • The job then runs everything that builds the site: npm install for mermaid-cli, pip install -r docs/requirements.txt, Sphinx, and docs/build.sh, which builds four Spark profiles with Maven.
  • Only the last step, "Copy & push the generated HTML", needs to write.

So a compromised dependency of any of those tools runs in the same job as a token that can push to asf-site. The job only runs on push to main (and a dispatch of main), so a pull request cannot reach it. The weakness is the dependency chain of an authorized build.

This is hardening, not a known compromise.

Proposal

Split it in two:

  1. A build job with contents: read and persist-credentials: false on both checkouts, which installs, builds, runs the mermaid checks, and uploads docs/build/html as an artifact.
  2. A small deploy job with contents: write that downloads the artifact, checks out asf-site, and does the rsync and push.

This separates the credential from the code that builds. It does not make the built output trustworthy: a compromised builder can still produce malicious pages. It only stops the builder from using the repository's write access directly.

Raised in review of #7311, which does not touch this file.

Activity

  1. added
    enhancementNew feature or request
    priority:lowMinor issues, test failures, tooling, cosmetic
    area:ciCI/CD, GitHub Actions, build tooling
    on Oct 29, 2026
  2. ErikBPF commented on Oct 29, 2026

    @ErikBPF
    Contributor

    This proposal preserves the boundary requested in the original review. No additional scope change is needed.

    Evidence

    A build job with contents: read and persist-credentials: false

    A small deploy job with contents: write that downloads the artifact

    For implementation, keep the reusable caller's permission ceiling sufficient for deployment, but explicitly narrow the build job to contents: read. Keep dependency installation, Maven, Sphinx and Mermaid execution in that read-only job. The fresh writer should consume the generated output without running project build commands or scripts from the artifact.

    Action: Verify the effective build-job permissions and non-persisted build checkout credentials, and verify that the deploy job performs only the static-output publication path. Include a disposable copy check preserving Git metadata, .asf.yaml and .nojekyll. The current copy step restores the latter two after rsync --delete, and docs/build/html alone does not supply root .asf.yaml. Keep the trigger guards and Mermaid checks. The stated caveat is important: isolating the writer does not certify the generated pages as trustworthy.

    This confirms the proposed scope. It does not mark the current workflow as repaired.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:ciCI/CD, GitHub Actions, build toolingenhancementNew feature or requestpriority:lowMinor issues, test failures, tooling, cosmeticrequires-triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions