RE: [Cvs-dev] LAYER X: A Novel Distributed Working System for anyVersion Control System

[Arthur Barrett]

Ronak,

> I was researching on the authentication system of 
> VCS. So i came up with an idea of developing a 
> client independent system. 

Great to hear you are spending time thinking of ways to improve SCM systems 
like CVS.

To me your description of the functional goals are rather vague (and duplicate 
existing features) and secondly you talk about an algorithm but have not made 
it clear which open source license you intend to publish it under.

My own involvement is mostly with CVSNT (which has a separate newsgroup).  The 
CVS and CVSNT projects often 'steal' code from each other that they find 
pertinent to each project.  In particular I think the majority of the 
functional advantage of your proposal has already been implmenented in CVSNT.

I personally look at improvements to CVS in terms of the 'business benefit' - 
ie: what business problem does this improvement solve?  Ie: the audit 
integration solved compliance issues for SOX, the changeset/bug number features 
(edit, commit, merge) allowed a business unit of work (job/bug/issue) to be 
tracked (audited) and allowed companies with CVS based SCM to inform customers 
easily of the relationship between a release and specific business units of 
work.  Your proposal (whilst seeming quite 'nifty') does not give me any idea 
as to the business benefit.

> Layer X : 
> 
> 
> In a Version Control System each time a user 
> logs in, the contents of a module (in accordance 
> with the access rights of the user) are copied 
> into the client. After first authentication 
> the user need not provide any login information
> (unless his session or password expires) for 
> rest of the activities(like commit, update, diff 
> etc) from the same client. 

You have just described what 'cvsagent' (part of the cvsnt project) achieves 
already and has done for many many years.  

I believe there is also a generic putty agent that works the same way for ssh 
connections.  

The CVSNT and Putty agents are implemented client side and I think at this 
point in time that both are specific windows implementations (remember that 
CVSNT itself runs on linux/unix/mac etc).  I don't know of any particular 
reason why cvsagent was implemented as windows specific - except that perhaps 
we assumed that non-windows users could set up ssh key based authentication 
easily enough, or maybe we just couldn't be bothered with linux at the time...

> Imagine a situation when the user check-outs 
> the module from a café and want to commit from 
> your home PC. In this case the user will have 
> to give the login information again so as to 
> authenticate from the new client. 
> 
> We propose to build a novel layer (called 
> 'LAYER X') which when deployed at the 
> version control server enables a client-independent 
> authentication system. 

Implementing it purely server side I think would open up many many security 
holes.  It's not that difficult to spoof a client address and hijack a 
connection.  Signing the connection or having some token exchanged would 
require changes to the server as well as the client which is not what your 
current proposal is - and in that case - why bother with the server side at 
all?  The authentication token can be safely cached on the client in memory for 
a 'session' (which is what cvsagent does) or can be stored in a file on the 
client for 'permanent' use (which is what 'cvs login' does).

A 'half way' approach is the (already existing for years in CVSNT) 'sspi' 
protocol which re-authenticates each connection, but does so with a token that 
the server and client both have (from active directory/winbind).

> Hence we achieve a 
> distributed working system for VCS. 

Unless I'm seriously confused - the definitions of a distributed versioning 
system have got nothing to do with what you are talking about here.  Besides - 
CVS/CVSNT are already distributed versioning systems by any reasonable 
definition and were that way from the day they were concieved more than 20 
years ago.  The only thing that CVS/CVSNT do not do is store multiple revisions 
on the client for which any reasonable sized project would be an enormous waste 
of resources. However if you really want to store the entire repo on several 
'clients' (or proxy servers) then CVSNT 2.5.04 has had this ability (the 'sync' 
protocol) for over a year, I wouldn't be at all surprised if CVS 1.12 has 
something similar.

> We have 
> designed the protocol in accordance to the 
> CVS server (Concurrent Version System), 
> which is one of the most widely used 
> server for version control. 

Source code?  Open source projects are about contributing 'source'...

> Our protocol 
> has been designed such that,  both the 
> pserver and the challenge based 
> authentication system become client independent 
> for a particular session period. We also 
> present a detailed analysis of the security 
> and performance of Layer X.
> 
> ----------
> I would love to receive feedback from you guys 
> about this idea. If anyone wants i can 
> also send the detailed report of the algorithm.

I think you are re-inventing the wheel.  

Get involved with the project(s) on a daily basis and talk about ideas in 
smaller 'bite sized chunks' and you'll get the hang of it.  

If you have questions/discussion items about CVSNT specifically please join the 
CVSNT forum(s).

Regards,


Arthur Barrett