> The security guide is written with the general public in mind. > While there's nothing inherently wrong with uWSGI, it is common > for people to look at synthetic performance benchmarks and make > their choice based on those. Unfortunately, uWSGI has an incredibly > large number of options, choices, features, and configurations for a > deployer to tweak, many> of which can > result in bad performance or > security problems. Furthermore, segfaults are pretty common in that > codebase (at least with some configuration options), which is not > encouraging from a security perspective.?
Sorry, but this is not the kind of "FUDish" answer i would expect from such an important project. Nginx too (given the amount of options) can be tuned badly and in very insecure ways, and i can ensure you since 2009 i have seen people configuring gunicorn (as well as uWSGI) in completely crazy and insecure ways. Segfaults ? You are telling that horizon (or gunicorn) never throwed an exception with a traceback handy for debug ? When uWSGI segfaults (and fortunately people report it to the bug tracker when this happen) it gives a c traceback. Nginx segfaults too, but i would never say it is insecure for such reason. (well even python segfaulted to me during the years, and without traceback ;) Stability ? Do you know the amount of huge sites (booking.com ?) that runs on uWSGI because of its robustness ? There are companies choosing it only because they can buy commercial support and there is a company behind it, what do you think such companies can understand when reading such a comment in your docs ? (Expecially when there are other sites saying exactly the opposite, and other openstack components using uWSGI by default) The only thing i can think of, is that that doc sentence was written years ago, when people (thanks to some stupid hello world benchmark) started choosing uWSGI for performance instead of its features (most of them "security" features). Fortunately things changed in the last years, there are still newbies making this kind of choice, but this is the kind of people that would not run openstack :) > The conservative choice is to recommend gunicorn which is stable, has fewer features, and is generally easier to configure and deploy correctly. If you prefer uWSGI and already > have experience running it, please feel free to use it with Horizon. And this is the kind of sentence you should put in the docs. (in addition to the fact that you should never choose a WSGI container based on silly benchmarks). I completely agree that gunicorn MUST BE the default as it is no-brainer to install and run, but this has nothing to do with security, expecially because security is something the "general public" rarely understand right, so why giving them a false sense of it ? (and throwing s*it to other projects) Finally, SCGI and FastCGI are only protocols, reporting to not use them for security purposes is completely wrong. Sadly, albeit i have followed the project for lot of time, i have never noted that page, otherwise i would came up before. Sorry for the noise :) -- Roberto De Ioris http://unbit.it _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
