Check a download yourself.
No Avano release has been published yet, so there is nothing to check today. This page is ready for the day there is. It takes the APK, the signed build manifest and the SBOM that come with a release, and the release key we publish, and runs on them the same verifier as the command line avano-attest verify-apk: the same checks, in the same order, saying the same words. The files never leave your browser. The verifier is a WebAssembly module that imports nothing: it has no network, no clock and no way to send anything anywhere, only the bytes you hand it.
Three files and a key. One answer.
It catches a swapped download. It cannot vouch for the site that served it.
What a pass shows: the manifest was signed by the key in the field, your APK is byte for byte the file that manifest names, your SBOM is the one it names, and every rebuild it records agrees with your APK once its signature is taken off. So a copy from a mirror, a cache or a link somewhere else, or a damaged download, is caught the same way the command line catches it.
What it cannot show, against whoever controls this site: they could replace the APK, the manifest, the key in the field and this page together, and the page would pass. Two things narrow that, and they are yours to do. Compare the key's fingerprint with a copy from somewhere this site does not control (the source repository once it is public, and a second place we will name with the first release). And check the verifier itself: this page runs verify.wasm, 160,934 bytes, SHA-256 99d434f8 56bf3bc8 9664e102 1d0dd887 3842a166 85e515b9 eaad2863 bc527a0f (computed now from the file this page loaded: not computed yet), which bash rust/avano-verify-web/build.sh builds from a checkout or an archive of the commit that published it (on Linux, with rustup's 1.97.0 toolchain; archives of one commit built in three different directories gave the same bytes, and the build is repeated and compared every night). The command line built from that source is the strong form of this check; this page is the convenient one.
What neither shows: that the build is honest, which only independent rebuilds show; or that you were shown the same manifest as everyone else, which only a public transparency log with witnesses shows, and this verifier does not read the log. The proof page grades each of these claims on the same question.
Seven answers, each with its own number.
| Code | Meaning |
|---|---|
| 0 | Every check passed. |
| 1 | A file could not be read, or the key is not valid hex. |
| 2 | The manifest does not parse: damaged, truncated, or a format this verifier does not know. |
| 3 | The manifest was not signed by the key in the field. |
| 4 | The APK is not the file the signed manifest names. |
| 5 | The SBOM is not the one the signed manifest names, or the manifest names none. |
| 6 | A recorded rebuild disagrees with this APK, or fewer builders agree than you required. |
The same numbers the command line exits with (proof, and docs/BINARY-PROOF.md in the source).