[Docs] Publish how to verify the vendored JavaScript against upstream #641
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck#641
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in the pre-publication security review.
Evidence:
tool/check_bundled_js.dart:10-18compares each file against the sha256 inassets/web_export/MANIFEST.json— both in the same repository, so anyone changing one changes the other. What the manifest does carry is asource:per bundle, and that route holds: I fetcheddompurify@3.4.12andmarked@18.0.5from jsdelivr and both hash exactly to the manifest values, and to the files on disk. But nowhere indocs/is it stated that this property holds, or how to check it.Why this matters: "why should I believe you have not touched 3.5 MB of minified mermaid?" is the first question a reviewer asks about an export that delivers 5.8 MB of third-party JavaScript to a client. The answer is strong — byte-identical to upstream, verifiable in one command — but it is not written down, and an unanswered question counts as a gap.
Proposal: three lines in
docs/SBOM.mdorTHIRD_PARTY_NOTICES.md: each bundle is an unmodified upstream build; verify withcurl -sL <source> | shasum -a 256and compare againstsha256in MANIFEST.json. Optionally a--verify-upstreamflag intool/check_bundled_js.dartthat does this for all six.