Live data from Hacker News

A fast and static web server for serving web apps

shortfin.io

81–90 of 135 posts

Re: A fast and static web server for serving web apps

#81
post #27

Earlier quoted context omitted.

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…

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 t…

>>>>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.

Re: A fast and static web server for serving web apps

#82
post #72
post #67

Earlier quoted context omitted.

because you wouldn't use anything from him because he isn't OpenBSD My sarcasm detector must be malfunctioning. Who said I don't want to use his software or install anything linked on HN because they're new? I've checked out and installed plenty of things linked on HN, not because they're new, but because they're interesting. But lax procedures like the root shell install aren't good indicators. In fact, I was just g…

> My sarcasm detector must be malfunctioning. Who said I don't want to use his software or install anything linked on HN because they're new? I've checked out and installed plenty of things linked on HN, not because they're new, but because they're interesting. But lax procedures like the root shell install aren't good indicators. Oh, my apologies. I think the context of your other comments caused me to misunderstand…

Accepted :)

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.

Re: A fast and static web server for serving web apps

#83
post #27

Earlier quoted context omitted.

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 t…

>>>>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…

Why? 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/

Re: A fast and static web server for serving web apps

#84

Earlier quoted context omitted.

I host more websites on the same server and as kajecounterhack said I'm using nginx as a reverse proxy. The server is fast and have no problems at all with the HM crowd ;)

What are advantages over nginx? Memory footprint, higher through-output? I mean, what's the main "selling point". Why should one use this instead of battle tested nginx? Don't get me wrong, I'm not criticizing, I'm just curious.

On my tests it's a few 100 requests faster per second than nginx but the average should be around the same. The kernel is the bottleneck in this case I believe.

There isn't any "selling point" ;) Anyone could use it as they like. The main usage for me has been in other projects where I needed a fast and lightweight http server. Such as tracking servers etc. It's pretty "experimental" but I think I will use the "original" server to serve a web app that I will be launching soon. The problem for me has been the lack of a reverse proxy.

Re: A fast and static web server for serving web apps

#85
post #48

Earlier quoted context omitted.

You'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.

Hm, 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.

1. Don't install software from untrusted sources. 2. The trusted sources should provide checksums so you can verify the package before installing it.

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...

Re: A fast and static web server for serving web apps

#86
post #27

Earlier quoted context omitted.

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 t…

>>>>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…

What? 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.

Re: A fast and static web server for serving web apps

#87
post #4

I don't get it. You create a server to solve C10K problem, and then host its own website with nginx? Why? Having HN crowd coming and testing your server would be a great test, no?

I host more websites on the same server and as kajecounterhack said I'm using nginx as a reverse proxy. The server is fast and have no problems at all with the HM crowd ;)

But why do you need reverse proxy at all if your server is as good as Nginx? And if the speed is comparable and Nginx has more features why did you write your server then?

Re: A fast and static web server for serving web apps

#88
post #25
post #12

Earlier 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.

    curl https://install.meteor.com  | less

Re: A fast and static web server for serving web apps

#89
post #27

Earlier quoted context omitted.

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…

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 t…

No, 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?

Re: A fast and static web server for serving web apps

#90
post #87

Earlier quoted context omitted.

I host more websites on the same server and as kajecounterhack said I'm using nginx as a reverse proxy. The server is fast and have no problems at all with the HM crowd ;)

But why do you need reverse proxy at all if your server is as good as Nginx? And if the speed is comparable and Nginx has more features why did you write your server then?

I've never stated that it was as good as nginx?

The answer to "why" is answered in these comments:

https://news.ycombinator.com/item?id=6168052 https://news.ycombinator.com/item?id=6168541

Post reply on HN