Looks like you're using a SSL cert for www.github.com rather than for http://brew.sh


Edit: Logged this here before realising that it probably wasn't the correct place...
The canonical URL is http://brew.sh not https://brew.sh
@ilovezfs that's not fantastic, especially for a website that tells users to curl a command straight into bash...
We're aware that we do not have SSL certificates for the brew.sh domain.
The fact that you manually typed in https:// and then had your browser note that the content is in fact on GitHub and the GitHub site uses a GitHub certificate is not the same thing as brew.sh having an invalid certificate, sorry.
I did not manually type it, that is your assumption.
I was taken there as the top search result when using a search engine, also although not in this case browsers are starting to ship with the option to use SSL first.
Security is especially important when dealing with a package manager, please take this seriously.
What search engine has "https://brew.sh" as the top result? That sounds like a bug in that search engine.
It doesn't sound like a bug, it sounds like good search engine behavior!
DuckDuckGo
Chrome 52.0.2793.0
OSX 10.11.5
Regardless, as I said, this is a package manager, please consider security, especially when you're suggesting that it's a good idea that users curl straight to shell from the internet, if they don't use SSL anyone could MITM that link of yours and people could be infected with malware etc...
@MikeMcQuaid @UniqMartin - your thoughts on users curling straight from an unencrypted website to their shell?
DuckDuckGo's top result is "http://brew.sh/" so it's your browser configuration.
... so why not fix the broken SSL cert?
Also, why are you ignoring my comments about telling users to curl to shell straight from an unencrypted website?
Yes, it would be nice if we had an SSL certificate for brew.sh. I understand that you'd like that to be the case. Feature request noted.
The fact remains, however, that the SSL certificate is not "broken" because there is no SSL certificate for brew.sh. The only reason you're seeing that is because _something_ is coercing the URL to "https://brew.sh" which will then end up triggering GitHub to cough up a (valid) GitHub SSL certificate. The GitHub SSL certificate is not for the brew.sh domain, it's for the GitHub domain, and your browser then notes that the SSL certificate is not in fact for brew.sh, which is indeed true.
So again, the issue here is why is your browser ending up directing you to https://brew.sh
May I suggest that a warning is added to the website about curling blinding from websites to shell and perhaps providing users with the MD5/SHA sums of the downloaded file as some assurance that they haven't been compromised?
We're using GitHub Pages for our website. This is a known limitation of GitHub Pages when used with a custom domain. See this help article for details. SSL certificates cost money and/or require paid hosting with SSL support. We don't have a steady income that would currently allow us to pay for that.
There's ongoing discussion in Homebrew/homebrew.github.io#98 and that issue also links to previous discussions for context. Please read (all of) this and then see whether you can help us improve the situation. Practical suggestions and pull requests are welcome, but “spamming” this issue doesn't help resolve the problem—and yes, I agree that it is suboptimal that our website isn't served via HTTPS.
Giving up, message regarding curling to shell clearly not taken on board.
@sammcj posting a checksum for the install file doesn't sound unreasonable, though it would have to be updated every time there's a commit to https://github.com/Homebrew/install/
Note that the URL being curl'd actually is indeed using https
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
https://raw.githubusercontent.com/Homebrew/install/master/install is the GitHub raw content link for this file https://github.com/Homebrew/install/blob/master/install
If you don't trust http://brew.sh/, you can always get the instructions for the installer directly from its repository (see the README) or clone our GitHub repository (see Alternative Installs for details).
If a website or some third party asks you to paste stuff into your terminal, you _always_ have to be careful and understand what you are doing, no matter where you get that information from.
Giving up, message regarding curling to shell clearly not taken on board.
We didn't ignore this part of your issue and we're aware of the problem, as stated above. But we don't have a satisfying solution yet. If you can contribute to a solution, please do! But only complaining doesn't help get this resolved and unfortunately there's no such thing like “simply enabling HTTPS” …
@UniqMartin I'm still curious how in the world it's ending up at https://brew.sh if he's not manually entering that and DuckDuckGo is correctly pointing to http://brew.sh. I can't reproduce the issue with Chrome or DuckDuckGo locally, though.
@ilovezfs I suspect some browser plugin that alters the links locally. Maybe it's just checking whether the web server is responding at all to HTTPS requests and then gets fooled by GitHub Pages which in (my understanding) serve from the same web servers no matter if it's *.github.io or some custom domain.
Yup, a browser plugin is my guess, too. It would be nice to know which one in case this comes up again (and so it can be reported to the plugin developer!), since that's pretty broken behavior.
I agree. This information would be helpful to have.
@sammcj Life tip: messages provided with a patronising tone will generally not be taken on board.