sha256 value mismatch for bazel-0.18.1-installer-darwin-x86_64.sh

[davemac327]

ATTENTION! Please read and follow:

• if this is a question about how to build / test / query / deploy using Bazel, ask it on StackOverflow instead: https://stackoverflow.com/questions/tagged/bazel
• if this is a discussion starter, send it to bazel-discuss@googlegroups.com
• if this is a bug or feature request, fill the form below as best as you can.

Description of the problem / feature request:

sha256 of bazel-0.18.1-installer-darwin-x86_64.sh does not match the value in bazel-0.18.1-installer-darwin-x86_64.sh.sha256

$ shasum -a 256 bazel-0.18.1-installer-darwin-x86_64.sh
ed9671b5a78c1f7cbaa3b36abcb9329dbfa869fae4593adec4acc3d07315b7cc bazel-0.18.1-installer-darwin-x86_64.sh
$ cat bazel-0.18.1-installer-darwin-x86_64.sh.sha256
7ba0f48f9dff3aaf7d1b3d69ae1ab8f3c3cffca54cf4e44cb7b1bd13c0f35dcf bazel-0.18.1-installer-darwin-x86_64.sh

Feature requests: what underlying problem are you trying to solve with this feature?

I want to trust the script before I run it

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Run shamsum -a 256 bazel-0.18.1-installer-darwin-x86_64.sh
Compare the output to the contents of bazel-0.18.1-installer-darwin-x86_64.sh.sha256

What operating system are you running Bazel on?

MacOS 10.13.6

What's the output of bazel info release?

N/A

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

N/A

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

N/A

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

No

[jin]

cc @meteorcloudy @aehlig

[jin]

0.18 release ref: #5963

[aehlig]

What happened was the following. During the release of 0.18.1, the upload of the artifacts to github failed[1]. This was dicovered[2] and, assuming bazel builds are reproducible, triggered the release pipeline again. However, as it turns out, our releases are `--stamp`ed, without setting SOURCE_DATE_EPOCH [3,4], so the newly generated binaries actually differ. But, of course, only those artifacts could be uploaded that weren't uploaded previously, thus causing the current mess. I'm already working with @philwo to set SOURCE_DATE_EPOCH in our release builds, to have reproducible binaries. For this particular release, can you update to the latest release, which is 0.19.0 [5]. If you have to stay with the 0.18 series, for darwin it is safe to stay on 0.18.0, as the difference between 0.18.1 and 0.18.0 is a fix for a windows-only issue. [1] https://buildkite.com/bazel/release/builds/132#8d31f5f3-62f0-4e07-a014-7436c402adc8 [2] https://groups.google.com/forum/#!topic/bazel-discuss/tI6Q5QmbFCQ [3] https://reproducible-builds.org/specs/source-date-epoch/ [4] https://github.com/bazelbuild/bazel/blob/f445af588e3f35464db73b880a2efbc39d0cebc6/src/main/java/com/google/devtools/build/lib/bazel/BazelWorkspaceStatusModule.java#L254 [5] https://github.com/bazelbuild/bazel/releases/tag/0.19.0

…

-- Klaus Aehlig Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[philwo]

As Klaus described, this was an issue of mixing the uploads of two runs of the release pipeline.

I've fixed this by downloading the release artifacts from our Google Cloud Storage bucket, manually verifying the checksums and signatures and then re-uploading them to GitHub.