I agree completely Karl. (I am also withholding the deep urge
to make a joke about a CVS "security" list :-)
The important goal is to spec what we all believe that subversion
should do. So here is what I am proposing...
1) History should NOT be be kept in a (single) physical
file - it should be stored as transaction records that could not
easily be located or hacked. In database CM tools the records
are scattered throughout the repository.
2) There should be a hierarchy of events (e.g. security events, "minor"
events etc.)
3) Source files (and all of their associated revisions) should also
not be single specific files. They should be persisted as
transaction
records that are scattered throughout the database.
4) There should be referential integrity across the repository. If
someone
manages to erase 2 or 3 containers then my trusty admin utilities
should flag the loss of referential integrity.
5) Many modern CM tools allow you to use common database systems.
That means that you can use their own internal tools to accomplish
many of these objectives.
I joined this group because I have a lot of experience promoting and
supporting large scale CM tools in many large financial services firms.
Recently, I critized (on CM Crossroads) CVS based CM tools as
lacking proper security and being inappropriate for use in large scale
(global) financial services firms.
The vendor (you'll never guess who it was!) suggested that I get involved
with this effort to try to influence the development of subversion from a
security perspective. I do know C++, but I suspect that my skills as
a C++ developer are not as strong as most of you (although that doesn't
mean that I won't try!). I do have a lot of experience as a Unix Admin
(on AIX/HP-UX/Linux and a little Sun). I may turn out to be more helpful
as a tester and SQA resource. I have installed and provided hands-on support
for many largescale CM tools on many environments. I have also trained a lot
of
developers. (I know what they are going to ask and what confuses new users!)
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.
Also if there is a better forum to propose suggested requirements - then
please let me know!
Bob
----- Original Message -----
From: <kfogel@collab.net>
To: "Martin v. Löwis" <martin@v.loewis.de>
Cc: "Bob Aiello" <raiello@acm.org>; <dev@subversion.tigris.org>
Sent: Friday, June 20, 2003 1:46 PM
Subject: Re: introducing myself...
First, welcome Bob!
Second, just a gentle reminder (not targeted at Bob, by the way) that
this is the Subversion dev list, not the CVS security list, so please
let's try keep discussions related to Subversion. I realize it's
always a judgement call, so 'nuff said.
Thanks,
-Karl
martin@v.loewis.de (Martin v. Löwis) writes:
> Bob Aiello <clearcaseguru@optonline.net> writes:
> > oh by the way I wrote about these issues in this months edition
> > of CM Crossroads (www.cmcrossroads.com).
>
> Very interesting. However, I feel that the terminology in this article
> is confusing: protection from failures and protection against attacks
> are completely indepedent issues, and I think only one of them should
> be called "security" (i.e. the protection against attacks). The other
> is better called "safety" (as in "safety belt" - not "security belt").
>
> While I can agree that CVS lacks safety (e.g. no fault tolerance, real
> risks of corrupted databases), I fail to see why you consider it
> insecure. E.g. when used over ssh, CVS provides strong
> authentication. As a revision control system, it supports auditing by
> nature. There are some operations that are not audited, but it would
> be easy enough to disable them altogether without loss of usability.
>
> About the only thing it does not provide is non-repudation.
>
> Regards,
> Martin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 21 00:16:28 2003