Networking and Security

This page is for CVS development issues related to making a connection over a network including some issues which are specific to client/server CVS.

SOCKS

SOCKS is a protocol to allow controlled traversal of firewalls. 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 this is not needed for recent versions of CVS and SOCKS.

Dante

Dante is an open source implementation of the SOCKS protocols. The Dante FAQ has a note about how using Dante with :ext: in CVS can be a problem because rsh and ssh, being setuid, can't use Dante the same way that :pserver: does (via LD_LIBRARY_PATH or similar mechanisms, in a nutshell).

SSL

There is a patch concerning tunneling CVS through HTTP. This 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).

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 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.

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.

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.

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.

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.

People often ask how to implement the network security scheme du jour for CVS. The first answer often seems to be to hack CVS. The right answer is probably to hack CVS as little as possible (keep reading for a more detailed rationale). Here are a few ways:

• Port forwarding, popularized by SSH. See the SSH page for details (hopefully other network security products will start offering this very useful feature).
• RSH replacement, as described on our security page.
• Implement the socket API. This approach has been popularized by SOCKS. The new socket implementation can be plugged in via the shared library features present in all modern variants of unix. Now, the security library has to figure out how to deal with the caller not passing information such as a username on the remote system, but the usual approach is to read config files in the user's home directory and/or system-wide, which can specify any such information. This is better anyway, in the sense that one doesn't need to learn a whole new mechanism which is specific to CVS.
• Implement a "generic" API such as GSSAPI. The biggest issue is whether GSSAPI is truly generic in practice as well as intent. Well, also whether it buys us anything which the sockets API does not, I guess.

Why?

Here is more discussion of why to separate them:

• CVS application developers shouldn't become network security developers. Trying to reinvent Kerberos, SSL, &c, within CVS would be a massive duplication of effort and a recipe for not doing it well.
• One wants to secure services other than CVS.
• The more separate the network code is, the easier it is to audit it for security holes, and (perhaps more importantly) understand just what the security implications are of a particular setup.

Legal

The reasons for separating network security from CVS are primarily technical. But since the legal issues often come up, we'll briefly discuss them, with an emphasis on the United States. Disclaimer: nothing on this page is intended as legal advice and if it is important to you, you should do your own research and/or get your own lawyer. In particular, if you need US export licenses for your non-CVS products, you probably need to be especially careful about staying on the good side of the export control authorities.

As far as we know, exporting the source code to implement the client half of an interface such as GSSAPI does not present any problems with respect to US export control. People often talk about how including hooks may subject one to export control, but as far as we know that doesn't apply to this case. Even the Kerberos Bones case, which is perhaps the closest thing to a precedent, was not litigated and we're not aware of any cases in which this logic has been applied to a situation such as GSSAPI (whether in court or in an administrative context).