Skip to content

ci: bump brace-expansion from 1.1.16 to 1.1.18 in /frontend in the npm_and_yarn group across 1 directory - #120

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/frontend/npm_and_yarn-84557ebc70
Closed

ci: bump brace-expansion from 1.1.16 to 1.1.18 in /frontend in the npm_and_yarn group across 1 directory#120
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/frontend/npm_and_yarn-84557ebc70

Conversation

@dependabot

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

Copy link
Copy Markdown
Contributor

Bumps the npm_and_yarn group with 1 update in the /frontend directory: brace-expansion.

Updates brace-expansion from 1.1.16 to 1.1.18

Commits

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Jul 31, 2026
@dependabot
dependabot Bot requested a review from tyler-rich as a code owner July 31, 2026 05:03
@tyler-rich
tyler-rich changed the base branch from main to dev July 31, 2026 05:06
@tyler-rich

Copy link
Copy Markdown
Owner

@dependabot rebase

Bumps the npm_and_yarn group with 1 update in the /frontend directory: [brace-expansion](https://github.com/juliangruber/brace-expansion).


Updates `brace-expansion` from 1.1.16 to 1.1.18
- [Release notes](https://github.com/juliangruber/brace-expansion/releases)
- [Commits](https://github.com/juliangruber/brace-expansion/commits)

---
updated-dependencies:
- dependency-name: brace-expansion
  dependency-version: 1.1.18
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot changed the base branch from dev to main July 31, 2026 05:09
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/frontend/npm_and_yarn-84557ebc70 branch from 0a752e9 to 7c0b9a5 Compare July 31, 2026 05:09
@tyler-rich

Copy link
Copy Markdown
Owner

Closing — retargeting to dev left the diff stale (1.1.15 -> 1.1.18 against a lockfile already at 1.1.16). Folding the bump into the v0.2.0 release prep instead.

@tyler-rich tyler-rich closed this Jul 31, 2026
@dependabot @github

dependabot Bot commented on behalf of github Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml

@dependabot
dependabot Bot deleted the dependabot/npm_and_yarn/frontend/npm_and_yarn-84557ebc70 branch July 31, 2026 05:12
tyler-rich added a commit that referenced this pull request Jul 31, 2026
…bump, Dependabot security-PR routing (#121)

Cuts CHANGELOG `[Unreleased]` to `[0.2.0] - 2026-07-31` with a fresh empty
`[Unreleased]` above it and a `[0.2.0]` compare link, and adds a `### Security`
entry covering the base-image and dependency currency that answers issue #75.

Bumps brace-expansion 1.1.16 -> 1.1.18 and the nested
@typescript-eslint/typescript-estree copy 2.1.3 -> 2.1.4, regenerated with npm
rather than hand-edited. Dependabot's #120 proposed this but opened against
main, and retargeting left its diff stale, so it was closed in favour of doing
this on dev.

Documents in CLAUDE.md and CONTRIBUTING.md that Dependabot security updates
always open against the default branch, ignoring target-branch, and that
retargeting such a PR does not work.

See docs/ARCHIVE.md § Deviations (2026-07-31) for the full pass.
tyler-rich added a commit that referenced this pull request Aug 2, 2026
The retarget diagnosis said #110 and #120 have "no such event", which is
true of automatic_base_change_succeeded but reads as though their
timelines are bare. #120 carries two ordinary base_ref_changed events -
the manual retarget-to-dev-and-back already documented on 2026-07-31 -
so a reader checking a timeline needs the event types told apart, not
just the presence of a base change.
tyler-rich added a commit that referenced this pull request Aug 2, 2026
* backend: bump fastapi 0.140.0 -> 0.140.13 and regenerate requirements.lock

Reapplies the bump Dependabot proposed in #127, which could not merge as
opened: Dependabot edits pyproject.toml without touching
backend/requirements.lock, so CI's drift gate rejects it. The lock is
regenerated with the pinned command from CONTRIBUTING.md § Backend
dependency lock (uv 0.8.17, --group build --generate-hashes
--python-version 3.14) and moves three lines: fastapi's version and its
two wheel hashes. starlette stays at the explicitly-pinned 1.3.1.

All thirteen patch releases are internal dependency-tree/OpenAPI
refactors (0.140.1-0.140.7) or fixes to paths this backend does not use
- SSE/JSONL streaming, response_model_* on Iterable returns,
jsonable_encoder's exclude_defaults, and nested-Annotated sequence
params. Verified by grep: no jsonable_encoder, no StreamingResponse, no
SSE helper, no response_model_* anywhere in backend/app.

Confirmed against the regenerated lock rather than the version pin: a
venv on CPython 3.14.6 built the way the image builds (pip install
--require-hashes -r requirements.lock, then pip install --no-deps
--no-build-isolation .) runs the full suite green - 666 passed, 5
skipped, identical to the pre-bump baseline.

* ci: bump docker/login-action 4.5.1 -> 4.5.2

Reapplies what Dependabot proposed in #128, SHA-pinned per the repo's
Actions convention with the tag as a trailing comment.

The commit SHA was resolved from upstream with git ls-remote --tags
against docker/login-action rather than read off the bump description -
refs/tags/v4.5.2 maps to 371161bbe7024a29a25c5e19bfcbc0804fe9ad2c.
Trusting a rendered SHA is the substitution a SHA pin exists to prevent.

v4.5.2 contains one substantive commit, "surface Docker Hub OIDC error
responses" (docker/login-action#1058): it improves the error text when a
Docker Hub OIDC login fails. All three call sites here log in to ghcr.io
with the built-in GITHUB_TOKEN as username/password - not Docker Hub,
not OIDC - so the changed path is never entered. No input, output, or
breaking changes. This matters because these workflows run only on the
tag-gated publish path and the nightly, which CI cannot exercise.

* ci(dependabot): ignore node majors and the local scrye build tag

Two ignore entries, both closing a recurring failure.

node majors, on the docker entry. #126 proposed node
22-bookworm-slim -> 25-bookworm-slim. Node's odd-numbered lines never
become LTS: v25 reached end-of-life on 2026-06-01, before that PR was
opened and years before the 22 line's 2027-04-30, so it would have moved
the frontend builder onto an unsupported runtime. The wanted move is
22 -> 24 (Active LTS, 2028-04-30) and is tracked in docs/ROADMAP.md
because it spans the Dockerfile, ci.yml and CONTRIBUTING.md together.

The ignore is scoped to version-update:semver-major so digest refreshes
of the pinned 22 tag still come through - declining a major previously
left Dependabot offering nothing for this image and the digest went
stale until #107 refreshed it by hand.

dependency-name: scrye, on both docker entries. docker/docker-compose.yml
pins image: scrye:0.2.0, Scrye's own locally-built tag; Dependabot
resolves the unqualified name as Docker Hub's library/scrye, gets a 401,
and fails the run with private_source_authentication_failure. Reading the
files confirms the compose file carries the only such reference and
docker/Dockerfile carries none, so the substantive entry is on the
docker-compose ecosystem; it is repeated on the docker entry because the
failing run's ecosystem is visible only in the Dependabot UI, and
suppressing a name the Dockerfile never mentions costs nothing.

The image tag itself is unchanged: qualifying it as
ghcr.io/tyler-rich/scrye:0.2.0 would make the compose file pull a
published image instead of building locally, changing what the
documented quick start does.

* docs: record the post-v0.2.0 dependency cleanup and the base-branch diagnosis

A version update sitting on main is not the documented security-update
case. #126, #127 and #128 were all opened against dev correctly - their
head branches carry the /dev/ target-branch segment - and each records an
automatic_base_change_succeeded event 2-3 seconds after the v0.2.0
promotion (#122) merged. GitHub retargets open PRs whose base branch is
deleted to the merged PR's base, and auto-delete-on-merge deleted dev as
the promotion's head branch. dependabot.yml was not involved, and neither
was grouped security updates: all three are version updates across three
different ecosystems. The remedy is already in place (auto-delete
disabled on 2026-08-02); target-branch and the grouping setting stay as
they are.

CLAUDE.md § Dependency hygiene and a new CONTRIBUTING.md subsection carry
the rule and a two-signal table for telling the two causes apart.

docs/ROADMAP.md: the Node 22 -> 24 item rewritten to state that it must
be its own PR with a registry-verified digest pin, and to name the three
files that have to move together - bumping the Dockerfile alone would
leave CI on 22 while the image builds on 24. New item for enabling
GitHub code scanning (CodeQL) on Python and TypeScript: free for public
repos, default setup adds a workflow running on every push and PR, and
the first run surfaces a triage backlog, so it wants its own session.

docs/ARCHIVE.md gains the dated §14 entry covering all of it, including
the correction to #125: GHSA-mh99-v99m-4gvg was re-scoped per major on
2026-07-31 and 1.1.18 / 2.1.4 are both above their line's first patched
version, so the #121 bump did clear it. Verified at the source - 1.1.17
and 2.1.3 introduce EXPANSION_MAX_LENGTH and name CVE-2026-14257 in
their comments - not from the advisory metadata that produced the wrong
claim in the first place. #125 closed on its own stated criterion; #123
and #124 re-verified and still accurate.

* docs: distinguish base_ref_changed from automatic_base_change_succeeded

The retarget diagnosis said #110 and #120 have "no such event", which is
true of automatic_base_change_succeeded but reads as though their
timelines are bare. #120 carries two ordinary base_ref_changed events -
the manual retarget-to-dev-and-back already documented on 2026-07-31 -
so a reader checking a timeline needs the event types told apart, not
just the presence of a base change.

* docs: state the evidence for the node digest-refresh assumption

The ignore is scoped to version-update:semver-major so digest refreshes
of the pinned 22 tag keep arriving, but that rests on documented
update-types semantics plus reported updater behaviour - not on an
observed run in this repository. Says so, names the first scheduled
docker run as the test, and records the fallback if it is wrong (refresh
the digest by hand, as #107 did).

* ci: pin docker/login-action to v4.6.0 rather than v4.5.2

Supersedes the 4.5.2 applied earlier in this branch. 4.5.2's only
substantive commit improves Docker Hub OIDC error text, a path none of
the three call sites can reach - all three log in to ghcr.io with the
built-in GITHUB_TOKEN as username/password. 4.6.0 lands a day later and
its change is at least adjacent to what this repo does: it hardens the
buildx-scoped config path used by the login -> buildx -> push chain, and
carries the action's own bundled dependency bumps.

SHA resolved from upstream with git ls-remote --tags, not from a
changelog: refs/tags/v4.6.0 -> dbcb813823bdd20940b903addbd779551569679f.
The moving v4 tag currently points at the same commit; the pin is the
immutable v4.6.0 commit, not the alias.

Read at the source by diffing v4.5.2...v4.6.0 rather than from the
release notes, because these workflows run only on the tag-gated publish
path and the nightly, which CI cannot exercise. action.yml is
byte-identical, src/main.ts and src/docker.ts are unchanged, and the
whole change is in src/context.ts's buildx scoped-config-dir helper -
path.resolve containment on the registry and scope inputs behind a new
isChildPath() helper.

Behaviourally a no-op here: that helper returns early on
'if (scopeDisabled() || !scope || scope === "")', and no call site
passes a scope input. Currency plus defence-in-depth, not a fix for
anything reachable.

* frontend: bump postcss 8.5.16 -> 8.5.25 (GHSA-r28c-9q8g-f849)

Applied by hand rather than waiting for Dependabot: it has not proposed
this, and after closing #126/#127/#128 there are no open Dependabot PRs
at all, so a HIGH advisory was waiting on a bot that was not going to
act.

Which version actually clears it was verified in the published source,
not taken from the advisory range - GHSA-mh99-v99m-4gvg was re-scoped
mid-flight and #125 was wrong because of it. postcss 8.5.18's
lib/previous-map.js loadFile() gains the containment check the advisory
describes (relative(dirname(cssFile), path) rejected when it is '..',
starts with '../', or is absolute); 8.5.17 has none of it. So 8.5.18 is
the real floor. The same check is still present in 8.5.25, which is what
is pinned - current release on the pinned 8.5 line, per CLAUDE.md
§ Dependency hygiene.

No overrides entry needed and no parent bumped: postcss is a direct
devDependency here, and every package that also reaches it declares a
peer/caret range 8.5.25 satisfies (vite's ^8.5.3 included), so raising
the single pin lifts the tree and npm ls shows one deduped copy.

Regenerated with npm pkg set + npm install --package-lock-only, not by
editing version strings, so resolved URLs and integrity hashes moved
with the version. Diff is postcss 8.5.16 -> 8.5.25, its nanoid floor
^3.3.12 -> ^3.3.16, and nanoid 3.3.15 -> 3.3.16 - all dev-only, no new
packages.

npm ci installs 8.5.25 with the containment check present; ESLint,
Prettier, the 20-file/69-test Vitest suite and npm run build all pass;
npm audit no longer reports postcss. Nothing ships either way - postcss
runs during vite build and the image copies only dist/.

* docs: record the 4.6.0 pin and the postcss bump in the dated entry

The §14 entry's login-action item now covers 4.6.0 and why it was taken
over the 4.5.2 that #128 proposed, including the source-level diff and
the honest note that the hardened path is gated on a scope input this
repo never passes.

The advisory-issues item gains the full postcss treatment: why it was
applied by hand, the 8.5.18 fix floor verified in the published source
rather than read off the advisory range, why no overrides entry or
parent bump was needed, and the post-bump verification. #124 closed on
its own stated criterion, the same standard applied to #125.

CHANGELOG [Unreleased] gains a Security entry for the postcss advisory -
and says explicitly that unlike the brace-expansion bump in 0.2.0, this
one does clear its advisory - plus Changed entries for the login-action
and fastapi pins.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant