7 ms·
It's a lot worse than the standard configure, make and make install. For one, it's only requiring one simple script to get compromised and replaced to compromi
by ebbv 13y ago
It's a lot worse than the standard configure, make and make install.
For one, it's only requiring one simple script to get compromised and replaced to compromise your entire machine. At least when I download the tarball, unpack it, etc. I've got several steps before I even get to the make install that I would run as root. And I might not even do that depending on my install target. If I do, I have ample opportunity to verify the package in question and examine the script I'll be running via sudo before I do so.
With the instructions provided by this site, not only is there no opportunity to verify the script I've received is the one I wanted to (HTTPS alone is not enough for this, the site or domain may have been compromised) but they're instructing me to just run it immediately as root without any examination.
This is a terrible practice, and while yes it has been around for a long time in the past it was something only done and encouraged by idiots, it seems to be gaining popularity.
This is a bad idea, stop doing this people.
Provide an install tarball and provide a checksum of it that we can verify.
- tlrobinson 13y ago"Provide an install tarball and provide a checksum of it that we can verify." https://github.com/timothyej/Shortfin https://github.com/timothyej/Shortfin My point was the people who are going to blindly run curl/sh commands are also going to blindly download the source tarball and run configure/make/make install, and the people who want to do more verification are certainly free to do so.
- lstamour 13y agoI wonder how much work it would be to modify that one-liner to include an MD5 or SHA1 check? Of course it might then be shell and OS-specific... Unless curl or wget can confirm the sha1? Oh... found it! http://superuser.com/questions/453823/is-there-a-tool-that-automatically-downloads-and-compares-md5sums http://superuser.com/questions/453823/is-there-a-tool-that-a...
- nmat 13y agoWithout HTTPS in the main site that is mostly useless
- lstamour 13y agoTrue. Though for a bit of benefit, if the download was hosted separately from the site, that'd be two things to hack. The downside, of course, is that script updates would require new SHA1s. It would be best, then, to insert version numbers into the installer scripts, and a version check. That way if a new version comes out, the installer could warn about it (y/n), while still verifying the SHA1.
- ebbv 13y agoYes people are going to dumb things. But that doesn't mean you need to encourage and facilitate it. That's my point. If you know better you should be facilitating the proper way to do it, not the worst way.
- tlrobinson 13y agoTeaching people good security practices is a lot more involved than telling them to run 3 commands instead of 1.
- skrebbel 13y agoI'm a Windows user. Virtually every piece of software I install comes in the form of an executable, that I download-and-run directly from the browser. I often give this executable administrator priviledges. The executable can then do whatever it wants on my computer. Usually it will install said piece of software (except when it was made by Oracle, it'll install said software and the Ask.com toolbar) This has been standard practice for decades. It's very comprable to that wget oneliner. Why is it bad? Or, why is the wget oneliner bad but not Windows installers? Do Windows sysadmins compile tarballs and verify checksums? Or are Windows sysadmins simply dumber/less paranoid than Linux sysadmins?
- ebbv 13y agoYou're giving those executables full control over your computer. Yeah, you won't get burned very often (depending on where you're getting these executables.) But when you do get burned it's going to be catastrophic. That's the problem. It's a bad practice.
- skrebbel 13y agoHm, I see your point. How would you then recommend installing non open source software on a production system? E.g. a freeware (but proprietary) FTP server or a database engine.
- hrjet 13y agoIf you are taking recommendations, I wouldn't recommend installing them at all. You could ask the authors to support a platform which has a better security model. (Given that there are open-source and robuster-than-Windows platforms freely available.).
- jamespo 13y agoCool, I'll just email MS and ask them to port Sharepoint to BSD.
- at-fates-hands 13y ago>>>>Provide an install tarball and provide a checksum of it that we can verify. This 100%. When I first started experimenting with Linux after being a lifelong Windows user, this was the same advice I got from a seasoned Linux developer: ALWAYS COMPILE FROM SOURCE - NO EXCEPTIONS. He just told me even though Linux is secure and not as big a target as MS, he said you want to establish good habits from day one and not get lulled into a false sense of security.
- reidrac 13y agoWhy? If you don't trust your Linux distributor then you need to find a different one, but I don't think the answer is compiling everything from source; specially if the upstream project doesn't support 100% your target distribution. See: http://www.debian.org/security/ http://www.debian.org/security/
- jnbiche 13y agoWhat? You don't need a tarball to be able to verify the package via a checksum. In fact, a good packaging system will do checksums automatically, plus offer public key signature verification. I know deb and rpm files do that, and I believe many Windows packaging systems also provide checksums and public key signing. So do apt, aptitude, yum etc. On most of these systems, you even have to manually disable this option if you don't have the repo's public key. In fact, of all the install methods I use regularly as a Linux user, the only one that does not offer automatic checksums and public key signing is make. You can certainly verify checksums and public key signatures, but you have to do it manually. Do you look through all the code you build from source? Highly unlikely. If not, what's the point? Security is a lot more social screening than many people in the tech world would like to think. Know and trust the people you are running code from. If you don't know and trust them and still need their code, that's when you want to spend a couple of hours reviewing the source.
- Ecio78 13y agoALWAYS COMPILE FROM SOURCE - NO EXCEPTIONS. And still you can have problems if the source package has been compromised: https://news.ycombinator.com/item?id=6167000 https://news.ycombinator.com/item?id=6167000 [ok it's javascript] http://www.exploit-db.com/exploits/15662/ http://www.exploit-db.com/exploits/15662/ [source code -ProFTPD] http://www.cert.org/advisories/CA-2002-28.html http://www.cert.org/advisories/CA-2002-28.html [source code - Sendmail] etc.. or do you want to tell us that you inspect every line of the source code before compiling something?
- superuser2 13y agoIf the site or domain is compromised, wouldn't a mildly competent attacker change the hashes also?
- deleted 13y ago[deleted]
- jnbiche 13y agoNo, they're not depriving you of any opportunities to verify. They're offering you a shortcut if you decide that you trust them enough to forgo examining thousands of lines of code. If you decide you want to review the code, just wget it down and then install it after you review it. And if someone doesn't know enough command line to do that, are they really going to be in a position to audit the code?