Open Stack

> 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