Repository navigation
build(deps): bump actions/upload-artifact from 7.0.1 to 7.0.2 - #6343
Conversation
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 7.0.1 to 7.0.2. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@043fb46...cf430e0) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: 7.0.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
the
dependencies
dependabot
Bot
added
the
github_actions
![aethersdr-agent[bot]](https://avatars.githubusercontent.com/in/3286087?s=60&v=4){kind=small}
There was a problem hiding this comment.
Issue fit
No linked issue, and none is wanted: this is a Dependabot dependency bump, which CONTRIBUTING.md:153 places in the Infrastructure (Tier 2) tier — "changes to the repo's own scaffolding (dependency bumps, issue templates, CI config, build config)". GOVERNANCE.md's RFC requirement doesn't reach it. Reviewed against the title's own claim instead, and that claim is literally true:
$ git ls-remote --tags https://github.com/actions/upload-artifact 'v7.0.*'
043fb46d1a93c77aae656e7c1c64a875d1fc6a0a refs/tags/v7.0.1 <- old pin
cf430e030ddbb5b0abf93d22962f4752f3646cd9 refs/tags/v7.0.2 <- new pin
Both SHAs are exactly the tags named in the title. I also read the upstream range rather than assuming what a patch bump contains — v7.0.1..v7.0.2 is two substantive commits, Bump @actions/artifact to 6.3.1 plus release prep. Nothing touches overwrite, if-no-files-found, compression, or path globbing, so there is no default-behavior change for the eleven call sites to absorb.
This also closes the open item the CodeGuard audit flagged for me: it could not confirm the SHA→tag mapping from the checkout alone. Confirmed upstream, above.
Scope
Everything in the diff is explained by the stated change. 11 insertions, 11 deletions, and zero changed lines that are not an upload-artifact pin:
| File | Changes | Claimed by title | Verdict |
|---|---|---|---|
appimage.yml |
1 pin (:516) | Yes | In scope |
codeql.yml |
2 pins (:141, :187) | Yes | In scope |
docs.yml |
1 pin (:130) + # v7.0.1→# v7.0.2 |
Yes | In scope; see nit |
full-suite.yml |
1 pin (:279) | Yes | In scope |
macos-dmg.yml |
1 pin (:770) | Yes | In scope |
sanitizers.yml |
1 pin (:334) | Yes | In scope |
windows-installer.yml |
4 pins (:493, :526, :535, :812) | Yes | In scope |
Completeness checks: grep -rn 043fb46d... .github/ returns nothing — no straggler left on the old pin. All eleven upload-artifact@ references in the tree carry the new SHA. No mutable action tags anywhere in .github/workflows/. The download-artifact pin (3e5f45b2… = v8.0.1) is untouched and in the same post-v4 artifact-API generation, so the upload/download pairing stays coherent.
Blockers
None.
Nits
-
.github/workflows/docs.yml:130— the trailing version comment contradicts the repo's own documented convention..github/dependabot.ymlstates it directly: "pin actions to a full commit SHA with NO trailing# vXversion comment — Dependabot bumps the SHA but doesn't keep such comments in sync, so they drift and mislead (see #3864). The version lives in Dependabot's PR title." This is the only one of the eleven sites carrying such a comment. It is pre-existing (main has# v7.0.1) and Dependabot did keep it in sync this time, so nothing is currently misleading — but since the line is already being touched, it's the cheapest possible moment to bring it into line:uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9
Non-blocking, and equally fine to leave for a separate sweep.
Pre-existing, out of scope for this PR
A security audit was required on the changed files, so I ran it. Its findings are all on lines this PR does not touch — recording them here for visibility, not as anything that should gate a pin bump. Each is verified against the file by me, not just relayed.
-
.github/workflows/macos-dmg.yml:695, 708, 720, 729, 747— security-audit (CodeGuard),codeguard-0-input-validation-injection.md. Fiverun:blocks splicegithub.ref_nameinto bash as script text, e.g.:720:codesign --force --timestamp \ --sign "Developer ID Application" \ AetherSDR-${{ github.ref_name }}-macOS-${{ matrix.label }}.dmgThe repo already writes this rule down at
windows-installer.yml:21-22— "A tag name may contain", ; $and backticks, so it reaches scripts only as an environment variable, never by${{ }}substitution into the script text" — andmacos-dmg.yml:765itself implements the sanitization (SAFE_REF="${GITHUB_REF_NAME//[^A-Za-z0-9._-]/_}") just 70 lines below, as doesappimage.yml:414. These five sites in the same file missed it, and the job carries the Apple signing/notarization secrets. Reachable only by someone with push/tag-write, so it is a policy inconsistency rather than an unauthenticated vector — but it looks worth its own issue. -
.github/workflows/docs.yml:66—CF_TOKENis job-level, so it is in the environment ofnpm ci(:92) andnpm run build(:95) onpull_requestruns, while the only consumers are themain-gated deploy steps (:144-159). The comment at :64-65 explains the reason honestly ("thesecretscontext is not available in stepif:conditions"), so this is a known tradeoff rather than an oversight; narrowing it would mean gating on avarsflag instead. -
codeql.yml:82,full-suite.yml:45,sanitizers.yml:37, 68use mutable:latest/:tsancontainer tags while everyuses:in the tree is SHA-pinned. Low severity (org-owned registry, andsanitizers.yml:92-110asserts image identity at runtime), noted only because the pinning policy is otherwise uniform. -
appimage.yml:388-390fetcheslinuxdeployfrom the mutablecontinuousrelease tag with no checksum and executes it, wheredocs.yml:51-55pins and SHA-256-verifies its Pandoc/Typst toolchain.
Refuted and dropped: CG-PATH-001 at appimage.yml:205 and :417 are both comment prose containing a literal ".../", not path operations. The CS-VLN-CMDI-BACKTICK hits in windows-installer.yml are PowerShell line-continuations. The CS-VLN-CMDI-ENVVAR hits are the mitigation the scanner mistook for the defect. CS-VLN-CMDI-SUBSHELL/PIPE operands are static literals or runner-local tool output. The harness triage line also listed a CS-PII-BANK category with no itemized entry; grepping for IBAN/account/routing/SWIFT/card patterns returns nothing, and the audit identified the matches as 64-hex SHA-256 and 40-hex commit pins — i.e. the digests themselves tripped an account-number rule. No credential material is embedded in any of the seven files; all come from secrets.*.
What I tried to break
- "7.0.1 to 7.0.2" could have been a wrong or hostile SHA. Verified both pins against upstream tags with
git ls-remote(not the API — the sandbox blocks it). Exact match both directions. This is the one check that mattered most and the only one I could settle empirically. - A patch bump could still move a default. Read
v7.0.1..v7.0.2upstream rather than trusting the semver label: one dependency bump, one release-prep commit. No input-handling or default change. - A bulk SHA replacement usually leaves a straggler. Grepped the whole
.github/tree for the old SHA — none. Also checked for anyuses:on a mutable tag (none) and thatdownload-artifactwasn't left on an incompatible generation (it's v8.0.1, untouched, same artifact-API era). - Hidden payload in a "mechanical" diff. Counted the changed lines that are not pin lines: zero. No workflow logic, trigger,
permissions:, orif:condition moved. Checkedpermissions:blocks across all seven files — all explicit and scoped, nonewrite-all. - The diff I was handed looked corrupted (
!cancelled() ${PR_DIFF}${PR_DIFF} (...)in full-suite.yml). Read the real file: it says&&. Harness rendering artifact, not a finding. - Could not check: runtime behavior of the new action version. Only
docs.yml's upload step actually executed on this PR — all 7 checks are green including "Build docs site", which proves the new pin resolves and runs. The other five workflows will first exercise it elsewhere:appimage/macos-dmg/windows-installeruploads are tag-triggered, andfull-suite/sanitizersuploads are failure-conditional, so five of seven workflows first run this pin on a release or a red run, not here. That residual risk is inherent to the bump, not a defect in it. The branch is one commit on top of currentmain(a9a83e66a), so no stale merge base.
Findings above are reasoned from the workflow sources and from upstream git metadata; nothing was reproduced by executing a workflow.
Recommendation
Approve (with the optional nit). The central claim is verified upstream rather than taken on trust, the diff is exactly the eleven pin lines and nothing else, no straggler or mutable tag remains, and one CI lane has already run the new pin green. The only canon-citable line in the diff is the # v7.0.2 comment in docs.yml:130, which contradicts .github/dependabot.yml's stated convention but is pre-existing and currently accurate — fine either way.
Next step: per CONTRIBUTING.md:106 this is Tier 2, so it needs an @aethersdr/infrastructure owner rather than a general maintainer. The pre-existing macos-dmg.yml github.ref_name interpolation is the one item I'd suggest splitting into its own issue — it is a real deviation from a rule the repo states explicitly and implements correctly two files over, and it should not ride along on a Dependabot PR.
🤖 aethersdr-agent · cost: $9.3557 · model: claude-opus-5
|
Cisco CodeGuard — static analysis of this PR (89 finding(s))
Automated static scan by Cisco DefenseClaw CodeGuard on the changed files. Advisory — some may be false positives; the review above verifies them. 🤖 aethersdr-agent · cost: $10.5234 · model: claude-opus-5 |
ten9876
left a comment
ten9876
left a comment
There was a problem hiding this comment.
Approving at c65e3ce.
Verified:
- The pins match their upstream tags.
actions/upload-artifactv7.0.1=043fb46d…(old) andv7.0.2=cf430e03…(new), checked against theactions/upload-artifacttag refs. - No straggler. On
main(f753dbf), noupload-artifact@pin other than the eleven this PR bumps remains. - The four required contexts pass at this head, and
Build docs siteran the new pin green (docs.yml's upload step), so the pin resolves and executes.
Bot review nits:
docs.yml:130# v7.0.2trailer: left as is by maintainer decision. It is pre-existing and accurate, and leaving it keeps this branch Dependabot-managed with no extra CI cycle.- Pre-existing items: the
macos-dmg.yml${{ github.ref_name }}interpolation is already gone on currentmain(#6083 moved it toSAFE_REFfrom$GITHUB_REF_NAME, :677/:775), so nothing is left to file. Theappimage.ymllinuxdeploycontinuousdownload is filed as #6415. TheCF_TOKENscope and the mutable container tags are documented trade-offs (sanitizers.yml asserts image identity at runtime), so nothing was filed for them.
Not verified: the appimage, macos-dmg and windows-installer uploads are tag-triggered, and the full-suite and sanitizers uploads only run on failure. Those sites first run the new pin on a release or a red run.
Bumps actions/upload-artifact from 7.0.1 to 7.0.2.
Release notes
Sourced from actions/upload-artifact's releases.
Commits
cf430e0Merge pull request #822 from actions/tunc-d-prepare-upload-v7-0-2c2acdedchore: prepare v7.0.2 release4687c1bMerge pull request #821 from actions/tunc-d-upload-artifact-package-bump8cbe1beBump@actions/artifactto 6.3.1Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)