Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
A fast and static web server for serving web apps
21–30 of 135 posts
Re: A fast and static web server for serving web apps
#22What's a "static web server"? I haven't seen this term. A webserver for only static pages, i.e. it won't talk to a runtime? But it's "for serving web apps", this means all the dynamic content is pulled from client side JS? Then you would still need programs on the server to answer AJAX requests. I did not find an explanation on the page or by Googling.
Re: A fast and static web server for serving web apps
#23Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
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."
Re: A fast and static web server for serving web apps
#24Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
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.
Re: A fast and static web server for serving web apps
#25>wget http://shortfin.io/install.sh && sh install.sh Isn't it recommended that any project doing one-line installs use HTTPS?
Side-note for the author: the download can be made more elegant that way $ curl http://shortfin.io/install.sh | sh I definitely agree with the HTTPS. For example this is what meteor proposes: $ curl https://install.meteor.com | sh
Streaming your install script directly into computer execution without even giving it a once-over, md5 compare, etc is atrociously insecure.
Re: A fast and static web server for serving web apps
#26okay ... why? what's special about this? features? benchmarks? anything?
The author claims it's 'high-performance and open-source' - sounds good to me. It's not as if we have a hundred web servers all competing as we do static blogging systems, the more web servers the better in my opinion, just as with web browsers.
The zip file is 312KB as linked from here, so it's pretty compact, possibly suitable for embedding in apps, etc:
Re: A fast and static web server for serving web apps
#27Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
Yes, it's a thing, and aside from the lack of HTTPS it's not much worse than your standard "./configure", "make", "make install" install flow of the last 20-whatever years of open source. If you don't trust the developer to serve you a safe install.sh script you shouldn't trust the rest of their code either. If you don't trust them you should audit the code no matter what the install process looks like. That said, if…
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.
Re: A fast and static web server for serving web apps
#28What's a "static web server"? I haven't seen this term. A webserver for only static pages, i.e. it won't talk to a runtime? But it's "for serving web apps", this means all the dynamic content is pulled from client side JS? Then you would still need programs on the server to answer AJAX requests. I did not find an explanation on the page or by Googling.
A server that only serves static files. It doesn't enable the use of dynamic content like CGI[1]. Compare this to something like Apache or nginx. Both can serve static files but also support a number of ways of either directly running scripts (ex: mod_perl or mod_php in Apache) or proxying to other servers that handle dynamic content. [1]: https://en.wikipedia.org/wiki/Common_Gateway_Interface
Re: A fast and static web server for serving web apps
#29What's a "static web server"? I haven't seen this term. A webserver for only static pages, i.e. it won't talk to a runtime? But it's "for serving web apps", this means all the dynamic content is pulled from client side JS? Then you would still need programs on the server to answer AJAX requests. I did not find an explanation on the page or by Googling.
In fact, I think the op needs to explicitly mention thttpd on the page for shortfin and provide a performance comparison, since that's all anyone really cares about ... "is it faster than thttpd ?"
Re: A fast and static web server for serving web apps
#30Earlier quoted context omitted.
Side-note for the author: the download can be made more elegant that way $ curl http://shortfin.io/install.sh | sh I definitely agree with the HTTPS. For example this is what meteor proposes: $ curl https://install.meteor.com | sh
asdfsdfgkjlsdfg! Streaming your install script directly into computer execution without even giving it a once-over, md5 compare, etc is atrociously insecure.