Provide checksum

[chulkilee]

How can I get the expected checksum of zip files so that I can check it against the calculated checksum from downloaded files?

[ericmj]

What's the use case for the checksum?

[chulkilee]

Make sure the downloaded file is not changed by others. Of course I can download the current file and use the checksum of it, but it would be nice if checksum is released together at the same time.

For example, the current official elixir docker image uses elixir-lang precompiled one with own checksum (since it's not provided): https://github.com/c0b/docker-elixir/blob/bd537f8d1a54491020854186e509d2c98960578b/1.6/alpine/Dockerfile#L9

Note that the published checksum should not be easily modified (especially when the file to protect is compromised). One way to do that is.. put the checksum in the CHAGENLOG of git repo, like kubernetes: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.8.md#v1814

I don't know alternative. Maybe hex.pm later support package signature?

[ericmj]

This project does automated builds of Elixir and uploads them to S3 for each push to the elixir github repository. Since it's automated and done so frequently I don't think we should commit checksums to Elixir for each build. I don't think it would help to upload the checksums to S3 either since if S3 is compromised you can change both the builds and the checksums.

Instead I think it would be better to add checksums to the official builds https://github.com/elixir-lang/elixir/releases. But again, anyone who has permissions to change the builds has permissions to change the checksum in the repository, but the git history would make it easier to discover tampering.

Also note that the Dockerfile you linked uses official builds, not builds from this project.

I don't know alternative. Maybe hex.pm later support package signature?

I don't think this is related to hex.pm since elixir is not a hex package.

[chulkilee]

S3 is compromised you can change both the builds and the checksums.

For this exact reason, k8s puts the checksum to CHANGELOG in git repo.

it would be better to add checksums to the official builds https://github.com/elixir-lang/elixir/releases

I agree that should be done, but I'd like to use build on this project since I'd like to use otp-variant build :)

Also note that the Dockerfile you linked uses official builds, not builds from this project.

I know that - I mentioned that because you asked for the use case of checksum. Also note that I created a issue on that repo to use hexpm/bob to support otp-variant images. See c0b/docker-elixir#63

I don't think this is related to hex.pm since elixir is not a hex package.

Oh, I thought it uses the same structure as a hex package. However, we still may use same way to sign a hex package and an elixir build from bob - e.g. using same key.

[ericmj]

I agree that should be done, but I'd like to use build on this project since I'd like to use otp-variant build :)

Do you have a proposal for how to provide checksums for automated bob builds without adding noise to the elixir repository?

For this exact reason, k8s puts the checksum to CHANGELOG in git repo.
Oh, I thought it uses the same structure as a hex package. However, we still may use same way to sign a hex package and an elixir build from bob - e.g. using same key.

Signing and providing a checksum is very different. User-signed packages is a complicated subject that has been discussed extensively. I think we should focus on checksums in this issue.

[chulkilee]

Do you have a proposal for how to provide checksums for automated bob builds without adding noise to the elixir repository?

I think checksum of bob builds should be on bob repo, not elixir repo for now. I don't know how bob builds are "official" though.

I think we should start with 1) having checksum from the build, and then 2) providing checksum in secure way.

For getting checksum - we may upload a file with checksum for each file - probably inside build_upload at

bob/scripts/elixir_github.sh

Line 80 in 4b4b879

aws s3 cp *.zip "s3://s3.hex.pm/builds/elixir/${1}${2}.zip" --cache-control "public,max-age=3600" --metadata '{"surrogate-key":"builds","surrogate-control":"public,max-age=604800"}'

For prevent from tampering - I think that needs wider review and consideration of the whole system - where bob is running, and etc.

If bob builds are more of "official" builds of Elixir (I believe so) then it would be better to call for help from wider community - especially experts on this matter (secure build/release/artifact management).

[ericmj]

I think we should start with 1) having checksum from the build, and then 2) providing checksum in secure way.

Until we can provide trusted checksums I don't want to provide them at all because it would give a false sense of security.

I don't think checksums for builds are useful because elixir builds are not reproducible and there's no guarantee that a new build for an existing version won't be triggered. We would have to change how bob works for that.

Checksums don't provide a lot of value because they only guarantee that the build hasn't be tampered with, but it provides no guarantee that the build system itself has not been compromised. We would need reproducible builds for that. Because of this I don't think there's much value in changing how bob works.

Until we have reproducible builds I would recommend building from source if you want secure Elixir builds.

For prevent from tampering - I think that needs wider review and consideration of the whole system - where bob is running, and etc.
If bob builds are more of "official" builds of Elixir (I believe so) then it would be better to call for help from wider community - especially experts on this matter (secure build/release/artifact management).

I don't think the builds being official or not should change anything. Any help you can find from people with experience would be appreciated of course.

[chulkilee]

I don't think checksums for builds are useful because elixir builds are not reproducible and there's no guarantee that a new build for an existing version won't be triggered. We would have to change how bob works for that.

That's why I think it may need some help from more than this project - elixir build config or build experts.

Checksums don't provide a lot of value because they only guarantee that the build hasn't be tampered with, but it provides no guarantee that the build system itself has not been compromised.

I know the problem, but I think providing checksum only for preventing tampered binary is still worth it (compared to nothing). And as I mentioned, it can be gradual process.

Again, checksum is not silver bullet but it definitely adds some value.

[ericmj]

Will be fixed in #17.

[amuino]

I'm not sure #17 will fix this issue.

As far as I understand, it is providing just the githuh sha, so it is useful in that you know the code used for the build but is not useful to detect tampering… am I right? Should we reopen this issue even if just as a reminder?

[ericmj]

You are right, #17 only adds git shas, we need to add the sha for the zip as well. We can build on #17 and add the zip sha to the same file.

[ericmj]

We merged #17 now so if anyone wants to work on adding checksums it should be fairly easy to build on the previous PR.

[wojtekmach]

Closing in favour of #34.