Skip to content

composer-update: per-package retry so one unfixable package doesn't widen the rest#23

Merged
oxyc merged 1 commit into
masterfrom
fix/composer-update-per-package-fallback
May 19, 2026
Merged

composer-update: per-package retry so one unfixable package doesn't widen the rest#23
oxyc merged 1 commit into
masterfrom
fix/composer-update-per-package-fallback

Conversation

@oxyc
Copy link
Copy Markdown
Member

@oxyc oxyc commented May 19, 2026

Summary

bcplatformscom #43 widened phpunit/phpunit from ^9.0 to ^11.5 — across two majors — even though CVE-2026-24765 is patched in 9.6.33, well within the existing constraint.

Root cause

composer update -W <list> is transactional. The vuln list included wpackagist-plugin/faq-schema-block-to-accordion, whose only fix sits on dev-trunk (rejected by #21). With one unsatisfiable target in the batch, composer rolls back the entire transaction and leaves the lock untouched. Step 1 then sees no diff and falls through to Step 2's widening for every listed package — including phpunit, which had a perfectly reachable fix in ^9.

Fix

After the bulk attempt, loop per package: for any package whose locked version didn't move, retry composer update -W <pkg> on just that one. Only packages that still don't move get passed into the widening step.

Keeps the bulk-first happy path (one solver run, fast) but isolates a single unfixable package so it doesn't poison its neighbors.

Test plan

  • Re-trigger the vuln scan on bcplatformscom and confirm phpunit/phpunit lands on ^9.x with the lock moving to 9.6.33+, while faq-schema-block-to-accordion is still warned-and-skipped.
  • Confirm nesbot/carbon updates within ^2.x (CVE-2025-22145 is patched in 2.72.6) rather than getting widened.
  • Confirm symfony/http-foundation updates within ^6.4 (patched in 6.4.29).

🤖 Generated with Claude Code

…iden the rest

bcplatformscom #43 widened `phpunit/phpunit` from `^9.0` to `^11.5` even
though CVE-2026-24765 is patched in `9.6.33` — well within the existing
constraint.

Why: `composer update -W <list>` is transactional. The list included
`wpackagist-plugin/faq-schema-block-to-accordion`, whose only fix sits
on dev-trunk (which we now reject). With one unsatisfiable target,
composer rolls back the entire batch and leaves the lock untouched.
Step 1 then sees no diff and falls through to Step 2's widening for
every listed package, including phpunit — bumping it across two majors
purely because its batch-mate was unfixable.

Fix: after the bulk attempt, loop per package and retry
`composer update -W <pkg>` for any package whose locked version
didn't move. Only packages that still don't move get passed into the
widening step. Bulk first preserves the happy-path speed; the
per-package fallback isolates the one unfixable package without
penalizing its neighbors.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@oxyc oxyc merged commit ccb7f60 into master May 19, 2026
@oxyc oxyc deleted the fix/composer-update-per-package-fallback branch May 19, 2026 16:51
oxyc added a commit that referenced this pull request May 29, 2026
… (+ test suite) (#35)

* test(composer-update): unit + integration tests; extract helpers to lib.sh

The composer-update logic had no tests and was fragile (every recent fix —
#20#31 — was a production-only discovery). Add a real test suite and make
the logic testable.

- Extract the helper functions (build_pkg_arg, build_widen_arg,
  find_direct_ancestors, loosen_constraint, is_still_vulnerable,
  expand_args_for, get_lock_version) from update.sh into a sourceable
  scripts/lib.sh. update.sh sources it; behavior is unchanged (the existing
  no-widen integration test still passes).

- Unit tests for the PHP helpers (the fragile version-range logic):
  - compute-min-safe-constraints: exclusive/inclusive bounds, missing version
    components, multi-range selection, no-entry fall-throughs.
  - is-still-vulnerable: in/out of range, multi-range, junk-input fail-safe.

- Unit tests for the bash helpers, each tied to the edge case it guards:
  #27 build_pkg_arg trailing newline, #29 build_widen_arg caret widen,
  #28 loosen_constraint, #22/#26 find_direct_ancestors BFS + expand_args_for.

- Integration tests driving the real update.sh with a fake composer:
  #24 downgrade revert, #21 dev-* revert, #23 per-package retry isolation,
  #20 no-widen honored as a JSON array. (Plus the existing no-widen test.)

- Fix surfaced by the tests: compute-min-safe-constraints emitted `[]` for an
  empty result, but update.sh string-indexes that map with `jq '.[$pkg]'`,
  which errors on a JSON array under `set -eo pipefail`. Encode as `{}`.

- CI: composer-update-tests.yml now sets up PHP and runs tests/run.sh.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(composer-update): inclusive-bound (<=) safe-version derivation skips 4-segment hotfixes

compute-min-safe-constraints derived ~X.Y.(Z+1) for a <=X.Y.Z advisory.
That skips a 4-segment hotfix like X.Y.Z.1, which is >X.Y.Z but
<X.Y.(Z+1): the constraint matched no published version, the update
no-opped, and the vuln went unpatched (no PR opened).

Real case: suomentyokalu / seo-by-rank-math, advisory <=1.0.271, fixed
in 1.0.271.1. The derived ~1.0.272 could not resolve.

Emit >X.Y.Z,<X.(Y+1).0 instead — a strict-greater lower bound that
matches the hotfix while still excluding the vulnerable boundary X.Y.Z,
still minor-capped. Teach loosen_constraint() and build_widen_arg() the
new range shape (major-cap widen/loosen, boundary stays excluded).

Tests: regression case asserting <=1.0.271 -> >1.0.271,<1.1.0 plus
Semver checks that 1.0.271.1 is reachable and 1.0.271 is excluded;
updated existing <= assertions; helper-fn coverage for the range shape.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: test <test@example.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant