doc: refresh the assurance status tables after the merge wave - #402
Open
xanimo wants to merge 1 commit into
Open
doc: refresh the assurance status tables after the merge wave#402xanimo wants to merge 1 commit into
xanimo wants to merge 1 commit into
Conversation
The assurance case was finalized last, as planned, so its tables recorded the board as it stood when dogecoinfoundation#366 was written. Thirteen PRs merged in the day after, leaving rows that still read "Landing", "Open" or "Draft" for work that is now on 0.1.5-dev. Updates both status tables against the actual merge state: dogecoinfoundation#359, dogecoinfoundation#351, dogecoinfoundation#357 (2026-08-04), dogecoinfoundation#360, dogecoinfoundation#346, dogecoinfoundation#347, dogecoinfoundation#348, dogecoinfoundation#363, dogecoinfoundation#365 (2026-08-05), dogecoinfoundation#328 (2026-07-22), dogecoinfoundation#361 (2026-07-21), dogecoinfoundation#362 (2026-07-30) and dogecoinfoundation#343 (2026-07-21). The BIP38 and wallet fuzz harnesses are recorded as unblocked rather than pending, since both dogecoinfoundation#351 and dogecoinfoundation#277 have landed. Adds a note recording that the cppcheck gate is currently red on 0.1.5-dev: it documents a phase-0 policy of gating on error severity but invokes --enable=warning --error-exitcode=1. Two of its 34 findings were real and are fixed in dogecoinfoundation#401; the rest are triaged in the note. An assurance document that claims static analysis is live should say that one of its three analysers does not currently pass on the base branch. No claims about coverage or verification results are changed -- only status, plus that note.
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.
#366 was finalized last, exactly as the merge order advised, so its tables record the board as it stood when it was written. Thirteen PRs merged in the day after, leaving rows that still read Landing, Open or Draft for work that is now on
0.1.5-dev.This updates both status tables against actual merge state — nothing else. No claim about coverage, CT verdicts or verification results is touched.
The BIP38 and wallet fuzz harnesses now read as unblocked rather than pending, since both #351 and #277 have landed.
One substantive addition
A note recording that the cppcheck gate is currently red on
0.1.5-devitself — reproduced on an untouched checkout, so it is not any one PR's doing.Its header documents a phase-0 policy of "only
errorseverity fails the job", but the step named gate on error severity invokes--enable=warning --error-exitcode=1, so warnings fail it. 34 findings on the base:fscanfinto a fixed buffer reachable through the public wordlist API, and table indexing guarded only by anassertthat compiles out underNDEBUG%dused with unsigned values — real but cosmeticwallet.c/utils.c, still to triageHASH_DEL/assert, and the OP-TEEuninitvarhits areTEEC_MEMREF_TEMP_OUTPUTbuffers the TA writes intoEither the gate narrows to match its stated policy, or the backlog is dispositioned in
contrib/analysis/cppcheck-suppressions.txt. Until then it is red on every PR.An assurance document asserting that static analysis is live should say when one of its three analysers doesn't pass on the base branch. Fixing the gate itself is a separate PR.