Before you run a download, what does its signature prove?

Start before pressing Install

Imagine a small studio replacing a utility on its editing workstation. It finds a release page, a download from a community mirror and a message in a forum offering a faster link. The filenames look alike. Which file belongs on a machine that can read a client’s unreleased footage? The studio needs an answer that another person could check tomorrow, after the messages and download links have changed.

Our proposed approach starts with the decision: what software, from which project, for what role, on what machine? For a small command-line utility, that could mean a particular stable release and architecture. For a tool that will handle backups or credentials, the record should also identify the permissions it needs and who owns future updates. Without that expectation, a valid verification result may describe a different package than the one the team meant to approve.

Separate four questions. Do these bytes match the expected file? Who made the claim about those bytes? What does the claim say about how the file was produced? What would running it allow it to do? The first three can use technical evidence. The fourth requires a decision about the intended use. You can answer one and still need evidence for the others.

Lumacta analysis. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

A checksum compares bytes with a reference

Canonical’s Ubuntu download tutorial separates two checks. It uses a digital signature to authenticate a checksum manifest, then compares the downloaded installation image against the corresponding digest in that manifest. The manifest and signature are separate files, and the tutorial treats establishing trust in the signing key as a separate step.

Here is a hypothetical failure that shows why that order matters. Someone puts a modified installer on a lookalike website and displays the digest of that modified file beside it. A reader calculates the digest and gets an exact match. That is a successful comparison with the reference they were given. The question of who supplied that reference has simply never been answered.

A digest mismatch is a reason to stop. It could come from a wrong architecture, a different release, an incomplete download or unexpected modification. The mismatch alone cannot diagnose which explanation applies. Return to an independently trusted release channel, confirm the exact asset name and compare again. Substituting a digest copied from an unrelated forum would make the result harder to interpret, even if it turned green.

In a team, save the digest next to the release identity and the origin of the expected value. A pasted line of hex has little value at handover if the next person cannot tell which file it describes or who vouched for it. A useful record separates the digest you computed from the evidence you used as the comparison point.

Source notes: 1. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

A signature needs an expected signer

A signature can bind the file, or a manifest that names it, to a signing identity. Sigstore’s documentation shows verification against an expected certificate identity and issuer. For the signed-blob workflow it describes, the verification bundle carries supporting material, including a certificate and evidence of inclusion in a transparency log.

Write down whose signature should count before opening the verification result. With a long-lived signing key, the crucial relationship is between the key you trust and the project you intended to use. If the download page provides a file, a matching signature and a key you have never encountered, the signature can be internally consistent while the publisher relationship remains unresolved.

Suppose a project rotates its signing key. An unexpected key could reflect ordinary maintenance, an incorrectly selected download or an attack. The prudent response is to find the project’s trusted announcement or ask the person who maintains its approval policy. Silently adding a new key just to make the check pass removes the very decision the verifier was meant to preserve.

The same logic applies when certificates express identity through a service. For example, a team may expect an approved release workflow rather than any identity associated with a hosting platform. “A certificate was valid” leaves out the expected signer and issuer. A decision record should keep those expectations and the observed result together.

Source notes: 1, 2. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

A build attestation describes an origin you can check

GitHub documents build attestations as signed claims that can link an artifact to its workflow, repository and source commit. SLSA’s verification guidance asks verifiers to check the artifact and provenance against an established trust root, then compare the builder and build parameters with their own expectations.

Imagine the studio accepts a utility only when it comes from the project’s approved release workflow. A verified claim from a different workflow could accurately describe a file and still fail that policy. The important distinction is between a true statement about an artifact and a statement you are prepared to rely on for this job.

A build claim also needs to describe the right object. Keep the verified file associated with the claim you checked. If the studio later extracts an installer from a verified archive, its evidence concerns the downloaded archive and the resulting chain of custody. If someone hands over a similarly named installer separately, the original archive check does not establish that separate file’s origin.

Consider what provenance would change about a real decision. It could make a package acceptable when you previously could not connect it to a known build. It can also expose why a test artifact is out of scope. By itself it cannot explain whether the project made a good design decision, whether dependencies have security defects, or whether the installer should be allowed to read the studio’s footage.

GitHub also documents a release-asset verification command that checks a file against an attestation associated with a particular release. That is a different question from checking which source and build workflow produced a binary. Record which type of statement you checked before treating the result as evidence of a build path.

