RE: CVS & SSL

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Thursday, May 24, 2001 1:21 PM
> To: CVS-II Discussion Mailing List
> Subject: Re: CVS & SSL
> 
> 
> 
> It is because of this issue that CVS MUST NOT implement *ANY* security
> model!  CVS already provides all the necessary hooks so that *any*
> external security model may be implemented.  There's really 
> no need for
> pserver (and there never ever was).
> 
> If CVS simply offered only the :ext: method and forced admins to use
> either rsh, ssh, or some similarly capable remote execution facility
> then it would be much harder for anyone to blame CVS for inherent
> security flaws, and it would be much harder in fact for 
> admins to choose
> an insecure access method (most would no doubt just choose SSH because
> it's available and works right "out of the box").
> 
If CVS simply offered only the :ext: method, and a central server was used
by people logging in from Macintoshes, Windows boxes, and Unix boxes,
how would it keep the line-ending conventions straight?  With pserver, the
reads on the local files are performed by the local client at least.

If CVS simply offered only the :ext: method, wouldn't we have to use
Samba and various potentially incompatible NFS implementations to keep
our heterogenous network running?

Unless you can provide me with a way to use :ext: that handles different
line-ending conventions properly, is not prone to corrupting the repository
through NFS problems, and which doesn't require people in the Atlanta office
to keep entering passwords in order to use CVS, I'm going to have to stick
to :pserver: here.

I'm open to suggestions, but if I'm going to accept them I need some
assurance that I'm moving forward, not backward.

> That would be OK, but apparently NOT with the current 
> implementation --
> only without setuid!  (and only for read-only access to a 
> safe mirror if
> you care at all about the content of your real repository)
> 
There are real costs in not trusting your developers.  There are people
whose job it is to maintain security on getting into developer accounts,
and whose job it is to make sure nothing comes in on 2401 except through
a validated channel.