Validate artifact upload scope against repository #10

New issue

Open

opened 2026-07-05 20:04:50 +00:00 by stephen · 1 comment

stephen commented

2026-07-05 20:04:50 +00:00

Owner

Follow-up from rasterstate/download-artifact-action#15. The download-side fix rejects cross-repository reads when repository or RASTER_ARTIFACTS_SCOPE does not match GITHUB_REPOSITORY.

Upload should get the same scope validation for writes, so one repository cannot write or poison another repository's artifact prefix when repos share the same backend credential.

Expected fix: bind upload object keys to the current run's repository scope, or reject RASTER_ARTIFACTS_SCOPE/repository-style overrides unless backed by a signed scope claim.

Follow-up from rasterstate/download-artifact-action#15. The download-side fix rejects cross-repository reads when repository or RASTER_ARTIFACTS_SCOPE does not match GITHUB_REPOSITORY. Upload should get the same scope validation for writes, so one repository cannot write or poison another repository's artifact prefix when repos share the same backend credential. Expected fix: bind upload object keys to the current run's repository scope, or reject RASTER_ARTIFACTS_SCOPE/repository-style overrides unless backed by a signed scope claim.

stephen referenced this issue from rasterstate/download-artifact-action

2026-07-05 20:05:03 +00:00

Reject cross-repo artifact scopes #16

stephen commented

2026-07-05 20:42:53 +00:00

Author

Owner

The #16 review showed that binding to GITHUB_REPOSITORY is still job-controlled and bypassable. The upload-side fix should mirror the signed-claim boundary from download-artifact-action#15 instead:

require RASTER_ARTIFACTS_SCOPE_CLAIM plus RASTER_ARTIFACTS_SCOPE_PUBLIC_KEY
verify an Ed25519 signature over the claim payload
derive the object prefix from the signed repository claim, not from GITHUB_REPOSITORY / RASTER_ARTIFACTS_SCOPE
fail closed if GITHUB_REPOSITORY or any explicit scope override disagrees with the signed claim

So this issue is still valid, but the expected fix should be signed repo-scope claims, not a client-side comparison to GITHUB_REPOSITORY.

The #16 review showed that binding to `GITHUB_REPOSITORY` is still job-controlled and bypassable. The upload-side fix should mirror the signed-claim boundary from download-artifact-action#15 instead: - require `RASTER_ARTIFACTS_SCOPE_CLAIM` plus `RASTER_ARTIFACTS_SCOPE_PUBLIC_KEY` - verify an Ed25519 signature over the claim payload - derive the object prefix from the signed `repository` claim, not from `GITHUB_REPOSITORY` / `RASTER_ARTIFACTS_SCOPE` - fail closed if `GITHUB_REPOSITORY` or any explicit scope override disagrees with the signed claim So this issue is still valid, but the expected fix should be signed repo-scope claims, not a client-side comparison to `GITHUB_REPOSITORY`.