Hello John!
>From: John Peacock <jpeacock@rowman.com>
>To: Tom Martin <tommartin687@hotmail.com>
>CC: dev@subversion.tigris.org
>Subject: Re: Feature request: Disable ssl prompting in "servers" for better
>security
>Date: Mon, 20 Dec 2004 20:43:02 -0500
>
>Tom Martin wrote:
>>A new boolean config entry "ssl-no-promt" for the "servers" config file.
>>If the ssl host cannot be authenticated using "ssl-authority-files",
>>the svn client fails without promting.
>
>It seems like a waste to spend time adding a new config entry to deal with
>a situation brought on by poor network management practices. Repositories
>on a network must be in a 'fixed' location, so that clients can contact
>them. If you choose to give the repository a floating IP (a bad idea in
>the first place), then the clients must be able to resolve the server
>address by name (via some resolution method). Said method should
>(according to good design) contain a cache that is shorter than any time
>limit on an assigned IP address.
>
>I think that this was a classic case of shooting yourself in the foot; the
>tool (in this case Subversion) should not be in the business of setting
>rules for your network that would prevent this from happening. There is no
>security failure here other than the unwise decision to have a movable
>repository containing sensitive information and the developer's inability
>to read an error message and act on it appropriately. IMNSHO.
You are right that a dynamic IP is not perfect (but unavoidable in this
case);
but it is only making the problem more worse, but it is not the cause of the
problem itself. For the following you may assume that the IP is static.
Authentication itself is a very serious security issue.
No serious security manager would rely on proper timeouts and on proper
IP routing. There are several possibilities for manipulating this.
This is exactly the reason why ssl authentication exists.
I am sure you don't want to say that this feature has no reason.
Agreed, everything would be fine if all people would correctly
response to warning messages. But in practise they are humans.
I try to teach them all the time about several security aspects.
And basically it works mostly; but again and again there are situations
where they do the wrong thing.
It is all my experience that human make errors, and that technology
helping to reduce human errors are a good thing.
Being responsible for security, I want to reduce dependency on correct
user behaviour as far as possible. It will be never perfect, but as more as
better.
BTW, you may argue that other applications work in the same way
as subversion. However, it seems that there is a difference of subversion
to many other applications: With subversion you typically have much more
sessions than with other applications. For example, when using ssh you
typically
login, and then have a longer session. When using svn, every single svn
command is a new session. This makes it much more likely to simply
click warning messages away.
Thanks!
Tom
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 21 03:15:20 2004