(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

Reply via email to