[ On Wednesday, August 9, 2000 at 01:37:01 (-0600), Tobias Weingartner wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot) 
>
> I'm a hardliner, and am going to say "down with inferior protocols".  May
> they die a quick, and painless (for most of the unix world at least) death
> they should have died 10 years ago.  To the rest of the people out there
> promoting and encouraging the continued use of such protocols, shame on
> you.

Yes, exactly.  But it's not exactly a "hardliner" position to take since
even more importantly it would be ethically wrong for any professional
not to fight against the likes of cvspserver.

It is necessary for a professional civil engineer to speak out against a
less professional colleague who would build an unsafe bridge (literally,
by the code of ethics through which they attain their professional
status!).  It is also necessary for all of us as software engineers to
speak out against those who would continue to promote unsafe networking
protocols like cvspserver.  Even worse is the example of an unethical
engineer who would provide a false sense of security by fixing the wrong
problem in an unsafe bridge, and claiming it makes the bridge safer --
safe enough for the public to use.  Ethical professionals must not allow
this kind of damaging behaviour to persist.

I.e. Justin:  Please do not continue to publicly promote your patch --
it is not an improvement in security and continued promotion will give
CVS users a false sense of security.  In fact I will continue to
strongly suggest that you not even use it for yourself!

All of what Tobias has so eloquently said is exactly right.  There is no
excuse for not using strong cryptographic security with CVS.  There is
no excuse for building orthogonal protection mechanisms into any
application, and most especially not one that offers public network
services!  There are 20-30 years of history and science behind the
development of safer ways to network and now with the likes of SSH we
can deploy these techniques with *far* less cost than any *single* risk
we would face by not deploying them.

(Mind you -- I cannot say the above without also stressing the risks of
something like SSH are not zero -- the server must still trust the
physical hardware and the operating system within the client since SSH
can easily be used covertly by a virus or worm!  This means that SSH
users on both ends of the connection must continually secure their
systems and provide reasonable assurances against such covert use!)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <[EMAIL PROTECTED]>      <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Reply via email to