ci: pin and least-privilege Android workflows - #1558
Draft
Jeremy1844 wants to merge 2 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause
The five Android workflows trusted mutable external-action refs, relied on implicit token permissions, and allowed checkout credentials to persist. The two release-writing paths also lacked explicit non-cancelling concurrency boundaries, and the Play job lacked a defensive full-ref guard.
This is the single action-provenance and workflow-trust-boundary root tracked as
ADV-2026-0033/RC-0033. It is based onmainat55405f66a8c555047dc0035747acdcaa371d59fa.Change
contents: read, granting writes only to the jobs that label PRs or update releases.persist-credentials: falseon all four checkouts.main/developrelease behavior while adding a defensive full-ref guard.No application code, content, signing material, release credential, persistence format, or user data changes.
Red/green evidence
de799a5998d1a926e0fd68cf337f6f3bc739d3d6: expected failure, 0/6 policy groups passed.2ad6104c258e115b17ab90af118cd07a7773be14: 6/6 policy groups passed; treeeee2a593ae127ac2036c136f53256f806cbc9949.--dry-run; both signing tasks were present and skipped.+306/-16, and a clean worktree.No signing, decryption, artifact upload, release, Play submission, deployment, or workflow dispatch was performed.
Version decision
actions/checkoutremains on the reviewed immutable v6 commitd23441a48e516b6c34aea4fa41551a30e30af803. It is an official signed Node 24 revision and is the version exercised by the complete tested tree. Moving to v7.0.1 adds behavior and dependency changes and should receive its own focused review rather than changing this root during publication.actions/upload-release-assetremains an archived, unsigned Node 12 action. Its full-SHA pin contains provenance drift but does not modernize the runtime. Replacement is a separate behavior-tested root and remains a merge gate for release enablement.Open-PR overlap and required order
on_push.yml; the merged tree is clean and both workflow policies pass.develop; preserve the documented order#1557 -> corrected ADV-2026-0033 -> develop ADV-2026-0054 -> ADV-2026-0073.Remaining safety gates
Migration, recovery, and rollback
There is no persistence or schema migration. Operationally, release writers queue instead of racing, and later steps no longer inherit checkout credentials. Prefer a forward fix pinned to a newly reviewed commit. If concurrency/ref behavior needs correction, retain immutable pins, least permissions, and non-persistent credentials; never restore floating refs, implicit broad permissions, or persisted credentials.