Pin the Composer platform to PHP 8.1 and clear the PHPCS security advisories #192

Merged

thatguygriff merged 2 commits from fix/187-composer-platform-pin into main 2026-08-25 02:08:07 +00:00

Conversation 0 Commits 2 Files Changed 2

+36 -30

thatguygriff commented 2026-08-25 01:46:12 +00:00

Owner

Copy Link

Copy Source

Follow-up flagged in #191.

composer.json declares "php": ">=8.1", but Composer resolved against whatever PHP the machine running the update happened to have — 8.5.9 locally. So a composer update could produce a lock containing a package that requires 8.2+: it would install fine on the machine that made it, and fail on the 8.1 leg of the test matrix. Now that the lock is committed, that failure mode is one composer update away at any time.

config.platform.php makes resolution always target the declared minimum, so a lock that resolves at all is a lock that installs everywhere the plugin claims to run.

Diff is as small as it looks

• composer.json: three lines, config.platform.php = "8.1".
• composer.lock: the new content hash and a platform-overrides block. No package versions change — nothing currently locked requires a PHP newer than 8.1, so the pin only constrains future updates.

Effect on local work

composer update will now refuse a package that needs PHP newer than 8.1, even on a newer local PHP. That is the point, but it does mean the constraint shows up at update time rather than in CI — which is the trade being made.

Note this pins resolution only. It does not affect which PHP actually runs anything: tests still execute on real 8.1/8.2/8.3/8.5 via the matrix.

Security advisories fixed

composer audit reported three advisories against the PHPCS stack, two rated high. All are dev-only and none ship in the plugin — bin/build-zip.sh installs --no-dev — but they execute against repository content on every CI run.

Package	CVE
squizlabs/php_codesniffer	CVE-2026-67434, OS command injection (high)	3.13.5	→ 3.13.6
wp-coding-standards/wpcs	CVE-2026-45293, arbitrary code execution (high)	3.3.0	→ 3.4.1
phpcsstandards/phpcsutils	CVE-2026-65954, arbitrary code execution	1.2.2	→ 1.2.3

The existing ^3.7 and ^3.0 constraints already allowed the fixed releases, so composer.json is unchanged by this part. phpcsstandards/phpcsextra (1.5.0 → 1.5.1) and dealerdirect/phpcodesniffer-composer-installer (v1.2.0 → v1.2.1) come along as transitive dependencies.

Five packages move, none added or removed. The updated standards report no new violations — composer cs is clean without any code changes, which was the risk I flagged when I first suggested holding this back.

composer audit now reports no advisories.

Tests

• composer validate — valid
• composer test — 966 tests, 2795 assertions, OK
• composer lint — no errors
• composer cs — clean, on the updated standards
• composer audit — no advisories

No CHANGELOG.md entry: build tooling only, nothing user-visible.

