Repository navigation
ordeal v0.22.1 — the bump that missed the #22 merge - #23
Merged
Merged
Conversation
…false result GHSA-xfxf-qxr3-435x (HIGH), published today, affects every ordeal release from 0.2.0 through 0.22.0 — including the v0.22.0 this layer pins. Shifts and rotations at non-power-of-two bit widths used too few barrel-shifter stages, so some satisfiable queries returned Unsat WITH AN LRAT CERTIFICATE THAT RE-CHECKS. The checker certified the CNF it was given and the CNF was the wrong encoding, which means the usual defence — "we do not trust the solver, we check the certificate" — does not catch it. That is worse here than in any one repo's CI. A layer is how this organisation distributes a prover; shipping the affected one hands every consumer a tool that can certify a wrong answer, and consumers pinned to 2026.09.16 have it now. v0.22.1 publishes the same four Linux assets, so the musl mapping added in this branch is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu
Contributor
Automated review for PR #23pulseengine/pulseengine-layers: Verdict: 💬 Comment Summary: Layer.toml update for ordeal version bump. Findings: 0 mechanical (rivet) · 1 from local AI model. Findings (1):
Generated by a local AI model and post-validated against a strict JSON contract. Each finding includes the verbatim line being criticised — verify by reading the file at the cited location. Reviewed at |
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
1 participant
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.
This realm still ships the affected ordeal.
mainpinsv0.22.0, insideGHSA-xfxf-qxr3-435x's range.
My mistake, stated plainly: I pushed the ordeal bump to #22's branch after
it had already merged. #22 merged at
04:56:42Zwith head0081baf— themusl commit alone. The ordeal commit sat unmerged on a dead branch while I
reported it as handled. Re-applied here on top of current
main.The scanner bumped synth
0.75.0 → 0.76.0after #22 landed. The%Rtemplates followed it, and I verified that rather than trusting the pattern —
all ten musl assets were resolved against the real release listings and
every one exists.
check-manifest.pypasses.Merging this still publishes nothing
Worth stating because it caught me: a merge to
maindoes not deposit.scan-and-deposit.ymlgates both the commit and the deposit onif: steps.scan.outputs.moved == 'true', andmovedis true only whenscan-pins.pyfinds a pin behind upstream. These pins are already atupstream latest, so the next scan reports "nothing moved" and exits — no
commit, no deposit, forever.
So a hand-edited
layer.tomlis never published by the scanner. The onlyautomatic path to a deposit is upstream drift. Publishing this needs a
deposit.ymldispatch, which I am not doing unilaterally: it signs andpublishes to consumers, and varve has no revocation.
Filed the general gap separately.