Development of CVS: Networking

This page is for CVS development issues related to making a connection over a network, including some issues which are not exactly networking as such, but are specific to client/server CVS.

First, the rant about how network security should be separated from CVS.

SOCKS

SOCKS is a protocol to allow controlled traversal of firewalls. Apparently with a recent SOCKS implementation it is possible to use SOCKS without modifying CVS. The "runsocks cvs ..." command should enable the use of SOCKS at run-time. For Windows clients, the equivalent to runsocks is SocksCap; see the SOCKS web page for further information.

People have also patched CVS for SOCKS, but as far as I know this isn't needed for recent versions of CVS and SOCKS.

SSL

I'm not aware of anyone working on supporting SSL for CVS, nor do I have more than a general notion of what the issues might be.

Also take a look at gssapi_ssleay, although I haven't seen reports from anyone who has tried to use it with CVS.

Also here is a patch concerning tunneling CVS through HTTP, which has the potential to be a relatively clean way to support SSL-style authentication and encryption.

Encryption

If one tries to use the -x option with pserver, or some other method which does not support encryption, it should be an error (just like it already is if one is using Kerberos without encryption). I don't think it is now.

Pserver server run as non-root

Running the server as non-privileged (non-root) user works, but it isn't documented. Here is a documentation patch with a first cut at documenting it. Disclaimer: although in general there are fewer potential security problems than running the server as root, this documentation does not document the security issues in any detail.

Another related issue is running pserver when you don't have access to inetd.conf. Here is an inetd substitute.

Password authentication

The CVS pserver server gets a username and password over the network and, if the SystemAuth configuration option is set to yes, asks the operating system to verify the username and password. Unix systems have traditionally offered a getpwnam() function which allows CVS to do this, but as the system-supplied authentication options have multiplied so have the ways in which an application is supposed to access them. The clean solution to this is PAM (pluggable authentication modules), but CVS doesn't yet support PAM. The arguably more practical solution is to try to deal with the many APIs out there for checking passwords; here are patches for Digital Unix 4.0 and SCO.

Better server logging

The CVS server either ignores errors or reports errors to the client. In cases where there is a problem communicating with the client, this doesn't work so well. Here is a patch which takes a small step toward better logging of errors on the server side.

--allow-root versus 4 arguments to inetd

If your version of the inetd networking daemon, which is used to start the CVS pserver server, only allows 4 arguments, and you want to specify more than 4 repositories with --allow-root, you have a problem. There is a fairly simple fix/workaround. There is also a nonrecommended patch.

A semi-related issue is that some sites would like a security model similar to rsh but based on sending a password. Kerberos or other cryptography-based systems are overkill for some people. So the CVS server could have a mode in which it accepts verification of the username and password only from the operating system (rather than CVSROOT/passwd). In this mode, --allow-root would not be required. The mode would be enabled by an option to CVS such as --system-auth-only, or an entry in the mythical global config file.

Multiple users sharing an rsh account

If multiple users share an account on the CVS server and access it with rsh, then there is normally no way to distinguish which user made a particular checkin. One clever solution, which requires no CVS modification, is to have each user set CVS_SERVER to a script which sets LOGNAME and USER to something unique, and then invokes the CVS server. Might want to document this somewhere (and add to sanity.sh).

Change pserver port

If you want to run pserver on a port other than the port specified for "cvspserver" by your system (typically port 2401, in /etc/services), you will need to patch your clients. For example, you might want to run a released version of CVS on port 2401 and an experimental version on another port. Here is a patch using an environment variable (which arguably is a bad place to specify the port), or another putting the port into the CVSROOT. Here is one which puts it into the CVSROOT with host/port syntax.

This is a commonly requested and reinvented feature, but everyone seems to have a different idea about what syntax to use. I guess my current sympathies are with URL syntax (see the discussion at "into the CVSROOT" above). Maybe.

Kerberos and GSS-API

Here is a patch to let you build a non-Kerberized CVS on a system which has Kerberos installed.

Solaris 7 is said to have GSS-API but not Kerberos. The above patch should help but also probably isn't the whole story.

Lots of useful-looking kerberos patches from Michael Shiplett; I won't try to summarize them all but they let the kerberos code do many of the things which pserver already does and various other useful things.

Here is a discussion of using kerberized CVS clients on Windows.

CVS server issues

Here is a report of a case in which the SERVER_FLOWCONTROL code can cause a spurious SIGPIPE ("Broken pipe").

Obsolete Patches

The patches in this section are no longer considered relevant (usually because the problem has been solved some other way or the patch has been made official). They are subject to disappear at any time; if you know of some reason why they might want to stick around, let us know.

• Ian checked in a similar patch to this GSS-API patch on 1 Jun 1998.