Just run the following command as root to install the server.
# wget http://shortfin.io/install.sh && sh install.sh
Just run the following command as root to install the server.
# wget http://shortfin.io/install.sh && sh install.sh
That said, if you're going to do this, you should do the following:
1. HTTPS only. No excuses.
2. No URL shorteners, which make or may not use HTTPS, and introduce another point of failure.
3. Ideally serve directly from Github repo. Eliminate another point of failure. The user can be reasonably confident that the install script is the same one that's in the Github repo.
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.
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.
Unless curl or wget can confirm the sha1? Oh... found it! http://superuser.com/questions/453823/is-there-a-tool-that-a...
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?
It's a bad practice.
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.
(Given that there are open-source and robuster-than-Windows platforms freely available.).
Suggesting that the best way to securely install Windows packages is to use a different operating system smacks of immaturity, and is obviously not a practical solution in Windows environments.
A better suggestion might be: If you do not trust it, run it in a VM/sandbox.
This protects you from a compromised package so long as the page you accessed the package from has not been compromised (if that page is compromised, the checksum could be changed to the new one).
I have no idea how you would verify closed source software if the checksum and package are both corrupted...
If the checksum is published to another trusted location, in addition to where you download the files, that would help in the case that an attacker compromises both the checksum and the package on the download site.
The developer could post the checksum to Twitter at the same time as making the package available for download. An attacker would need to compromise both Twitter and the download site.
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.
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.
etc..
or do you want to tell us that you inspect every line of the source code before compiling something?
I can tell you I don't do this every time. Now if I'm installing a 3rd party extension or plugin, I usually do it in a sandboxed environment, run some pen tests on it to check how secure it is and see if there's any malicious code before I install it on my machine or server.
And yes, even then, it is still possible to install malware on your machine.
and later run it on some unprivileged TCP port over 1024.
The lack of TLS is worrisome, but that's not so much "becoming a thing" as it is "a bad thing we're just finally starting to get rid of."
Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages.
I suppose this is tilting at windmills, though.
Yes, and you still can do that. But the standard installation instructions almost never include it. For example, nginx's build instructions boil down to "run configure, possibly with some flags, and then run make and/or make install". That includes the exact same vulnerability you complain of here — it never tells you to checksum anything. This is true for essentially all the software I've ever downloaded. So again, still not "becoming a thing."
The assumption is that if you're the sort of person who customarily checks code before they install it, you know how to inject that step.
Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.
Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post.
It's unrealistic to expect those who take security seriously to do so in the first place. Regardless of how often it's done elsewhere.
OTOH, there's a well known and trusted software distributor that does the vetting for you, which this project doesn't have, and I'd much rather do the "vetting-skipped install" if you will for something they distribute instead.
Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security.
That's not tautology. It's sane practice that I wish more people followed.
The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.
because you wouldn't use anything from him because he isn't OpenBSD
In fact, I was just going over his install script to see whether it's worth installing and test, but seeing things like this :
# The umask is ridiculous, or mkdir does not conform to POSIX,
# or it failed possibly due to a race condition. Create the
# directory the slow way, step by step, checking for races as we go.
case $dstdir in
/*) prefix='/';;
-*) prefix='./';;
*) prefix='';;
esac
Oh, my apologies. I think the context of your other comments caused me to misunderstand that one. Your initial comment was simply "Nginx is part of the base OpenBSD install," and I read your later comment as an explanation of that, which made it sound to me like "I'm OK with nginx because it comes with OpenBSD and not OK with the OP's server because he's not a trusted organization." I understand better now.
And I apologize as well. My posts were venturing over to the pushy/rude side and I don't want that to be the case.
Truth is that I do enjoy seeing new projects like this because it forces me to look at things with a fresh perspective. Yes, the install method did give me some pause, but maybe I've been spoiled by things that I'm comfortable with so I welcome the chance to pour over the code for something totally different.
Then again, most of us blindly run what we assume to be GNU autoconf scripts and never read Makefiles before we 'make install' as root. Nor do most of us read or audit source code, even for security-sensitive applications.
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin