Skip to content

chore(composer): patch twig + symfony/yaml security advisories - #305

Merged
rubenvdlinde merged 1 commit into
developmentfrom
chore/composer-sec-twig-yaml-softwarecatalog
May 26, 2026
Merged

chore(composer): patch twig + symfony/yaml security advisories#305
rubenvdlinde merged 1 commit into
developmentfrom
chore/composer-sec-twig-yaml-softwarecatalog

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Bumps dev-only transitive deps twig/twig (>=3.26.0) and symfony/yaml (>=6.4.40) to clear composer audit advisories (11 twig + 3 symfony/yaml CVEs). Dev tooling only (phpqa/robo), no runtime impact. composer install --dry-run clean, 0 removals, platform-overrides unchanged (8.3).

@rubenvdlinde
rubenvdlinde merged commit d368a90 into development May 26, 2026
11 of 15 checks passed
@rubenvdlinde
rubenvdlinde deleted the chore/composer-sec-twig-yaml-softwarecatalog branch May 26, 2026 04:27
@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/softwarecatalog @ 3c26ff8

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
composer ✅ 120/120
npm ❌ 2/775 denied
PHPUnit ⏭️
Newman ⏭️
Playwright ⏭️

❌ Denied npm licenses

Package Version License
pako 1.0.11 (MIT AND Zlib)
sha.js 2.4.12 (MIT AND BSD-3-Clause)

Quality workflow — 2026-05-26 04:30 UTC

Download the full PDF report from the workflow artifacts.

rubenvdlinde added a commit that referenced this pull request Aug 9, 2026
…relation (#473)

gate-54 relation-dialect 1 -> PASS, measured with hydra-gates 365fa31 at the CI
scope (--scope-to-diff --base origin/beta).

`contract.decisions` references decidesk Decision objects (ADR-066). It carried
BOTH `x-external-register: "decidesk"` AND `$ref: "Decision"`. OpenRegister
resolves `$ref` inside ONE register set and can never reach another app's
schema, so that $ref is dead weight — it names a target nothing will ever look
up.

Earlier today I measured this same finding against package 651e5c5, concluded
it was an unclosable gate gap, and left it red with that reasoning — .github
#305 says exactly that, and I added my instance to it. That conclusion is now
WRONG: .github#286 landed hours later and gave the cross-app case a dialect.
The gate is right and the register was wrong.

The sanctioned form is `x-external-register: <app>` on the property carrying
the bare identifier (`type: string` + `format: uuid`), with no `$ref`. The
annotation moves to the PROPERTY as well as the item, because
`_is_external_ref()` reads it on the property; on `items` alone it is invisible
to the gate, which is why the old generic "does not resolve" message fired
instead of the new cross-app one.

Can-fail: restoring the $ref puts gate-54 back to 1.
gate-51 stays PASS; the register still parses.
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