> ## Content Index > Fetch the complete content index at: https://blog.meganova.ai/llms.txt > Use this file to discover other available public pages before exploring further. # How to Verify AI Model and Runtime Downloads with Checksums - URL: https://blog.meganova.ai/how-to-verify-ai-model-and-runtime-downloads-with-checksums/ - Published: 2026-11-11T07:24:39.000Z - Updated: 2026-11-11T07:24:39.000Z - Author: Tracy Giang - Tags: LibraOS AI software often runs close to your most sensitive data. A self-hosted agent runtime reads your documents, holds conversations and calls your systems. A local model server sees every prompt. So the files you install deserve the same scrutiny as any other part of your security setup. The first line of defense is simple: check that the file you downloaded is the file the publisher released. This guide explains how checksums and image digests do that, what they don't prove, and how to carry verified files into an air-gapped network. ## **Checksums: what they are and how to check one** A checksum is a short fingerprint calculated from a file's contents, most often with SHA-256\. Change a single byte of the file and the fingerprint changes completely. Publishers list the expected checksum for each release file; you calculate it for the file you downloaded and compare. LibraOS, for example, ships its Runtime as one binary with published SHA-256 checksums. Its download page shows the check: ``` # compare the binary with its published checksumcurl -fsSLO \  https://github.com/libraos/releases/releases/latest/download/SHA256SUMSsha256sum -c SHA256SUMS --ignore-missing ``` The first command downloads the list of expected checksums. The second calculates the checksum of each file you have and compares; --ignore-missing skips entries for files you didn't download. A line ending in OK means that file matches. Anything else means stop: don't run it, download again from the official source, and compare again. The same idea works for any release that publishes checksums, whatever the tool: calculate, compare, and only run what matches. ## **What a checksum doesn't prove** A matching checksum tells you the file wasn't corrupted in transfer and matches the list you compared it against. It doesn't tell you who made that list. LibraOS's download page says it plainly: a checksum detects transfer corruption or a mismatch; it does not independently authenticate the publisher. Why that matters: if an attacker could replace both the file and the checksum list in the same place, the two would still match. A checksum protects against accidents and some tampering, not against a compromised source. | Check | Answers | Doesn't answer | | -------------- | ------------------------------------------------------- | --------------------------------------------------- | | Checksum | Is this the exact file the list describes? | Who published the list? | | Signature | Was this signed by a key the publisher controls? | Whether that key is still safe, or the code is good | | Release review | What changed, and what does the publisher say about it? | Hidden behavior in the code | So treat checksum verification as one layer. Download from the official source over HTTPS, review the release notes and verification instructions the publisher provides, verify signatures where the publisher offers them, and keep a record of the versions and checksums you installed. ## **Containers: pin by digest, not by tag** Container images are identified two ways: - **A tag,** such as :latest or :v1.2, is a label. The publisher can point it at a different image later. - **A digest,** such as @sha256:…, is the image's own fingerprint. It always refers to exactly the same image. Pulling by tag means the image you run next month may not be the one you tested today. Pulling by digest means it is. LibraOS's download page recommends pulling its images pinned by digest for the same reason. In practice: test with a specific release, record its digest, and reference that digest in your deployment files. When you upgrade, you change the digest deliberately, after testing the new image, instead of picking up whatever a tag points to at the moment. ## **Carrying verified files into an air-gapped network** An air-gapped network can't download anything, so verification happens outside it, before transfer: 1. **Download on a trusted, connected machine:** the binary and its checksum file, from the official source. 2. **Verify there.** Run the checksum check and review the release notes before anything moves. 3. **Transfer both files** through your organization's approved process. 4. **Verify again inside,** if your process allows: the same check confirms nothing changed in transfer. 5. **Record what you installed:** version, checksum and date. Model files deserve the same treatment. They're large, they come from many publishers, and they run next to your data. Plan updates the same way before you need them, so an urgent fix doesn't turn into an unverified shortcut. ## **Checklist** - ☐ Software comes only from the publisher's official source, over HTTPS. - ☐ Every file is checked against its published checksum; only matching files run. - ☐ Release notes and the publisher's verification instructions are reviewed. - ☐ Signatures are verified where the publisher offers them. - ☐ Container images are pinned by digest, not by tag. - ☐ For air-gapped networks, files are verified on a trusted machine before transfer, and again inside if possible. - ☐ Model files go through the same checks. - ☐ Installed versions, checksums and dates are recorded. ## **Conclusion** Verifying a download takes a minute and catches corrupted or swapped files before they run next to your data. Check every file against its published checksum, pin container images by digest, and verify outside before you carry anything into an air-gapped network. Then remember what a checksum can't tell you, who published the list, and add the other layers: the official source, release review, and signatures where they're offered. > **Explore LibraOS:** [libraos.com](https://libraos.com/?ref=blog.meganova.ai) ## **Sources** - [LibraOS Download](https://libraos.com/download/?ref=blog.meganova.ai) - [LibraOS release repository](https://github.com/libraos/releases?ref=blog.meganova.ai) - [LibraOS Security & Private Deployment](https://libraos.com/security/?ref=blog.meganova.ai) ### **What’s Next?** [**Sign up**](https://console.meganova.ai/register?referral=e0602d28&utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink&ref=blog.meganova.ai) and explore now. 🔍 **Learn more:** Visit [**our blog**](https://blog.meganova.ai/?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) and [**documents**](https://docs.meganova.ai/?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) for more insights or [contact us](https://www.meganova.ai/contact-us?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink) for a demo of how MegaNova can power your AI products. 📬 **Get in touch**: Join our [Discord community](https://discord.com/invite/QBTnGurDw4?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fai%5Flaunch&utm%5Fcontent=body%5Flink) for help or [Contact Us](https://www.meganova.ai/contact-us?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=blog%5Fmn%5Flaunch&utm%5Fcontent=body%5Flink).