On Sun, 22 Jun 2003, Brad Appleton wrote:
> Hi Bob! I'm also very experienced with ClearCase. I wonder if we can
> look at the list of requests/bugs still to implement against subversion
> and the relative priority of them, and where security falls into the
> mix. My impression is that as important as security is, there are still
> many other more fundamental features subversion needs before version 1.0
> to make it "a compelling replacement for CVS" and I don't see security
> among them.
I think the others might be exhausted on this issue (or otherwise focused
on fixing defects rather than discussing new requirements), but I'd like
to re-emphasize the point made earlier that we are bandying about the term
"security" loosely here, and in the context of an SCM solution it means
many different things.
To be clear, where "security" means:
a) preventing escalations of privilege - where someone gets the right to
do what they "shouldn't", as configured
b) minimizing the opportunity for Denial of Service attacks
c) encrypting the connection between client and server using SSL as
designed (with bonus points for client-side certs)
then I think the SVN developers all have those as priorities (at least the
CN guys do).
It sounds like Bob's primary "security" examples have been around whether
a developer can do damage or change history in such a way as to change the
repository's history irreparably. This has much more to do with how
developers can touch the database than whether the database itself is
using CVS-style flat files, SVN-style DB files, or something else.
It's true that there is one way to set up the repository, ra_local, where
every developer has a Unix account and can write to the repository
(through the SVN client or otherwise) directly. Under Unix, write privs
also mean the ability to muck at low levels, or even destroy.
But through ra_svn or ra_dav, this is just not possible, if I understand
things correctly. It's even possible to guard against this with CVS, if
you configure your CVS server to not require separate Unix logins per
developer, and only allow them to connect through the CVS server.
Some of the "security" discussion also seems to be about audit-ability -
keeping a logfile to the side of all transactions then being able to
compare that logfile to the database and check that nothing was lost.
That doesn't seem to require modifications to SVN, it sounds like a matter
of copying the Berkeley DB logfiles off to another location and running
a recovery script from time to time to make sure nothing is lost.
> BTW - have you looked at what Collabnet SourceCast does for
> CVS+Bugzilla? There is also an implementation of it that works with
> ClearCase and ClearQuest. And I hear another is in the works that uses
> Subversion and Scarab. Is not SourceCast designed to address some of the
> secure viewing/accessing issues you raised?
If the issues are related to needing a better tool to manage the concept
of users, projects, and permissions across the range of tools we provide
(today, CVS and Bugzilla, soon, SVN and Scarab, with documented means of
co-existing with Clearcase and other tools) then that's what we're here
for. We've met the above network-related security requirements with CVS,
as well as preventing the types of corruption possible with Unix-local
access to CVS (which we don't allow).
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 21:34:13 2003