Source notes: 3, 4, 5. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

A check another person can repeat

Begin from a release source you have reason to trust. Record the intended product, release, platform and exact file. Keep links to the release page and its published verification instructions. If the official route and the forwarded link disagree, resolve that before selecting a file. Time spent on verification cannot repair a mistaken product choice.

Choose a check that the publisher actually supports. For a signed manifest, verify its signer through the project’s trusted instructions and then compare the matching file entry. For an attestation, compare the artifact and the expected publisher or build information. If one piece is absent, record the gap. An absent attestation may mean the project does not offer that evidence for this release; it is not the same outcome as a mismatching digest.

Make three outcomes visible: verified within scope, unresolved, and failed. Verified within scope means the check you specified passed for the file you selected. Unresolved means you could not establish something required, such as the identity of a replacement key. Failed means the observed evidence disagreed with a stated expectation. Keeping those categories apart helps avoid both unnecessary alarm and an unsafe assumption that every interruption is harmless.

For a handover, include the file identity, the evidence links, what you expected to observe, what you actually observed and the decision. Someone reading it should be able to tell whether a result was copied from the vendor, generated by the team’s own verifier or still pending. If the release asset changes, the old record remains evidence for the old bytes.

In a recurring workflow, save the approved expectations separately from the new candidate. Changing those expectations to fit a result is a different decision from verifying an ordinary update. A documented change can be reasonable, but it should remain visible to whoever relies on the outcome.

Source notes: 1, 3, 4. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Make installation a separate decision

Suppose every available check passes for a small editor. An install on a disposable machine with sample files and an install on a workstation holding client material are still different decisions. Ask whether the publisher and update channel are suitable, whether the permissions are proportionate and what would be at risk if the software behaved unexpectedly.

The comparison need not become a heavyweight audit. A person installing a familiar application can document the official route, check the available evidence and stop when an unexpected warning needs investigation. A team approving a package for a critical service may require a narrowly specified builder, an owner for exceptions, a reversible rollout and a record of the running version afterward. The amount of evidence should reflect what the change can affect.

An exception deserves a bounded scope. If an older tool does not publish provenance, consider whether an approved distribution route supplies adequate evidence for the intended use. If the risk cannot be understood or a required check fails, hold the install. A different path may be appropriate, but it should be assessed on its own terms rather than inheriting the result from the first file.

After approval, keep the verified artifact tied to the actual deployment. A shared folder named “final” can drift as people replace its contents. Confirm which reviewed file was handed off and which version actually reached the machine. That closes a practical gap between the approval of a download and the environment in which the software now runs.

Lumacta analysis. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

When two credible results point to different choices

Consider a second hypothetical. A lab keeps an older utility because an instrument vendor still supports it. Its old installer matches a signed manifest. A newer binary has provenance from a recognized project workflow, but the lab cannot establish that it supports the instrument. These results are useful in different ways. The first supports the identity of the known installer. The second supports the origin of the newer build. Neither settles compatibility or the security trade-off of retaining the older release.

Write the unresolved choice in operational terms. What would the lab need to observe before adopting the newer release? It might need a trial with representative input, an export that another workstation can read, and a recovery route if an instrument stops responding. These are proposed acceptance criteria. Passing a cryptographic check cannot take the place of the observations, and a successful trial cannot authenticate a package that came through a different path.

A small log makes this manageable. Preserve the result for each candidate, identify which constraints matter today, and agree when to revisit the decision. If a support bulletin, signing key or required permission changes, the review can restart from the relevant question. That is better than inheriting a generic “approved” label from an earlier install.

Lumacta analysis. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.

Read the result at the level it supports

This is a targeted reading of Canonical’s documented example, Sigstore’s verification model, SLSA’s verifier guidance and GitHub’s descriptions of build and release evidence. The sources explain mechanisms and policy choices. They do not measure how often a consumer encounters a tampered download or establish a success rate for the proposed workflow.

Our scenarios and comparison are editorial analysis. We did not download a sample installer, verify an actual signature, inspect a signing key or test a deployment. The method is useful when it leaves a reader with a precise claim about a specific file and a clear record of the decision that followed.

Source notes: 1, 2, 3, 4, 5. Comparisons and implications are Lumacta’s evidence synthesis; Lumacta did not run the downloads, verification commands or security tests described here.