Verifying every runtime you download
Libxa Desktop fetches PHP, Node, Nginx, MariaDB, phpMyAdmin and Composer, and then runs them. What gets checked, who produced each checksum, and what this posture does not protect against.
Libxa Desktop downloads PHP, Node, Nginx, MariaDB, phpMyAdmin and Composer, and then executes them. That is a lot of trust to place in a network connection, so it is worth being precise about what the app checks and when.
The rule
Every download is fetched over HTTPS from the publisher's own host. The SHA-256 is computed while the bytes are streaming to disk, and compared before anything is extracted. A mismatch deletes the file and aborts.
Hashing during the stream rather than reading the file back afterwards is not just about speed, though a second pass over a 100 MB archive is wasted I/O. It means the file never sits on disk in a state where some other code path might pick it up before it has been checked.
Where each checksum comes from
The distinction that matters is who produced the hash.
| Runtime | Verification | Who says so |
|---|---|---|
| PHP | vendor-checksum |
php.net's release manifest, fetched at install time |
| Node.js | vendor-checksum |
that release's SHASUMS256.txt |
| MariaDB | vendor-checksum |
their sha256sums.txt |
| phpMyAdmin | vendor-checksum |
the .sha256 beside the archive |
| Composer | vendor-checksum |
published alongside the phar |
| Nginx | pinned-checksum |
recorded by us from the official file |
Five of the six are the publisher's own hash, fetched fresh at install time. If they rebuild a release, we check against their new hash automatically.
Nginx is the exception. nginx.org signs releases with PGP but publishes no per-file checksum, so there is nothing to fetch. The hash was recorded from the official file over TLS and is pinned in the app. That is weaker: it trusts a single point in time, but it fails loudly if the upstream file ever changes, which is better than installing whatever arrives.
What this does and does not protect against
It protects against a corrupted download, a compromised mirror, and a man-in-the-middle who cannot also alter the checksum source.
It does not protect against a publisher whose own release was compromised at the source: the hash would match the bad file. Nothing a downloader can do solves that; it is what signing and reproducible builds are for.
It also does not make the pinned nginx hash equivalent to a fetched one. Worth stating rather than glossing over.
Before it runs
The UI shows you the source host, the publisher, the approximate size and the verification method before you commit to the download, not after, and not buried in a log.
Installs go to the app's own data directory. Nothing touches system
directories, nothing is added to PATH, and everything is removable from the
same screen that installed it.
The app's own updates
The same posture applies to Libxa Desktop updating itself. The updater fetches
latest.yml from the public releases repository, and that manifest carries the
SHA-512 of the installer. The download is checked against it before the
installer is allowed to run.
The releases repository is public even though the source is private, specifically so this works without credentials. Pointing the updater at a private repository would mean embedding a token in every copy of the app, which hands that token to anyone who unzips the build.
Builds are not code-signed yet. That is a real gap and it is why the installer triggers a SmartScreen warning. It does not weaken the checksum verification above, but it does mean you should only install builds from the official releases page.