(Noting that its kind of late where I am). Sean, I totally agree that we should fix uname. Let's get on that.
Michael On Mon, Jun 22, 2015 at 8:52 PM, Sean Dague <s...@dague.net> wrote: > On 06/22/2015 05:28 AM, John Garbutt wrote: >> On 22 June 2015 at 00:14, Michael Still <mi...@stillhq.com> wrote: >>> As an aside, do we think that exposing the exact version of a server >>> process is safe from a security perspective? >> >> During discussions in the Nova API meeting, it was noted that while we >> do expose the exact API version, we are not exposing the git hash of >> the deployed cloud. >> >> Its certainly something we need to consider when we talk about bumping >> the micro-version for a security fix, but I suspect the need to >> backport is likely to force us to not bump the API version for such >> changes. >> >> Its certainly a concern that should be noted, in the hope we can get >> some extra eyes on that detail. > > First, I don't think this is an issue. Like John said, we aren't > exposing git hash. > > Secondly... the API is a programing interface. Hiding the version number > on a programing interface is... kind of crazy. It would be like making > uname -a return ("Probably Linux") instead of anything specific. Or > "probably libc, your guess is as good as mine". I get where people get > freaked out about sharing, but, you can't have an API without sharing > information about what it is and how to use it. The logical follow on > from hiding the API version is we should delete all the API > documentation as well, because someone might use it to do a bad thing. > > Thirdly, we're building an endpoint that we expect to be on the > internet. If we think the only security for it is by hiding information > about it, I think we've got to go back to the drawing board about a lot > of things. Yes, it's hard to get that right. But that's kind of the > whole point of the project. :) > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev