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.
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.
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. As far as
I can tell (from this discussion, not having read the docs recently) pserver
supports this mode of operation while ssh does not. People who require this
specific capability don't appear to have a viable alternative that is "done
right" and are therefore forced to use a poor solution that happens to be
"done well enough" to meet their needs today and will be happy to replace
their rope bridge with the wooden model when it becomes available or
practical.
One thing that I have not seen in this argument is a recommendation on HOW
to deploy cvs with ssh to maximize security. As with many Unix security
issues, there appears to be some expectation, if someone simply mentions that
an issue exists and the way around it is to use or avoid some feature, that
the reader can figure out exactly what the issue is, what its underlying
cause is, why the use or avoidance of that feature works, and how to deploy
a solution. Examples: Don't use chmod for locking; don't give ordinary
users write access to any files (even logs) that are open for writing by
root; don't use pserver.
If the participants of this forum really wish to help their peers solve
problems like these, they should consider publishing a very detailed
description of the problem, the correct solution, the correct configuration
(in a general way), and specific examples. That document should be added to
the current FAQ list and eventually be included in the manual. If such
completeness already exists in those places, then a pointer to the applicable
section(s) would be in order.
'Course, I have it easy because I can live with a rope bridge so this
discussion doesn't really interest me. But since this discussion breeds
more heat than light, I suggest that such discourse might become a bit more
constructive and useful.
--- Forwarded mail from [EMAIL PROTECTED]
[ 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)
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.
--- End of forwarded message from [EMAIL PROTECTED]
