Increasing security with asfd checksum checking

Checking a known valid hash

If you know the hash of a valid file, you can secure future downloads and detect changes in the file published. This is particularly useful in Dockerfiles as this technique ensures you more recent images use the same valid file.

The traditional way to do this in a Dockerfile is to combine multiple shell commands like this:

RUN version="v2024.9.6" && \
    sha="c835a3f72e640896ff171963eadc368efd29ef6962af34aa36de62eb45174109" && \
    curl -O -L https://github.com/jdx/mise/releases/download/${version}/mise-${version}-linux-x64 && \
    echo "${sha}  mise-${version}-linux-x64" | sha256sum -c

This snippet was written with upgradeability in mind, so that the switch to a new version is done simply by assigning updated versions to the variables version and sha. Authoring this snippet is cumbersome though, as the variable version is used in 3 different locations, the checksum piped to sha256sum may not include a typo (did you note that there are 2 spaces between the sha and the filename?).

Now, compare this to using asfd:

RUN asfd -h "c835a3f72e640896ff171963eadc368efd29ef6962af34aa36de62eb45174109" https://github.com/jdx/mise/releases/download/v2024.9.6/mise-v2024.9.6-linux-x64

It is much simpler to read and to update, and brings the same security level. It is also faster to author, increasing the probability of its continuous use.

Hosting checkums on a distinct server

Using a checksum file hosted on the same server as the downloaded file is a no big utility if the server gets hacked: the malevolent actor can replace both the file proposed for download and the checksums file. Doing this, downloaders would not detect that the file was updated by a third party.

This can be improved by publishing the checksums file on a distinct server. We do this at Asfaload. This increases security of downloaders as a malevolent actor would have to compromised 2 servers to update both the file proposed for download, and its checksums file.

This setup is fully supported by asfd with the -p flag. For example, if you have asfd installed, you can easily download a new version from our Github releases, but validating its checksums against a file published on our domain:

  asfd -p https://asfaload.com/asfd-releases/v0.1.0 \
      https://github.com/asfaload/asfd/releases/download/v0.1.0/asfd-armv7-unknown-linux-musleabi

Simplifying procedures for GPG signed checksums files

If the publishing party does not host the checksums on a distinct server, you can still do it yourself on your own server.

Some projects like mise publish checksums files signed with GPG, which which let you check the authenticity of the checksums files. GPG is cumbersome to use though. If this procedure has to be repeated, you can be sure it will be skipped sooner rather than later. Luckily asfd can help you simplify repeated downloads validations in this case too.

You start by downloading the checksums locally and validate their authenticity with GPG. You do this once, and then publish the checksum on your own server which needs to be correctly secured. As you validated the authenticity of the checksums file, and as your server is unlikely to be compromised by an attacker targetting the publishing project, you can use asfd with your locally hosted checksums files to detect if published files are altered on the publishing server.