Open Stack

Roberto,

It sounds like you disagree.  Let's keep this constructive.  Could you file
a bug and/or a change request for how you would like to see this part of
the book improved?  Then we can focus on that specific change that you have
in mind, rather than expressing discontent at the motivation for the
current content.

Bugs can be filed here (please tag with "sec-guide"):
https://bugs.launchpad.net/openstack-manuals/+filebug

Git repository is here:
https://github.com/openstack/security-doc

Change process is described here:
https://wiki.openstack.org/wiki/Gerrit_Workflow

Cheers,
-bryan




On Wed, Aug 27, 2014 at 10:34 PM, Roberto De Ioris <roberto at unbit.it> wrote:

> > 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 at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140828/2ed887c5/attachment.html>