Hello, Steve!
> > Using cvsweb, or a commitinfo script (with e-mail, etc), this can be made
> > almost to order. I agree that immediate feedback would be nice too. I'd
> > say that if and only if the user/password stuff are "fine", then you could
> > complain about a bad CVSROOT...
> >
> [smc] Except the first place CVS looks when checking
> the password is _in_ the repository, (see check_password()
> in server.c) so if CVSROOT is bad, you can't check the
> password quite properly. Perhaps you can in the event
> your server is configured to use the native OS user account
> passwords, (e.g. those in /etc/shadow).
Then Mr. Joe Hacker will use CVS to guess passwords.
The `login' program makes a delay after unsuccessful authorization.
Why wait that slow login if CVS returns the result immediately?
When CVS complains about CVSROOT the password has been found.
Congratulations, Mr. Hacker!
I believe that revealing all CVSROOT's will not do such harm as using
CVS for shadow password authorization by default.
Relying on CVSROOT being "unguessable" is wrong. They are not supposed to
be checked against dictionaries for "strangeness"
CVSROOT is not a secret. The shadow password is a secret. Storing it in
~/.cvspass is dangerous. Using it for CVS is dangerous.
Pavel Roskin
