| gabriel rosenkoetter on Mon, 13 May 2002 01:03:38 -0400 |
|
On Mon, May 13, 2002 at 12:23:06AM -0400, Michael Leone wrote: > I'm trying to help someone setup CVS on his Debian system. It all seemed to > install correctly. I see the entry in /etc/inetd.conf. What do inetd's logs say? > mjl@slimtop:~$ cvs -d :pserver:mjl@localhost:/usr/local/cvs init > cvs init: warning: skipping invalid entry in password file at line 1 > /usr/local/cvs: no such repository Hrm. Do you have a pre-existing .cvspass? Why are you using pserver on the localhost? Or, really, at all? You know that pserver is *strongly* discouraged, in favor of using the CVS_ROOT=<host>:<path> and setting CVS_RSH=`which ssh`, right? pserver's clear text, password included. And there's no reason to use pserver unless the repository's actually on a remote system. Even if you set up an anoncvs user, the source is transfered in the clear over the network, which you really ought to be concerned about. (A mitm could very easily insert malicious code without your being any the wiser.) Not that figuring out what's wrong isn't worth your time, just that you probably don't actually want to be using pserver at all. > However, when I try to login: > > cvs -d :pserver:mjl@localhost:/usr/local/cvs login > Logging in to :pserver:mjl@localhost:2401/usr/local/cvs > CVS password: > /usr/local/cvs: no such repository Hrm. As whom is pserver running? (That is, is your inetd or pserver itself doing a setuid(), or, perhaps more importantly, a chroot()?) > It looks like it's accepting the password (since there's no password error), > but it also thinks there's no repository. Could be a spurious error. What version of CVS is this? (Various versions before 1.11 had some serious bugs with a variety of things, pserver included.) > I've been told that this system isn't using MD5 passwords; would that make a > difference? Shouldn't. pserver, if memory serves, uses getpass(3), crypt(3), getpwent(3) to deal with password operations, which means that it'll deal with whatever your local system knows how to deal with. Rolling your own password verification routines is generally a bad idea (the existing libcrypt is almost definitely more bullet proof that what you could come up with without a LOT of work; though auditing those existing routines might be worth while) and distinctly non-portable, since crypt(3) has functioned pretty much the same everywhere since about Version 7 AT&T Unix. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpKr0WyRlPQX.pgp
|
|