[EMAIL PROTECTED] on 2000.07.25 00:29:08
>> And hence my point that developers must be trusted. In fact, this is a basic
>> philosophy of CVS.
>
>I trust myself and yet I don't sleep well if I'm not making nightly tape
backups.
Backups protect you from disasters other than hacking developers.
>Also, if one of my developer's passwords is compromised, we'll say without his
>knowledge for point of example, the damage might be more limited if the
attacker
>can only access one developer's account. I am also a step closer to figuring
out
>how security was compromised if I can trace the access to a particular user's
>account.
Like I said many times before, if you're worried about this, you wouldn't use
many-to-one mappings. What I haven't said is that many-to-one mappings should
really be used only for read-only users (but it shouldn't be limited to that
use).
>Why are you riding the connection on SSH in the first place if you are so
>trusting? Why not just use pserver and the functionality already present in
the
>current version?
I trust the ones I give access, but not the ones I don't.
>I also notice you neglected to respond to the point about user names no longer
>being guaranteed to be unique. Do you think this an inconsequential issue?
I just responded to it. Have some patience ;) What I said in that post (with
some modifications to generalise) are:
1. Pluggable authentication.
2. Allow many-to-one mapping of CVS client users to CVS server user. CVS should
log a separate identity for each client user while running as the one CVS server
user. (Of course, this scenario can be generalised to more than one CVS server
user).
3. The CVS server should not run setuid or setgid.
4. Minimal sysadmin involvement. The sysadmin should only be involved when a
new system user needs to be created.
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
