CI: generate checksum for release file

[axetroy]

release file

deno-x86_64-apple-darwin.zip
+ deno-x86_64-apple-darwin.zip.sha256
deno-x86_64-pc-windows-msvc.zip
+ deno-x86_64-pc-windows-msvc.zip.sha256
deno-x86_64-unknown-linux-gnu.zip
+ deno-x86_64-unknown-linux-gnu.zip.sha256
deno_src.tar.gz
+ deno_src.tar.gz.sha256
lib.deno.d.ts
+ lib.deno.d.ts.sha256

reference https://github.com/go-gitea/gitea/releases

[dsherret]

Alternatively consider creating a single SHASUMS256.txt file similar to what Node does: https://nodejs.org/download/release/v14.9.0/SHASUMS256.txt

I'm not sure what the advantages are one over the other though.

[ry]

I'm happy to add this - but I wonder how you intend to use these? Is it just for manual checking or is this to interface with some software?

[dsherret]

~~@ry I would use them in the version manager I'm working on to help generate these files https://bvm.land/deno/1.3.2.json which are used to install versions of deno.~~ Edit: I don't need this anymore.

[axetroy]

I'm happy to add this - but I wonder how you intend to use these? Is it just for manual checking or is this to interface with some software?

yes. Deno's version management tool needs to be verified after download Deno.

There are also runtimes of other cloud platforms, such as vercel/heroku, even Github Action

[VishnuJin]

Would be cool to have a checksum file associated with the release !! For example Krustlet has this

[stabai]

I wonder how you intend to use these? Is it just for manual checking or is this to interface with some software?

Bazel is one such piece of software that expects hashes to be present for all packages it includes. The main purpose of this is to ensure the package integrity before installing it into the dev workspace (it wants to ensure it has the expected version of the package and nothing has changed unexpectedly).

The rules_deno repository contains Bazel rules for running Deno scripts, and the process for adding a new Deno release to its catalog is much more burdensome than it could be.

Current process:

1. Fetch release info
2. For each release asset... a. Download the entire file b. Compute its hash c. Associate it with the release info
3. Write release details to file

With a single hash file, it could simply be:

1. Fetch release info
2. Download hash file and crossreference with release assets
3. Write release details to file

[dfang]

Any progress? is this hard to implement? :(

[maxwell-k]

I am delighted to see progress with this issue. Thank you.

In the Gitea example used in the initial request the checksum published is a sha256 hash of the file published for download. This approach, used by Gitea, is the only approach that I have seen used by other open source projects.

The implementation here surprised me. The checksum published for deno 2.0.0 is the sha256 hash of the uncompressed file. This can only be checked after it is extracted from the zip file published for download.

This can be seen in the implementation where the sha256 hash is calculated and then the file is compressed and stored in a zip.

@littledivy / @bartlomieju would you consider a pull request to change to the other approach? I am proposing the file is first compressed and then the hash is calculated.

One argument for hashing the compressed file is that you do not want to decompress an untrusted file; if a malicious change has been made to the file it is better to detect the problem earlier.

Comparison of Gitea vs Deno approaches at the command line

Commands to download Gitea files:

curl -OL https://github.com/go-gitea/gitea/releases/download/v1.22.3/gitea-1.22.3-linux-amd64
curl -OL https://github.com/go-gitea/gitea/releases/download/v1.22.3/gitea-1.22.3-linux-amd64.sha256

Command to check Gitea hash:

sha256sum --check gitea-1.22.3-linux-amd64.sha256

Output:

gitea-1.22.3-linux-amd64: OK

Commands to download Deno files:

curl -OL https://github.com/denoland/deno/releases/download/v2.0.0/deno-x86_64-unknown-linux-gnu.zip
curl -OL https://github.com/denoland/deno/releases/download/v2.0.0/deno-x86_64-unknown-linux-gnu.sha256sum

Command to check Deno hash:

sha256sum --check deno-x86_64-unknown-linux-gnu.sha256sum

Output:

sha256sum: deno: No such file or directory
deno: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

Command to decompress / extract:

unzip deno-x86_64-unknown-linux-gnu.zip

Command to check Deno hash:

sha256sum --check deno-x86_64-unknown-linux-gnu.sha256sum

Output:

deno: OK

[maxwell-k]

Just as another example NodeJS takes the same approach as Gitea and hashes the compressed files; as can be seen for the last release at https://nodejs.org/dist/v22.9.0/SHASUMS256.txt.

If it is better to put this request in a separate GitHub issue please let me know.

[marvinhagemeister]

Re-opening as we should generate the checksum from the final archive instead of the uncompressed one.