chore(security): phpcsutils 1.2.2 → 1.2.3 (CVE-2026-65954) - #184
Merged
Conversation
`phpcsstandards/phpcsutils < 1.2.3` carries CVE-2026-65954. `composer audit`
fails on advisory data alone, so a repo that changed nothing goes red once the
advisory propagates — openbuild's Security (composer) cell was still green as of
run 31524590763 (18:11Z), so this is ahead of the failure rather than after it.
Lock-only bump via
`composer update phpcsstandards/phpcsutils --no-install --no-scripts`;
`composer audit` reports no advisories after it. The bump is exercised by CI
actually RUNNING phpcs, not merely by locking it.
Does not touch openbuild's three E2E failures — all three are pre-existing and
none is attributable to any openbuild diff:
- `automations-rbac.spec.ts:124` — the first-open `CnSupportDialog` modal mask
intercepts the click. It is opened by an HTTP **200** carrying
`{"value": null}` from `/api/preferences/support-dialog-seen`, so it is not an
error dialog and not a symptom of the #173 500. The repo already ships
`suppressSupportDialog()` and 13 spec files use it; this one does not.
- `automations-rbac.spec.ts:152` — the fixture app it selects is never created
on CI. `ci-seed.sh` seeds only `hello-world`; the locator resolves to zero
candidates.
- `version-rollback.spec.ts:263` — commit `2b1a8900` FAILED it in run
31438032584 and PASSED it in run 31459739568, same `head_sha`, so it predates
PR #182 entirely.
The first two are fixed by the test-harness half of PR #177, which is
review-only by explicit instruction, so they are left for that review rather
than duplicated here.
Contributor
Quality Report — ConductionNL/openbuild @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| test-l10n | ✅ | ||||
| check-gitignore | ✅ | ||||
| check-nc-floor | ✅ | ||||
| composer | ✅ | ✅ 101/101 | |||
| npm | ✅ | ✅ 654/654 | |||
| PHPUnit | ✅ | ||||
| Newman | ⏭️ | ||||
| Playwright | ❌ | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-08-11 21:27 UTC
Download the full PDF report from the workflow artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lock-only bump of
phpcsstandards/phpcsutils1.2.2 → 1.2.3 for CVE-2026-65954.composer auditfails on advisory data alone, so a repo that changed nothing goes red once the advisory propagates. openbuild'sSecurity (composer)cell was still green as of run 31524590763 (18:11Z), so this lands ahead of the failure rather than after it.composer auditreports no advisories after the bump, and it is exercised by CI actually running phpcs rather than only locking it.This does not touch openbuild's three E2E failures — and here is why, measured
All three are pre-existing and none is attributable to any openbuild diff.
automations-rbac.spec.ts:124— a support dialog, not the #173 500Dies at line 130 clicking
getByRole('combobox', {name:/application/i}). The input resolves and is "visible, enabled and stable"; every retry names:useSupportDialog(fromCnAppRoot.vue,persistence: 'server') GETs/apps/openbuild/api/preferences/support-dialog-seen. openbuild is one of the few apps that actually serves that route, andPreferencesController::getPreference()answers HTTP 200 with{"value": null}— which the resolver reads as "not seen yet" and shows the modal. A 200 opens it. It is not an error dialog and not a symptom of the #173 500.The repo already ships
tests/e2e/support/appFixture.ts::suppressSupportDialog()and 13 spec files import it. This one does not.automations-rbac.spec.ts:152— the fixture app is never createdDies at line 159 on
getByRole('option', {name:/rbac.?automations.?app/i})with nolocator resolved toline at all — zero candidates, so this one is not the dialog. Ondevelopmentthe stringrbac-automations-appappears in exactly 3 places, all constants and comments inside the spec itself.ci-seed.shseeds onlyhello-world;global-setup.tsprovisions the fourrbac-*users and no such app. The spec's own header records that the app was created by hand via the wizard during a live-verification session.version-rollback.spec.ts:263— predates PR #182 entirelyhead_sha2b1a8900automations-rbac:124,:152,builder-host.spec.ts:44,version-rollback:2632b1a8900automations-rbac:124,:152Same commit, opposite verdicts. #182's diff touches three
tests/e2e/spec-coverage/files and nothing near it.Two things left deliberately undone
The first two failures are fixed by the test-harness half of PR #177, which is review-only by explicit instruction. Duplicating
suppressSupportDialogand its fixture-buildingbeforeAllinto this PR would conflict with a PR under human review and would land part of it by the back door. Left for that review — with one correction posted there: #177's green E2E demonstrates its harness changes, not its RBAC fix, because neither failing test ever issues an enable request.version-rollback:263is not masked. The available fix moves the row assertion insideopenVersionHistory's existing retry loop. It would go green — and if the mechanism candidate is right (CnObjectSidebar.vuere-anchoringactiveTabunconditionally on anytabsarray-identity change, so the sidebar silently snaps back off "Version history"), it would hide a user-visible defect behind a retry. That mechanism is inferred from shipped source and not observed live — testing it needs a rig, and disk here is at 97%. A flake and a product bug look identical from CI; masking one masks the other.