Hi all:
I'm happy to see that Subversion is closing in completing some features
that will make it usable in places beyond the original target audience
(CVS users). Merge tracking and the SVN 1.6 features to improve security
are important to me and make the difference between Subversion being not
usable, and usable in some environments.
An area that Subversion is currently "poor" in my opinion is its
handling of passwords. There are two components to this - the first is
security and the second is performance.
Starting with security:
The FAQ and documentation recognizes that some users cannot or do not
wish to store passwords to disk. Subversion has three models: 1) Store
passwords, or 2) Do not store passwords, 3) Subversion 1.6 on UNIX, and
Subversion today for Windows and MacOS X improve on this by providing a
third option - store passwords in an encrypted key ring.
For many groups this third option will be the preference and provides a
good compromise between 1) and 2). If my understanding is correct, the
third option will even deal with the user's password having changed in
that it will automatically re-prompt providing additional value over the
first option (I have not yet confirmed this).
Due to the number of systems in use in some companies or environments,
they have adopted "single sign-on" technology, and have chosen to
enforce strong security requirements on this single password rather than
tracking many passwords. For SVN this can be of great important as the
company's intellectual property are being protected by these passwords.
Worse, the Canada and US export control regulations can be very strict,
and software components written for some customers (such as the US
government) can have much financial/contractual penalties if holes exist
in the system. Storing passwords in a key ring may be insufficient in
these cases as the password is still stored to disk, and the decryption
key that the user users for their keyring may not be as strongly
guaranteed as the key it is protecting.
My first speculation here is that Subversion 1.6 provide an option to
use the "in memory" key ring, rather than the "persist to disk" default
key ring in GNOME key ring. Looking at Subversion 1.6 it looks like it
would be a simple change for GNOME keyring, provided that agreement on
how to configure this option can be obtained. This gives a good
compromise between 1) and 2) in that the password will be kept encrypted
in memory for the user's session, but not stored to disk. At its
simplest, the user would be given the ability to choose which keyring to
use, and they could identify the "in memory" key ring. This change on
its own greatly increases my confidence in ability to defend the use of
Subversion within a company I work for from a security stand point. The
current users are primarily Linux, Solaris, and Windows users. The
Windows security model for Subversion satisfies me from a security
perspective. If a patch to support "in memory" key rings for GNOME
keyring were to be proposed for Subversion 1.6 and it was small, would
anybody here have objections to the patch on principle?
Next we get to the repeated sending of the password using webdav with
every single request which encourages the password (even in base 64
encoded form) to be scribbled all over memory. I'm going to put the body
of this under performance although it also has a security component.
Performance:
Every webdav request is authorized and authenticated on its own.
Recently looking at GForge I've seen substantial amounts of complex
caching being used to try to recover performance in terms of ability to
ensure that: 1) the user is who they say they are, and 2) do they have
the required access to the repository? We've recently implemented "last
request" caching due to the number of webdav requests that Subversion
generates that are all approximately the same. That is, we look at
whether the request is a "read" or "write" request, which repository was
accessed, which user did the accessing, what their password was, and
whether we last authorized them or not. Without this cache it was
performing thousands of SQL queries for basic SVN operations. This sort
of problem is often solved from the webpage using "cookies". Instead of
sending the user + password with each request, a cookie is sent back to
the client, and the client will send the cookie with future requests.
The cookie is a standard fixed life time data structure that allows
server side state to be maintained providing the appearance of a
"session" to the user. If they logged in 10 minutes ago from the same
environment, why should they need to login again?
The concept here crosses with security in that a fixed life time key can
be stored to disk rather than a user/password. The need to store a
user/password disappears, and the key becomes a "fixed time password for
a particular use".
I read threads on dev_at_subversion.tigris.org in the past (2005?) where
this was raised and the sense was that neon supported cookies but that
some opponents to the idea felt that any system that relied on cookies
was broken by design. To some degree, I am seeing this as a conclusion
without merit. That is, the proposal isn't to rely on cookies, but to
allow cookies to replace the requirement for persistent passwords and to
allow complex calculations regarding access to be cached against the
session (for example, what country is the user in? what level of
technology does the US government believe the user should be allowed to
see?). If the client is a client that can provide the appearance of a
user session (as I believe the svn CLI can, or Subclipse can), it can
make its capability known to the server using a client header and the
server can generate a cookie to send the session key back to the user.
Users would need to re-authenticate once every 12 hours per repository
per user. During that 12 hour period they could operate without a
password on each operation, but still not have opened themselves to
exposing their password (where the password might grant access to other
resources such as an employee's personal records).
Support for cookies is a larger change (at least in concept) that I
don't expect to make it into Subversion 1.6 at this point. I do want to
re-open the discussion on this issue as I feel that the previous
discussions closed prematurely without merit. My challenge to the group
is whether each webdav request truly benefits from being
authenticated/authorized on its own (some might call this "RESTful") vs
whether there is benefit to providing the appearance of a session (cookies).
Please consider the number of WebDAV requests that are generated as a
result of even basic operations, and how the SVN command itself is
itself a "basic operation" that may be run dozens or hundreds of times a
day by busy users.
On a separate note - analysis of 'svn log' seems to show that Subversion
generates some requests multiple times when it should already have the
data it needs from a previous request? Does SVN not perform any caching
of results even within the same 'svn' command? In one case we have a log
of where it generates the exact same three WebDAV commands twice in a
row - 3 WebDAV requests turns to 6 with no intermediate writes? Is this
necessary? Are you aware of this or do you need a log to see it for
yourself?
Thoughts?
Thank you for your kind consideration.
Cheers,
mark
--
Mark Mielke <mark_at_mielke.cc>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-02 19:20:16 CET