Definitely a cool collection of, as the article calls them "quick wins." The stablelib.com business model is pretty interesting too. Not sure what to think about it.
The business is subscription, getting access to a (proprietary?) command line tool and "exclusive" (subscriber-only, proprietary?) training materials? That's what I guess from the home page. Accurate?
Mostly it's for commercial support (maintenance: bug fixes, backporting of patches, security alerts, and technical support) of the packages included in the distribution, as we don't have the tool (will probably be open sourced) or exclusive content yet. Thanks for the interest!
How do you defend yourself against somebody just mirroring the libraries?
I was just researching licenses for a similar business model (in a completely different field) and came to the conclusion, that it does not really work.
AGPL would somewhat work, but would still have the downside that commercial entities could use the software just for tooling and internal processes, which most software is used for anyway.
In my mind Open Source prevents commercial use of applications only if the software is very likely to be shipped to the client, for example Qt.
With libraries it might look different, because people just get used to them and want to use them everywhere.
Sorry for the late reply! Since the original upstream packages are all open source, there's pretty much no point in mirroring. The major value of such business is mainly commercial support, which includes maintaining compatibility and solving the problems that clients have with packages.
I guess it's great to know you /could/ do this in Go. But wouldn't anyone serious about these particular options just choose to apply them in Nginx? It's not like Go has completely kicked Nginx out of the mix. I still use it for static files (I trust/know Nginx caching) and for SSL termination (though yes, this /could/ be done in Go).
Would you use these options in Go or would you just set them at the reverse-proxy level?
> wouldn't anyone serious about these particular options just choose to apply them in Nginx?
It sounds like you are assuming that everyone "serious" already is or should be using Nginx. Also one shouldn't assume that you'll always be using a reverse-proxy. Even when you are using a reverse-proxy, in my opinion it's good to keep that layer as "dumb" as possible, minimizing application-specific details. For example, setting certain security HTTP headers correctly often requires a deeper understanding of an application than one should expect from the reverse-proxy layer.
Slightly off topic, but it reminds me of why I think web application firewalls are misused: they try to plug security holes that should be treated as application bugs.
Sure, the first two — adding headers and rate limiting — can be done in nginx. I like secure.Config, though, because I don't have to remember header names and make sure I wrote them correctly, as Go compiler will throw error if I mistype something (BTW, that's the reason there's Referer method in http.Request - http://golang.org/pkg/net/http/#Request.Referer).
It's a nice list of items, but I don't feel like it's informed from actual penetration tests on Go apps. Bad Content-Type headers and DNS rebinding affect almost every Go web application out there.
Any naked Go server is usually vulnerable to DNS rebinding because it doesn't test the Host header.
