[ On Wednesday, August 9, 2000 at 02:05:58 (-0700), Paul Sander wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
>
> This analogy is somewhat flawed. Engineering is a balance of "doing it right"
> versus "doing it well enough" while considering other factors such as cost,
> and engineers of all disciplines are required make decisions in this regard
> every day. Civil engineers approve unsafe bridges every day: A rope bridge
> built in a playground is unsafe to drive on, for example, but it's "good
> enough" for the application it's given.
I don't think you felt the full thrust of my analogy. Let me try
another:
Fixing cvspserver is likey patching a broken window in a barn
that has no door, and long long long after all the animals have
taken off out that unclosable door!
> Protocols such as pserver have their uses, provided they're protected from
> outside invasions, e.g. in a secure network behind a firewall and not
> available to the general public, just as rope bridges are used in playgrounds
> and not on our highways. Rope bridges and pserver are not general solutions
> to a general problem; they're point solutions for specific applications.
The current implementation of cvspserver was always fatally broken. the
RSH method was available right from the beginning and could just as
easily have been implemented in every client, easier in fact than
writing the current broken code. There never was any excuse for the
rotten crud that's in there now. Not ever. I really wish I'd pushed
harder to have it thrown out long long long ago. The people who use it
now use it only because it is there and they don't know any better not
to use it or they're too lazy/bull-headed to change now that they do
know.
> I see the arguments: You can have a secure installation if you assign
> unique user IDs to everyone who accesses the repository (for read-only access
> as well as modify access), and use ssh or some other secure method for
> authentication. But there are shops that cannot or will not allocate unique
> user IDs for every user, usually because they want to allow anonymous access
> and simply cannot identify every possible user in a practical way.
Nobody in their right mind, i.e. nobody who has even an ounce of
understanding of computer security, would ever want to avoid using real
system IDs for commit access. For even anonymous read-only access you
still need a unique unprivileged "anonymous" user of some sort (ala
"ftp" for FTP servers).
(Well, actually anyone who thinks M$ makes a secure OS might have such
thoughts, but they'd be wrong.)
> One thing that I have not seen in this argument is a recommendation on HOW
> to deploy cvs with ssh to maximize security.
That's because it's been covered more than adequately in previous threads.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
