search

boostorg / boost

Super-project for modularized Boost
https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Overview
Boost Software License 1.0
7.02k stars 1.73k forks source link

Feature request: SHA256 for GitHub release downloads #838

Open ecorm opened 8 months ago

ecorm commented 8 months ago

I'm using CMake's FetchContent to download the latest Boost release as part of my project's CMake build process. It's possible to pass an SHA256 hash to FetchContent so that it can verify the integrity of the download.

However, if I look at the assets listed in the Boost GitHub release page, there aren't any files there containing meta-information like SHA256 hashes.

I tried using the SHA256 hash available here at jfrog.io. CMake complains of SHA256 mismatch when I try using that hash:

verifying file...
[cmake]        file='/home/build/_deps/fetchboost-subbuild/fetchboost-populate-prefix/src/boost-1.84.0.tar.gz'
[cmake] -- SHA256 hash of
[cmake]     /home/build/_deps/fetchboost-subbuild/fetchboost-populate-prefix/src/boost-1.84.0.tar.gz
[cmake]   does not match expected value
[cmake]     expected: 'a5800f405508f5df8114558ca9855d2640a2de8f0445f051fa1c7c3383045724'
[cmake]       actual: '4d27e9efed0f6f152dc28db6430b9d3dfb40c0345da7342eaa5a987dde57bd95'

Of course, now I know that the hash is supposed to be 4d27e9efed0f6f152dc28db6430b9d3dfb40c0345da7342eaa5a987dde57bd95, but it would be better if that were published somewhere in an official manner.

To clarify, it's the GitHub release downloads that lack a published SHA256.

amadou1998 commented 8 months ago

Same problem for me.

Lastique commented 5 months ago

SHA256 checksums for the official archives are published in release notes.

ecorm commented 5 months ago

SHA256 checksums for the official archives are published in release notes.

I don't remember exactly, but I think that SHA256 only works with the jfrog download link, and not the GitHub release tarball.

Lastique commented 5 months ago

The checksums in the release notes only cover the archives on jfrog. The archives on GitHub are different and there are no published checksums for those.

ecorm commented 5 months ago

The archives on GitHub are different and there are no published checksums for those.

That's why I raised this issue. I should have made that clearer in my description.

mclow commented 3 months ago

The archives on GitHub are not official releases.

ecorm commented 3 months ago

The archives on GitHub are not official releases.

Not official, no, but I get a feeling that they're more reliable as a download source than the hosting provider that seems to change every few years. First it was boost.org, then something about a frog, now boost.io. The download provider changes keep breaking my CMake scripts.

pdimov commented 3 months ago

I should probably do something about having SHA256 hashes for these archives, but I'm not sure what.

mclow commented 3 months ago

The archives on GitHub are not official releases.

Not official, no, but I get a feeling that they're more reliable as a download source than the hosting provider that seems to change every few years. First it was boost.org, then something about a frog, now boost.io. The download provider changes keep breaking my CMake scripts.

If they work for you, then you should keep using them. But do so with the knowledge that they are different from the official releases, are neither tested nor supported.

ecorm commented 3 months ago

If they work for you, then you should keep using them. But do so with the knowledge that they are different from the official releases, are neither tested nor supported.

I will keep using them, and the lack of a "official" SHA256 hash for the GitHub version is an inconvenience, but not a showstopper.

I'll edit the title of this issue to make it clearer that it's a feature request.

Lastique commented 3 months ago

I should probably do something about having SHA256 hashes for these archives, but I'm not sure what.

Usually, projects publish .sig files along with tarballs. This is secure because the public key to verify the signature is published elsewhere - e.g. on www.boost.org.

If you publish a checksum on GitHub, whether in a separate file or in the release description, it cannot be used as a method of ensuring authenticity of the tarballs, because an attacker with access to the GitHub account could forge the checksum along with the tarball. The only solution in this case would be to publish the checksums on www.boost.org as well. But that would be difficult to do - you'd probably have to create a PR to the website from the release CI, and then someone has to merge it, too.

pdimov commented 3 months ago

An attacker with access to the Github account would be able to forge the signatures as well. He would just rerun the Github action that creates the release artifacts.

Signatures would only provide security if someone creates them locally and uploads them separately.

Lastique commented 3 months ago

The attacker would not be able to forge the signatures because he would not have the private key to sign the tarballs.

Lastique commented 3 months ago

Although, yes, you are correct he could re-run the CI. So if the CI has access to the private key then the key can be considered compromised.

pdimov commented 3 months ago

We can in principle have a private key as a Github secret etc, but that's smoke and mirrors. Better not pretend we have secure signatures if we don't.

Anyway, I added a few sha256sum calls to release-cmake.yml, so the next release should have associated .txt files.

https://github.com/boostorg/boost/commit/2ff30383d7e8056e5facb5d8020a1ed0a90d10e5