Re: CVS & SSL

[Greg A. Woods]

[ On Thursday, May 31, 2001 at 08:34:21 (-0400), Derek R. Price wrote: ]
> Subject: Re: CVS & SSL
>
> Well, there _is_ a basis of at least suggesting models in the docs.  I know
> that when I was a novice user I much preferred, "well, this'll get you up
> and running if you need it", with appropriate warnings to directions like,
> "go learn Kerberos" and talk to us later.

Yes of course.  However the CVS implementation itself must not include
any specific security model in favour of any other.  Even the the CVS
pserver could trivialy be implemented externally to the main CVS client
and server (as it very well should be if anyone ever wants to use it
as-is!).

> Keep in mind that I view pserver as more of a logging aid that can double as
> a simple, if possibly dangerous, security implementation if necessary.  I've
> never been one for making it impossible for a user to shoot themselves in
> the foot as long as the appropriate warnings were present.  I'm just not so
> egotistical as to think that I'm going to understand every one of their
> problems and I think the flexibility left in many *NIX programs has enabled
> their use for many probably unforeseen purposes.

That doesn't make any sense at all.  Use of an external remote job
execution tool give CVS the most flexibility possible!

> As for excluding communications support, well, it's there, at least, for
> user-side simplicity's sake.  Not everybody has a copy of tcpserver lying
> around yet.  Especially not on Windoze, I'm guessing.  And opening a simple
> TCP socket is fairly simple nowadays, even from inside a program.

It doesn't matter what someone does or does not 'have lying around'!  If
they want to implement something like CVS then they will get the
necessary tools and support programs.  Period.  End of discussion!

If you want to go around hammering screws in instead of finding the
proper tool then that's your business, but there's no reason why screw
makers should cater to your lazy/stubborn ways by stripping the threads
off their screws for you.

> Well, yeah.  I think this discussion started about the generic socket
> provider hook I provided, initially with the idea that it would be useful
> with an SSL provider.  This leaves CVS room to use authenticating and
> non-authenticating channel providers now - a non-authenticating provider
> (one which doesn't have/provide a useful user ID on the server) will use the
> old authentication server, at the least for logging purposes.  If the
> administrator desires something more secure, she can work that out for
> herself - the hooks are there.

So build your little "provider" as an external program that CVS can call
and there'll be no problem!  (well, at least not within CVS! :-)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>