Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downloads should be validated #97

Open
pmuetschard opened this issue Oct 30, 2019 · 12 comments
Open

Downloads should be validated #97

pmuetschard opened this issue Oct 30, 2019 · 12 comments
Assignees
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request New feature or request

Comments

@pmuetschard
Copy link

The .bazelversion file should allow developers to specify the SHAs of the files downloaded so that we can rest easy knowing that the bazel used by bazelisk is, well, not tainted.

@philwo
Copy link
Member

philwo commented Oct 31, 2019

Nice idea and probably easier to implement than #17. :)

@pmuetschard
Copy link
Author

Oooh, I like the idea behind #17! It "automates" some of the work. Sorry, I filed this bug with a solution in mind rather than just asking for what I want... The title of the bug ("Downloads should be validated") is what I'd like, my comment above is a suggestion on how to do it and can be ignored :)

Maybe someone more versed in these things can guide you on whether #17 is enough or if pinning SHAs is "more secure" as it would protect against the bazel key being compromised.

@philwo philwo added the type: feature request New feature or request label Jan 26, 2020
@valeraz
Copy link

valeraz commented Feb 21, 2020

@philwo @alexeagle Just wanted to see if this is in the current work queue for your team. It would probably block any wide-spread adoption of bazelisk within our company. Thanks!

@rayhoffmann-ANSYS
Copy link

My browser is refusing to download the most recent version of of Bazelisk on Windows - it says a virus was detected. Has the download been tainted?
image

@philwo
Copy link
Member

philwo commented Sep 17, 2020

@rayhoffmann-ANSYS Thanks for letting me know. We had false positives with Chrome’s malicious binary checking in the past and I had to escalate them with the team to get them removed from there. But I’ll inspect this personally just to make sure!

Could you let me know whether you’re running a virus scanner and if yes which one on your computer?

@philwo
Copy link
Member

philwo commented Sep 17, 2020

I checked https://github.com/bazelbuild/bazelisk/releases/download/v1.6.1/bazelisk-windows-amd64.exe with virustotal.com and it came back all green (nothing detected). I’d assume a false positive, but would still like to resolve this. Any details about your virus scanner that complained about the binary would be welcome.

@rayhoffmann-ANSYS
Copy link

rayhoffmann-ANSYS commented Sep 17, 2020

We had McAfee installed on our computers. Windows Defender is running.
I don't know what scanner detected on download like that though...

@freddd
Copy link

freddd commented Sep 21, 2020

Hi @philwo, we are having the same issue as reported by @rayhoffmann-ANSYS. See here: https://www.virustotal.com/gui/file/eed3dd5ee2433275eab79f999276a7cc5d082a0360c439cb370183eaa94fc293/detection. I just tried uploading the latest windows binary and it comes back as green: https://www.virustotal.com/gui/url/494f82b50db61451cc09367b664dfb061ee22bb7fed9c641590fbf77a156c2c8/detection, strange.

@philwo
Copy link
Member

philwo commented Sep 21, 2020

@freddd Which version was the file that comes back red? Do you still have it?

Oh, now I get it - if you upload the file it's red, but if you pass the URL in, it's green. Weird. 🤔 I'm looking into this.

@philwo
Copy link
Member

philwo commented Sep 21, 2020

OK, I figured it out. Apparently Go binaries that are built for Windows often result in false positives:

Especially when you use LDFLAGS="-s -w", which I did in Bazelisk to reduce the binary size. It seems like with Bazelisk 1.6.1 I just got really unlucky and a lot of virus scanners believe they see something malicious in that binary, but it really is just something common to many Go binaries.

Here's my recommendation:

  • I'll remove the LDFLAGS from the Windows binaries for future releases, which means they'll grow ~2 MB, but at least it should reduce the chance of false positives.
  • For Bazelisk 1.6.1 you could reproduce the binaries on your own machine to ensure that I haven't accidentally put a virus in them.

Bazelisk 1.6.1 as downloaded from GitHub has this SHA256: eed3dd5ee2433275eab79f999276a7cc5d082a0360c439cb370183eaa94fc293.

Repro instructions:

I'm using a MacBook Pro (macOS 10.15.6), in case this matters - I'm not sure.

$ git clone https://github.com/bazelbuild/bazelisk.git
$ cd bazelisk
$ git fetch --tags
$ git checkout v1.6.1
$ ./build.sh
$ sha256sum bin/bazelisk-windows-amd64.exe 
eed3dd5ee2433275eab79f999276a7cc5d082a0360c439cb370183eaa94fc293  bin/bazelisk-windows-amd64.exe

If you also get the same hash, it's proven that the release binary was built from the unmodified sources of the tag v1.6.1.

@philwo
Copy link
Member

philwo commented Oct 6, 2020

Bazelisk v1.7.1 contains the workaround and is now "only" flagged by three scanners on virustotal.com:

image

Unfortunately Microsoft is one of them, which I guess might cause trouble. 😞 I'll try to send this to them for analysis so that they can update their signatures to not mark this file.

@sluongng
Copy link
Contributor

sluongng commented Feb 7, 2021

I thin #17 is not really bazel-ly. It would be nice to be able to checking a list of known SHA256 for corresponding bazel versions downloaded by bazelisk.

That would helps shops with their own patched bazel releases to use bazelisk without having to bother about gpg sig.

I also see that #17 is quite stale. How keen are you to review/merge an MR for SHA256 verify?

@fweikert fweikert added the P3 We're not considering working on this, but happy to review a PR. (No assignee) label Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants