Why
GHSA-j586-36cw-2gc2 (published 27 Oct 15:04 UTC, high) reports an unbounded memory leak in the msgpack C extension when strict_map_key validation fails: msgpack < 1.2.3, CVSS AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The scheduled Security run at 304877b (40458746490) failed on it. Tracked as #1205.
Change
Complete remediation across every tracked Python lock, each via uv lock --upgrade-package msgpack --directory <example>:
- Root
uv.lock: 1.2.1 → 1.2.4 (already in this PR). - Twelve example locks: 1.2.1 → 1.2.4 —
clickhouse-ops,customer360,delta-portability,ecommerce-replication,federated-domains,healthcare-claims,iot-telemetry,logistics-control-tower,market-data-fx,public-data-research,saas-product-analytics,wap-failure-lab. examples/lakehouses/source-to-report/uv.lockstays at 1.2.3: the advisory affects< 1.2.3, so it is not vulnerable.mission-controlhas no msgpack entry.
No manifest edits; each lock diff touches only the msgpack package block (version plus its wheel matrix). The example locks are split across six commits because the deployed writer still enforces its 2.5 MB request budget, which #1207 raises in code but which is not live yet; the branch content is identical to a single-commit change.
Verification
make check-example-locks # exit 0: every example lock resolves
uv lock --check # root lock current
python3 scripts/dependency_delta.py --base b8fef367 --head <tree> --mode queue
# assessment complete: 0 introduced, no msgpack finding in any lock,
# 2 unaccepted findings remainThe two remaining --mode queue findings are the seroval advisories in packages/phlo-observatory/src/phlo_observatory/package-lock.json (GHSA-9wx9-5pv9-3349, GHSA-f86p-h4j2-7qgj), owned by #1208 and unchanged by this diff.
The previous run's failing installed provider artifacts (0) job was the container policy evaluated on this branch's stale base, before #1207's MinIO go-jose fix; #1208, based on current main, passes the same job. This pushes fresh check runs against current main.
Not run: full make check (lock-only change); CI validates the branch.
Activity
306
coldtea-pr-lens[bot]18h agoNOTE
phlo-agent[bot] opened this pull request, so PR Lens left it undrawn. Comment
@pr-lens drawto draw it
github.comment.notice: false in .github/pr-lens.yml turns this note off
phlo-agent[bot]18h agoReviewed the complete diff at 70248be. No correctness, security, or compatibility findings.
Scope is complete and lock-only
- All 13 changed files are
uv.lock: the root lock plus the twelve example locks, each a singlemsgpackblock (73 additions / 48 deletions). No manifest edit, so the resolution graph is unchanged apart from this package. - GHSA-j586-36cw-2gc2 declares
< 1.2.3vulnerable with first patched version 1.2.3, so leavingexamples/lakehouses/source-to-report/uv.lockat 1.2.3 is correct, not an oversight.examples/lakehouses/mission-control/uv.lockhas nomsgpackentry, andcustomer360-transform,polaris-streamingandretail-filescarry no lock at all — every trackable lock is accounted for. - The new metadata is genuine, not hand-edited:
msgpack-1.2.4.tar.gz(sha256:475c44e1…, 197764 bytes) and the cp312 manylinux x86_64 wheel (sha256:c4d5bbdb…, 475652 bytes) match PyPI's published digests for 1.2.4. security/dependency-risks.jsonis still[], so no accepted-risk entry needed retiring alongside the bump.
What still has to prove this worked
The PR-level security / introduced dependency risk job runs scripts/dependency_delta.py --mode delta, which by its own comment in .github/workflows/pr.yml blocks only newly introduced vulnerable versions. A pre-existing 1.2.1 entry would not fail it, so green PR checks are not evidence that the vulnerable pins are gone. That evidence is the queue-mode scan: the nightly Security workflow or dependency_delta.py --mode queue.
Two consequences worth tracking:
- The latest scheduled Security run (#730,
main@b8fef36, 30 Oct 06:51Z) predates this PR entering the merge queue and still failed, so post-merge confirmation is outstanding. The head-SHA checks at 70248be are green (pr / required, core tests, integration, installed provider artifacts), but the merge-group run is the gating artifact. - #1205 is still open and its Development panel lists no linked pull request, so closing it depends on the next clean scan rather than on this merge.
The seven identical commit subjects are history noise, but the body's 2.5 MB writer-request explanation makes the split intentional and it does not affect the resulting tree.
security(deps): GHSA-j586-36cw-2gc2 in PyPI/msgpack 1.2.1
Phlo agent owns advisory triage, compatibility analysis and coordination with Renovate. Maintainers own escalation if automation is unavailable. An agent cannot approve an exception or replace the scanner verdict.
Independent assessment: https://github.com/phlohouse/phlo/actions/runs/40645337846
Affected consumer locks:
examples/lakehouses/clickhouse-ops/uv.lockexamples/lakehouses/customer360/uv.lockexamples/lakehouses/delta-portability/uv.lockexamples/lakehouses/ecommerce-replication/uv.lockexamples/lakehouses/federated-domains/uv.lockexamples/lakehouses/healthcare-claims/uv.lockexamples/lakehouses/iot-telemetry/uv.lockexamples/lakehouses/logistics-control-tower/uv.lockexamples/lakehouses/market-data-fx/uv.lockexamples/lakehouses/public-data-research/uv.lockexamples/lakehouses/saas-product-analytics/uv.lockexamples/lakehouses/wap-failure-lab/uv.lockuv.lock