Skip to content

ci(deps): Bump the github-actions group with 3 updates - #6

Merged
cs3gallery merged 1 commit into
mainfrom
dependabot/github_actions/github-actions-981787fb12
Jul 31, 2026
Merged

ci(deps): Bump the github-actions group with 3 updates#6
cs3gallery merged 1 commit into
mainfrom
dependabot/github_actions/github-actions-981787fb12

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 30, 2026

Copy link
Copy Markdown
Contributor

Bumps the github-actions group with 3 updates: actions/checkout, actions/setup-node and trufflesecurity/trufflehog.

Updates actions/checkout from 4 to 7

Release notes

Sourced from actions/checkout's releases.

v7.0.0

What's Changed

New Contributors

Full Changelog: actions/checkout@v6.0.3...v7.0.0

v6.1.0

What's Changed

https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/ for more details about this breaking change

Full Changelog: actions/checkout@v6.0.3...v6.1.0

v6.0.3

What's Changed

New Contributors

Full Changelog: actions/checkout@v6...v6.0.3

v6.0.2

What's Changed

Full Changelog: actions/checkout@v6.0.1...v6.0.2

v6.0.1

What's Changed

... (truncated)

Changelog

Sourced from actions/checkout's changelog.

Changelog

v7.0.1

v7.0.0

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v5.0.1

v5.0.0

v4.3.1

v4.3.0

v4.2.2

v4.2.1

... (truncated)

Commits

Updates actions/setup-node from 4 to 7

Release notes

Sourced from actions/setup-node's releases.

v7.0.0

What's Changed

Enhancements:

Bug fixes:

Documentation updates:

Dependency update:

New Contributors

Full Changelog: actions/setup-node@v6...v7.0.0

v6.5.0

What's Changed

Full Changelog: actions/setup-node@v6.4.0...v6.5.0

v6.4.0

What's Changed

Dependency updates:

New Contributors

Full Changelog: actions/setup-node@v6...v6.4.0

v6.3.0

What's Changed

Enhancements:

... (truncated)

