Re: Subversion and security (was Re: introducing myself...)

[Brad Appleton <br...@bradapp.net>]

On Thu, Jun 19, 2003 at 06:16:16PM -0400, Bob Aiello wrote:
> The important goal is to spec what we all believe that subversion
> should do. So here is what I am proposing...
[...]
> I'd rather not spam this list in a debate on CVS or ClearCase security.
> I would like to know if there is interest in making subversion a world
> class CM tool that push the envelope on security as well as other features.

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'm all for discussing the encapsulation and interfaces needed in the short-term to be able to "plug in" the necessary security mechanisms later with minimal impact. I think that before Subversion tries to tackle security as you suggest it needs to tackle more of things that the existing CVS userbase would require before switching from CVS to SVN, and I think security is not near the top of that list. Most of the folks using CVS today don't have (or at least don't think they have :-) the extra security features you describe, and I see SVN needing to meet those other needs first before tackling security.

Again, I'm not saying to discuss possibilities. I do think that trying to pressure or influence security functionality to be implemented in the near term would not be best aligned with the vision and goals for SVN. Now, if some kind benefactor happens to be able to provide sufficient funding/resources to devote to security features, that situation could perhaps change :-)

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?

-- 
Brad Appleton <br...@bradapp.net> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion and security (was Re: introducing myself...)

[Brian Behlendorf <br...@collab.net>]

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