I dislike that the only way they list to install is "curl https://get.please.build | bash". I know it's fast and easy but it really leaves your computer at their mercy.
I see no way in which this "leaves your computer at their mercy" more than any other process of purposefully executing code they control on your system.
I would caution you to use the phrase “no way in which” when discussing security - the less informed may read this and believe it.
While an edge case and requiring a mailicious targeted attack in this case there’s at least the possibility of being MiTM’d.
The problem - as you’re probably aware - with using absolute terms when speaking about a case like this is that it’s easy to extrapolate this sense of safety to something that may lead to an attack that requires much less precision thank convincing the browser that the MiTM proxy is “please.build”.
For the inner downloads in the script, they use the -fsSL flags, which would protect against such broken behaviour. But not their use-facing script.
More to the point, the install just downloads:
https://get.please.build/${GOOS}_amd64/${VERSION}/please_${V...
then unzips and links it to PATH. No checking the source isn't corrupt, no checking if the tar archive successfully expands. (And the var GOOS seems to depend on an environment variable I don't think is guaranteed to exist. It certainly doesn't on my Mac.)
If that's the case... Why not just provide a download link? It won't have the same issue as a broken install if the connection drops, and is just as easy. The only technical bit, linking to PATH, is something the end audience could be expected to know.
What they should be doing is to understand what's actually going on.
Once you download and run software from a TLS enabled website, you're putting trust in that website. It doesn't really matter if you are doing 'curl https://example.com | bash' or downloading a binary. They can't be MITMed any more so with the curl way than downloading a binary.
That's all there is to it. I realize there are many security people who advice against doing the curl thing, but I feel people should realize it is a rule of thumb with unsecured websites.
It’s sometimes easy to forget that there are various reasons people are less informed. For people early in the career for example, reading security advice on HN and believing it is not unheard of especially when you have real experts on here who know what they’re talking about.
Something that is “all there is to it” for you is not necessarily the same for someone else. I’m not saying it’s anyones job to inform them; just that it’s better not to speak in absolutes.
If security folks say something, I assume there’s a good reason until I become a security folk myself - it’s one of those fields where being sceptical about everything third-party helps.
My point really wasn’t about the MITM but a there’s always a possibility that a proxy on a public/compromised network can intervene between you and a “secured” website.
Binaries can be verified with checksums to make sure that the artifact hosted on the repository is indeed what you received. You are 100% correct that you are still trusting the code from the third party developer though!
Same can happen to a binary.
>Binaries can be verified with checksums to make sure that the artifact hosted on the repository is indeed what you received
Here's the problem. The checksum is usually on the same page the binary is located. Which pretty much defeats the purpose.
I guess the only threat there (that I can see) is that the install script can be malicious, but your point was that you’re trusting the owners of the website anyway by downloading their binary and executing their code locally. It can be argued that it’s probably easier to ship malicious code outside the main repository (e.g. in an install script) but I do not have a good counter besides this weak argument.
The checksum is indeed usually on the same page and does make it useless in my hypothetical MITM.
in any event, it's more surface area. their web server being compromised and serving a bad shell script is just more that can go wrong.
If they were serving up a binary you would have the same exact threat that you mentioned.
The threat model barely, barely changes when talking about curl | sh vs downloading and manually executing a binary. Barely.