fix(xray): verify the release archive checksum before installing#5396
fix(xray): verify the release archive checksum before installing#5396n0ctal wants to merge 2 commits into
Conversation
UpdateXray downloaded the Xray-core release zip and installed the binary
from it after only a TLS fetch, an HTTP-200 check and a size cap — the
archive itself was never verified, so a corrupted or tampered release
asset would be extracted and run as the panel's xray binary.
Verify the downloaded archive against the SHA2-256 published in the
release's .dgst sidecar (which XTLS ships next to every asset) before
installing, and abort the update on mismatch, a missing/short SHA2-256
entry, or an unreachable .dgst. The digest parser and fetch are covered by
tests, including the real .dgst line format ("SHA2-256= <hex>").
|
Thank you very much for your contribution. I completely understand why you added this pull request—a faulty image/CDN, or a proxy that terminates TLS, leading to the prolonged use of an incorrect kernel. However, could you please add a warning if the SHA256 comparison is inconsistent? This warning would allow users to choose whether to proceed. This would be necessary for some users. The warning could be supplemented with something like: "When ordinary users see this message, it indicates that the image is corrupted or inconsistent with the official image; it is recommended to exit the installation and re-pull the image," or something similar. Please forgive any ambiguity in my wording. |
…smatch Per review feedback on the PR: on a SHA-256 mismatch, surface a plain-language warning that the downloaded archive is corrupted or differs from the official release and that the user should exit and re-download, instead of a terse "checksum mismatch" error. The install still aborts so a mismatched binary is never run; the message now tells the user the safe next step.
|
Thanks for the review! I've added a plain-language warning on a SHA-256 mismatch, using your suggested wording: it now tells the user the downloaded archive is corrupted or differs from the official release and to exit and re-download the official image before retrying. I kept the update aborting on a mismatch rather than offering a "proceed anyway", since auto-proceeding past a failed checksum would install a binary that may be corrupted or tampered with — exactly what the check is meant to prevent. The new message points the user to the safe next step (re-download). If you'd still prefer a user-overridable "proceed anyway" path, I'm happy to add it behind an explicit force flag — just let me know. |
2 participants
Summary
Verify the downloaded Xray-core release archive against its published
SHA2-256before installing, instead of installing it after only a TLS fetch + HTTP-200 + a size cap.Why
UpdateXray→downloadXRayfetched the release zip and installed the binary from it with no integrity check on the artifact itself. TLS protects the transport, not the bytes: a corrupted or tampered release asset (a bad mirror/CDN, or a proxy that terminates TLS) would be extracted and run as the panel's long-lived xray process.Scope
.dgstsidecar XTLS publishes next to each asset, parse itsSHA2-256(the label isSHA2-256=, notSHA256=), compute the archive's SHA-256, and abort on mismatch.dgstis unreachable or has no/shortSHA2-256entry — fail closed, never install an unverified archive. (Maintainer note: this hard-fails updating to any release without a published.dgst; happy to switch to warn-and-proceed if you'd prefer to keep installing those.).dgstread is capped at 64 KiBValidation
.dgstline format, plus missing/malformed entries) and the fetch (httptest 200 + 404)internal/web/servicepackage tests passRisk
Low. Adds a verification step inside the existing download path; no API or behaviour change beyond rejecting an unverifiable archive.