are there checksum available ?

[ilia-shipitsin]

hello,

small question from github runner images team.
we are looking for improving supply chain security.

are there checksums or some other integrity validation recommended ?

cheers

[ferd]

If you mean checksums available for the builds created by Rebar3, we do maintain checksums for dependencies's sources in the lock file, and Erlang has an option you can supply to make builds deterministic. We do not compute a checksum for the artifacts created however, only on the elements used to define the final build with the assumption that a repeatable build yields a repeatable result.

If you mean for the rebar3 binaries themselves, then no, we currently do not create these. Do you know if the build is obtained from github or from the s3 bucket? Neither has checksums published but I'm curious either way.

That being said, the artifacts we build both to S3 and github themselves are all automated. I guess a checksum could protect you from a third-party later changing the file in its final storage location, but as far as I can tell doing that without the ability to also update the checksum on similar storage is unlikely. I could imagine making it easier to invalidate cached copies at least.

[ilia-shipitsin]

thank you!

I've forgotten to mention, we are looking for rebar3 binaries validation. we download them from GitHub releases, but we usually try to download from the location officially proposed by project, we can change to S3 if needed.

I understand that idea to keep checksums together with binaries is not the best one. We are fine to download checksums from whatever location the project suggests. for each tool we track both URL and checksum validation (it maybe some URL or something else)

[ferd]

We haven't set that up at all, but I assume we could as part of automation. S3 generally contains only the latest main build, so github is likely the better place to do it, given we already automate part of the release process in

rebar3/.github/workflows/publish.yml

Lines 24 to 33 in a16f41a

	- name: Create Release
	id: create_release
	uses: actions/create-release@v1
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	with:
	tag_name: ${{ github.ref }}
	release_name: ${{ github.ref }}
	draft: false
	prerelease: false

I'll try and find time to prototype this workflow somewhere for the next builds, chances are I'd have to either do it as an extra attached file (

rebar3/.github/workflows/publish.yml

Lines 35 to 44 in a16f41a

	- name: Upload Release Asset
	id: upload-release-asset
	uses: actions/upload-release-asset@v1
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	with:
	upload_url: ${{ steps.create_release.outputs.upload_url }}
	asset_path: ./rebar3
	asset_name: rebar3
	asset_content_type: application/octet-stream

) which could just be called rebar3.checksum.

Do you have any preferences in terms of algorithms?

[ilia-shipitsin]

SHA256 / SHA512 are approved by our security team