Commits
  • 8207627 Migrate to ESM and upgrade dependencies (#1574)
  • 04be95c Add cache-primary-key and cache-matched-key as outputs (#1577)
  • 7c2c68d docs: Update caching recommendations to mitigate cache poisoning risks (#1567)
  • 6a61c03 Merge pull request #1569 from jasongin/update-actions-cache-5.1.0
  • 30eb73b Resolve high-severity audit issues
  • 4e1a87a Update dist
  • 360237f Strict equality
  • 4f8aac5 Bump @​actions/cache to 5.1.0, log cache write denied
  • f4a67bb Only use mirrorToken in getManifest if it's provided (#1548)
  • 0355742 Remove dummy NODE_AUTH_TOKEN export (#1558)
  • Additional commits viewable in compare view

Updates trufflesecurity/trufflehog from 3.88.0 to 3.96.0

Release notes

Sourced from trufflesecurity/trufflehog's releases.

v3.96.0

What's Changed

New Contributors

Full Changelog: trufflesecurity/trufflehog@v3.95.9...v3.96.0

v3.95.9

What's Changed

New Contributors

Full Changelog: trufflesecurity/trufflehog@v3.95.8...v3.95.9

... (truncated)

Commits
  • 6f3c981 fix(handlers): apk handler now doesnt check for apk extension since json-enum...
  • 05a5832 fix(detectors/posthog): widen phx_ key body to {43,48} (#5133)
  • a2ef4f5 [chore] Change job_id in metric to source_type (#5149)
  • e74404a updated detector to include underscore char (#5121)
  • 4d82f21 Fix scan_all_installations Rejecting Org Member Personal Repos (#5142)
  • 38999f8 Retry git clone on transient network errors (#5132)
  • 0eb1a81 Update module github.com/go-git/go-git/v5 to v5.19.1 [SECURITY] (#5034)
  • ec20cb3 document Config.SourceManager (#5002)
  • 4ecd7d5 Log analyze errors for HuggingFace analyzer (#5130)
  • 1247638 Log analyze errors for Postgres analyzer (#5131)
  • Additional commits viewable in compare view

Dependabot 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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

@dependabot
ci(deps): Bump the github-actions group with 3 updates
32c9e48 
Bumps the github-actions group with 3 updates: [actions/checkout](https://github.com/actions/checkout), [actions/setup-node](https://github.com/actions/setup-node) and [trufflesecurity/trufflehog](https://github.com/trufflesecurity/trufflehog).


Updates `actions/checkout` from 4 to 7
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v4...v7)

Updates `actions/setup-node` from 4 to 7
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](actions/setup-node@v4...v7)

Updates `trufflesecurity/trufflehog` from 3.88.0 to 3.96.0
- [Release notes](https://github.com/trufflesecurity/trufflehog/releases)
- [Commits](trufflesecurity/trufflehog@v3.88.0...v3.96.0)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: github-actions
- dependency-name: actions/setup-node
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: github-actions
- dependency-name: trufflesecurity/trufflehog
  dependency-version: 3.96.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: github-actions
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot @github

dependabot Bot commented on behalf of github Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Labels

The following labels could not be found: ci, dependencies. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@cs3gallery

cs3gallery commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Upstream changelog review (required by docs/DEPENDENCY_POLICY.md)

docs/DEPENDENCY_POLICY.md puts a major-version upgrade behind "Owner approval; changelog
review in the PR", and adds that major updates "are never merged without reading the upstream
changelog for breaking changes. Note in the pull request what you read." This is that review.

It needs more than the four green checks on this PR. release.yml triggers only on v*.*.*
tags, so those checks exercised ci.yml and never ran a single changed line in release.yml.
The known-good baseline for that file is run
30583901693, which
published @zenixsolutions/lumics-mcp@0.1.0 on actions/checkout@v4 + actions/setup-node@v4.
I read that run's log as the v4 control and diffed the action sources against it.

Everything below is marked Read (quoted or diffed from an upstream artifact) or Inferred
(my reasoning from those artifacts). Where the upstream notes are silent I say so rather than
guessing.

Bottom line

Safe to merge as-is. No edit to release.yml is required, and I do not recommend splitting
it from the ci.yml portion.

The specific wiring release.yml depends on — registry-url writing
$RUNNER_TEMP/.npmrc with a literal ${NODE_AUTH_TOKEN} placeholder, NPM_CONFIG_USERCONFIG
pointing at it, and $GITHUB_SHA plus origin/main both being resolvable at the guard step —
is unchanged from v4 through v7. In two places checkout v7 is strictly stricter than v4 on the
tag-triggered path, which is the safe direction for a release workflow.

Three things I would act on separately, none of them blocking:

  1. The TruffleHog bump is close to cosmetic. version still defaults to latest, so the
    workflow has never pinned the scanner — only the wrapper script. The comment in ci.yml
    saying it is "Pinned to a release tag" overstates what is actually pinned. Worth a follow-up.
  2. The release.yml path is still unexecuted after this merge. There is a zero-risk dry run
    described at the end that exercises exactly the changed part without publishing anything.
  3. actions/setup-node dropped the always-auth input in v6 and did not mention it in any
    release note. We do not use it, but it is a reminder that these notes are incomplete.

1. actions/setup-node v4 → v5 → v6 → v7: registry-url, .npmrc, NODE_AUTH_TOKEN

Read. The registry-url input description is byte-identical in
v4 and
v7:
"Optional registry to set up for auth. Will set the registry in a project level .npmrc and
.yarnrc file, and set up auth to read in from env.NODE_AUTH_TOKEN."

Read. Diffing src/authutil.ts at v4
against v7, the three things
that matter to our publish step are unchanged:

  • The file path is still path.resolve(process.env['RUNNER_TEMP'] || process.cwd(), '.npmrc').
  • It still writes <registry-without-protocol>:_authToken=${NODE_AUTH_TOKEN} as a literal,
    unexpanded     string, plus the registry= line. npm expands ${NODE_AUTH_TOKEN} from the
    environment at npm publish time, which is what makes step-level env: work.
  • It still unconditionally exports NPM_CONFIG_USERCONFIG pointing at that file. Writing the
    file is not conditional on a token being present.

Read. One real change, in v7 (v7.0.0 release notes, "Bug fixes: Remove dummy
NODE_AUTH_TOKEN export", #1558). v4 ran
exportVariable('NODE_AUTH_TOKEN', process.env.NODE_AUTH_TOKEN || 'XXXXX-XXXXX-XXXXX-XXXXX').
v7 exports it only if the caller already set it
(Object.prototype.hasOwnProperty.call(process.env, 'NODE_AUTH_TOKEN')). The PR's own stated
reason: "The action previously exported a dummy NODE_AUTH_TOKEN value ... While this didn't
break OIDC flows, it could corrupt the user's .npmrc".

Inferred. This does not touch us. release.yml sets NODE_AUTH_TOKEN as step-level env:
on the publish step, which under v4 already shadowed the dummy workflow-level export. Removing
the dummy leaves the publish step's own value as the only one in play. The failure mode this
changes is "you forgot to set NODE_AUTH_TOKEN at all" — we do set it.

npm publish --provenance and the OIDC id-token flow. The upstream notes do not describe
any change to either. The only v7 item in that neighbourhood is documentation
(#1536, "Add documentation for publishing to
npm with Trusted Publisher (OIDC)"), and #1558 explicitly states the dummy token "didn't break
OIDC flows". Provenance is minted by npm from the id-token: write permission granted at the
workflow level in release.yml; setup-node is not in that path. I found nothing to flag, and I
am not going to invent a risk here.

Default Node version resolution. No change I can find that affects us. release.yml pins
node-version: '20' explicitly. The v0.1.0 run resolved node: v20.20.2. The only
version-resolution change in the range is v6.3.0 adding devEngines parsing for
node-version-file (#1283); we do not use
node-version-file, and package.json has no devEngines field.

cache: npm. Two changes, neither of which reaches us because we set cache explicitly:

  • Read, v5.0.0 breaking change (#1348):
    automatic caching when package.json has a packageManager field, disabled with
    package-manager-cache: false. Our package.json has no packageManager field, and both
    workflows already pass cache: npm.
  • Read, v6.0.0 breaking change (#1374):
    "Limit automatic caching to npm". Narrows the above; no effect on an explicit cache: npm.
  • Read, v7.0.0 bumps @actions/cache to 5.1.0 and adds cache-primary-key /
    cache-matched-key outputs. Additive.

2. actions/checkout v4 → v5 → v6 → v7: fetch defaults, ref resolution, .git state

Read. fetch-depth still defaults to 1 and fetch-tags still defaults to false in both
v4 and
v7 action.yml. The ref default is
unchanged. persist-credentials still defaults to true.

Read. What did change, from the v4→v7 source diff:

  • .git state, v6.0.0 (#2286, "Persist
    creds to a separate file"). The v7 README
    states it plainly: "persist-credentials now stores credentials in a separate file under
    $RUNNER_TEMP instead of directly in .git/config", pulled in via an includeIf directive.
    The v0.1.0 log shows the v4 behaviour we are leaving:
    git config --local http.https://github.com/.extraheader AUTHORIZATION: basic ***.
  • Tag refspec, v7. In src/ref-helper.ts, getRefSpec for a refs/tags/ ref with a commit
    changed from return [`+${commit}:${ref}`] (v4 — fetch by SHA, writes a lightweight
    local tag) to result.push(`+${ref}:${ref}`) (v7 — fetch by name, preserving the
    annotated tag object). Confirmed against the v0.1.0 log, which shows v4 running:
    git ... fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +f6a59af203b677c6f215ec88c9234ef4573a59c0:refs/tags/v0.1.0
  • New hard assertion, v7. src/git-source-provider.ts now re-runs testRef after the
    fetch and throws: "The ref '' does not point to the expected commit ''. The ref may
    have been updated after the workflow was triggered."
  • Annotated-tag dereference, v7. testRef now compares against
    revParse(`${ref}^{commit}`) rather than revParse(ref), with the comment "Use ^{commit}
    to dereference annotated tags to their underlying commit".
  • --no-tags is now unconditional in git-command-manager.ts; tag fetching moved entirely
    into the refspec. Same net effect for fetch-tags: false.
  • git remote add origin <url> is unchanged, so remote.origin.fetch is still the default
    +refs/heads/*:refs/remotes/origin/*.

Now the guard. v0.1.0 is an annotated tag (git/ref/tags/v0.1.0 returns
object.type == "tag", object.sha == e042b13...), and GITHUB_SHA for that run was
f6a59af203b677c6f215ec88c9234ef4573a59c0 — the underlying commit, not the tag object. The
v4 baseline log shows the guard working end to end:

git fetch --no-tags --depth=100 origin main
 * branch            main       -> FETCH_HEAD
 * [new branch]      main       -> origin/main
Tag commit is an ancestor of main.

Inferred, and this is the answer to the question as posed: neither. The guard does not break,
and it does not stop guarding. The chain:

  • v7 fetches +refs/tags/v0.1.0:refs/tags/v0.1.0, which brings the annotated tag object and its
    target commit. $GITHUB_SHA is therefore still a resolvable object locally.
  • v7 then asserts refs/tags/v0.1.0^{commit} == $GITHUB_SHA and fails the job outright if not.
    So by the time the guard step runs, $GITHUB_SHA being the right commit is a precondition
    enforced by checkout itself, not merely an assumption.
  • origin/main is created by the guard's own git fetch --no-tags --depth=100 origin main
    — a plain shell command, not the action — and the opportunistic remote-tracking update it
    relies on comes from remote.origin.fetch, which git remote add still sets identically.

The credential relocation in v6 does not affect the guard's fetch either: lumics-mcp is a
public repository, so that fetch succeeds unauthenticated, and even for a private repo the
includeIf "gitdir:" still matches because the step runs inside the repository.

Two behavioural differences I want on the record, both fail-closed:

  1. v4 fetched the tag by SHA, which succeeds even if the tag is later moved or deleted. v7
    fetches by name and asserts the target. If someone force-moves a release tag between the
    trigger and the run, v4 would have quietly published the originally-tagged commit; v7 fails
    the checkout. For a release workflow that is the behaviour I want.
  2. The local tag in the workspace is now a real annotated tag object, so
    git rev-parse refs/tags/vX inside the checkout returns the tag object SHA, not the
    commit. Nothing in release.yml does that — the guard uses $GITHUB_SHA and the version
    check uses $GITHUB_REF_NAME — but any future step that resolves the tag ref needs ^{commit}.

3. Runner and Node runtime

Read. Both actions moved to the node24 runtime at v5, and both name the same runner floor:

Read. Confirmed directly from the action.yml files: using: 'node20' at v4 for both;
using: 'node24' at setup-node v5/v6/v7 and checkout v7.

So v5 is the bump that clears the annotation, and v7 carries it. The 0.1.0 warning —
"Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run
on Node.js 24: actions/checkout@v4, actions/setup-node@v4" — goes away after this merge.

New minimum runner requirement: runner v2.327.1. Both workflows use ubuntu-latest, i.e.
GitHub-hosted runners, which are well past that. Inferred: this is only a real constraint if
we ever add a self-hosted runner, and it should be noted wherever that decision gets made.

4. trufflesecurity/trufflehog v3.88.0 → v3.96.0

I diffed action.yml@v3.88.0
against action.yml@v3.96.0
in full, and searched the bodies of all 86 releases in the range for exit-code, --fail and
--only-verified changes.

No vacuous pass. Read: the docker invocation still ends
--fail --no-update --github-actions ${ARGS:-''}, and extra_args: --only-verified is still
passed through verbatim (visible in the PR's own run log: ARGS: --only-verified). --fail is
intact, so a verified finding still exits non-zero. No new required inputs: every input is
required: false with the same defaults, and the one addition (image) defaults to
ghcr.io/trufflesecurity/trufflehog, i.e. the previously hard-coded registry
(#4965).

Changed default behaviour, in the stricter direction. Read: on a push event where
github.event.before is all-zeros (new branch, or a force-push that orphans history), v3.88.0
computed BASE=$(git rev-parse $HEAD~$COMMIT_LENGTH); v3.96.0 sets BASE="", which with
--since-commit '' scans the full branch history instead of a fixed window. More scanning, not
less. The env var also changed from COMMITS: ${{ toJson(github.event.commits) }} to
COMMIT_IDS: ${{ toJson(github.event.commits.*.id) }} — same jq length semantics, but the
workflow no longer interpolates attacker-influenced commit messages into a shell env var.
jq is now auto-installed if missing. The pull_request path (BASE=base.sha,
HEAD=head.sha) is unchanged.

Exit-code semantics did change — but not because of this PR. Read:
v3.90.9 landed "Return
non-zero exit code if an error occurs during a scan"
(#4476). Fail-closed, and welcome.

The finding that matters here. Read: the version input defaults to "latest" in
both v3.88.0 and v3.96.0, and the container line resolves to "${IMAGE}:${VERSION}". The PR's
own secret-scan log confirms it:

Unable to find image 'ghcr.io/trufflesecurity/trufflehog:latest' locally
Status: Downloaded newer image for ghcr.io/trufflesecurity/trufflehog:latest
... "trufflehog_version": "3.96.0"

Inferred: the tag in ci.yml pins the composite wrapper script only. The scanner binary that
actually decides pass or fail has always been whatever :latest resolved to on the day. That is
why #4476's exit-code change reached our CI months ago without any PR. It also means the comment
in ci.yml — "Pinned to a release tag. Never use @master or @main for a third-party action:
a mutable ref is a remote-code-execution path into CI" — is describing a protection we only
half have: the wrapper is pinned, the code that runs is :latest. That reasoning applies to the
image just as much as to the ref. Fixing it means passing version: v3.96.0 (or a digest) as an
input, which is a separate change and out of scope for a Dependabot bump.

5. Other breaking changes plausibly affecting either workflow

  • actions/setup-node removed the always-auth input in v6. Read by diffing the
    action.yml files: present in v4 and v5, absent in v6 and v7. It appears in no release
    note — v6.0.0 lists only "Limit automatic caching to npm". Neither workflow uses it, so there
    is no impact, but a silently removed input is exactly the kind of thing a changelog review is
    supposed to catch, and the changelog did not have it.
  • actions/checkout v7 blocks fork-PR checkout under pull_request_target / workflow_run
    (#2454; backported to v6.1.0 as an explicit
    [BREAKING]; see the
    GitHub changelog entry).
    New allow-unsafe-pr-checkout input, default false. Read: ci.yml triggers on push
    and pull_request; release.yml on tag push. Neither uses pull_request_target or
    workflow_run, so this is inert for us — and it is a good reason not to add one later without
    reading that changelog entry first.
  • actions/checkout v7 and actions/setup-node v7 both migrated to ESM
    (#2463,
    #1574). Internal to the actions' own bundles.
    Inferred: no consumer-visible surface, and the four green checks on this PR are direct
    evidence for the ci.yml path.
  • actions/checkout v6.0.2 "Fix tag handling: preserve annotations and explicit fetch-tags"
    (#2356) — the origin of the refspec change
    analysed in section 2.
  • actions/checkout v6.0.3 / v7 SHA-256 repository support. New pre-fetch API call to
    determine object format, and git init --object-format=sha256 when applicable. Inert for a
    SHA-1 repository.
  • actions/checkout v7.0.1 ("escape values passed to --unset", "trim only ascii
    whitespace for branch") is newer than the v7 major tag this PR pins. Pinning @v7 picks it
    up automatically, which is consistent with how the other actions are pinned here.

Sources read

Upstream release notes and changelogs:

Action definitions and sources, diffed v4 against v7 (release notes alone were not sufficient —
the always-auth removal and the tag refspec change are only visible here):

Our own runs, as the v4 control and the v7 evidence:

What I did not verify, and how to close it cheaply

I could not execute release.yml under v7. Nothing short of pushing a tag can, and the analysis
above is a reading of the sources, not a test result. If you want that closed before the next
real release, the cheapest way is a deliberate throwaway:

Push an annotated tag v0.0.0 on a commit on main. It matches the v*.*.* trigger, so the
job starts, does the v7 checkout, and runs "Verify the tag is on main" — the exact step this
review is about. The next step, "Verify the tag matches package.json", then fails, because
0.0.0 != 0.1.0. The job stops there. npm ci, the build and npm publish never run, so
nothing can reach the registry. Read the checkout and guard output, then delete the tag.

That turns the one inference I am least able to prove into an observation, for the price of one
red workflow run and a deleted tag.

This was referenced Jul 30, 2026
Merged
Closed
@cs3gallery
cs3gallery merged commit 497e281 into main Jul 31, 2026
4 checks passed
@dependabot
dependabot Bot deleted the dependabot/github_actions/github-actions-981787fb12 branch July 31, 2026 04:03
cs3gallery added a commit that referenced this pull request Jul 31, 2026
@cs3gallery Josh Schall
ci(deps): stop grouping GitHub Actions majors into one pull request (#13
8986b49 
)

The github-actions group matched every pattern with no update-type filter,
so majors were swept into the same pull request as patches. PR #6 is the
result: actions/checkout v4 to v7 and actions/setup-node v4 to v7 alongside
a trufflehog patch, in one diff.

docs/DEPENDENCY_POLICY.md requires a major be raised separately and merged
only after its upstream changelog has been read, and two of those majors
touch release.yml — a workflow that triggers only on tags, so pull-request
CI never exercises it. Grouping made a change CI cannot test look like a
routine dependency bump.

Restricting the group to minor and patch does not suppress majors;
Dependabot raises each one as its own pull request, which is what the policy
describes.

Also corrects the npm ignore block's comment. It claimed majors are "raised
individually, never grouped". `ignore` does not do that — it stops the pull
request being opened at all. The behaviour may well be right for a project
that pins exact versions, but it is not what the comment or the policy says,
and that mismatch needs an owner decision rather than a quiet reword.

Co-authored-by: Josh Schall <josh@zenixsolutions.com>
@cs3gallery cs3gallery mentioned this pull request Jul 31, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@cs3gallery