Follow-up flagged in #191. `composer.json` declares `"php": ">=8.1"`, but Composer resolved against whatever PHP the machine running the update happened to have — 8.5.9 locally. So a `composer update` could produce a lock containing a package that requires 8.2+: it would install fine on the machine that made it, and fail on the 8.1 leg of the test matrix. Now that the lock is committed, that failure mode is one `composer update` away at any time. `config.platform.php` makes resolution always target the declared minimum, so a lock that resolves at all is a lock that installs everywhere the plugin claims to run. ## Diff is as small as it looks - `composer.json`: three lines, `config.platform.php = "8.1"`. - `composer.lock`: the new content hash and a `platform-overrides` block. **No package versions change** — nothing currently locked requires a PHP newer than 8.1, so the pin only constrains future updates. ## Effect on local work `composer update` will now refuse a package that needs PHP newer than 8.1, even on a newer local PHP. That is the point, but it does mean the constraint shows up at update time rather than in CI — which is the trade being made. Note this pins *resolution* only. It does not affect which PHP actually runs anything: tests still execute on real 8.1/8.2/8.3/8.5 via the matrix. ## Security advisories fixed `composer audit` reported three advisories against the PHPCS stack, two rated high. All are dev-only and none ship in the plugin — `bin/build-zip.sh` installs `--no-dev` — but they execute against repository content on every CI run. | Package | CVE | | | |---|---|---|---| | `squizlabs/php_codesniffer` | CVE-2026-67434, OS command injection (high) | 3.13.5 | → 3.13.6 | | `wp-coding-standards/wpcs` | CVE-2026-45293, arbitrary code execution (high) | 3.3.0 | → 3.4.1 | | `phpcsstandards/phpcsutils` | CVE-2026-65954, arbitrary code execution | 1.2.2 | → 1.2.3 | The existing `^3.7` and `^3.0` constraints already allowed the fixed releases, so **`composer.json` is unchanged** by this part. `phpcsstandards/phpcsextra` (1.5.0 → 1.5.1) and `dealerdirect/phpcodesniffer-composer-installer` (v1.2.0 → v1.2.1) come along as transitive dependencies. Five packages move, none added or removed. The updated standards report **no new violations** — `composer cs` is clean without any code changes, which was the risk I flagged when I first suggested holding this back. `composer audit` now reports no advisories. ## Tests - `composer validate` — valid - `composer test` — 966 tests, 2795 assertions, OK - `composer lint` — no errors - `composer cs` — clean, on the updated standards - `composer audit` — no advisories No `CHANGELOG.md` entry: build tooling only, nothing user-visible.

thatguygriff added 1 commit 2026-08-25 01:46:13 +00:00

Pin the Composer platform to PHP 8.1 ... b17adf02ff

composer.json declares "php": ">=8.1", but resolution ran against whatever
PHP the machine doing the update happened to have. Running composer update
on 8.5 could therefore produce a lock containing a package that requires 8.2
or newer, which installs fine locally and fails on the 8.1 leg of the test
matrix — a lock that is only discovered to be wrong in CI.

config.platform.php makes resolution always target the declared minimum, so
a lock that resolves at all is a lock that installs everywhere the plugin
claims to run.

No package versions change: nothing currently locked requires a PHP newer
than 8.1, so this only records platform-overrides and the new content hash.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2

thatguygriff added 1 commit 2026-08-25 01:50:37 +00:00

Update the coding-standards tooling off three security advisories ... 908b7fcd1f

composer audit reported three advisories against the PHPCS stack, two rated
high:

  squizlabs/php_codesniffer  3.13.5 -> 3.13.6  CVE-2026-67434, OS command injection
  wp-coding-standards/wpcs   3.3.0  -> 3.4.1   CVE-2026-45293, arbitrary code execution
  phpcsstandards/phpcsutils  1.2.2  -> 1.2.3   CVE-2026-65954, arbitrary code execution

All three are dev-only and none ship in the plugin — bin/build-zip.sh installs
--no-dev — but they execute against repository content on every CI run.

The existing ^3.7 and ^3.0 constraints already allowed the fixed releases, so
composer.json is unchanged. phpcsextra and the codesniffer installer come
along as transitive dependencies. Five packages move, none are added or
removed, and the updated standards report no new violations.

composer audit is now clean.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2

thatguygriff changed title from Pin the Composer platform to PHP 8.1 to Pin the Composer platform to PHP 8.1 and clear the PHPCS security advisories 2026-08-25 01:50:52 +00:00

thatguygriff merged commit b3ed3a67d5 into main 2026-08-25 02:08:07 +00:00

thatguygriff deleted branch fix/187-composer-platform-pin 2026-08-25 02:08:07 +00:00

thatguygriff referenced this pull request 2026-08-25 02:09:17 +00:00

Update the dev dependencies #193

thatguygriff referenced this pull request 2026-08-25 02:10:30 +00:00

Payments: migrate stripe-php from 17.6.0 to 21.x #194

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

Something isn't working

enhancement

Extends an existing feature

feature

New user-facing capability

payments

Billing, Stripe, receipts, reporting

security

Security vulnerability or hardening

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

Kydoimos (Kydoimos) thatguygriff (James Griffin-Allwood)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#192