Home | Stuff | Source Archives | Links | Time Wasting Links
This patch let's you specify the remote shell program to use on a per user@host basis. This makes it a lot easier to use separate private keys for each remote repository you connect to.
It helps solves a particular problem that we have in our multi-sited development group. That is, each of us use multiple repositories that are in different administrative domains. We don't trust the communications links between our sites and we don't run a VPN, so everything must be tunneled over an encrypted path. The repository admins don't want the users to be able to log in, so the path of least resistance is to use ssh with private key login, and a login shell which does not let you do anything but start cvs. We also use separate private key pairs for each repository we connect to, so we can't just leave a single private key in ~/.ssh/.identity.
All this adds up to a big pain with CVS. This patch let's you specify different remote shell programs (like ssh) and the options to feed them (like -i ~/.ssh/repos1_dsa ) on a per host basis.
apply aginst the sources to cvs-1.12.9 and build.
Or download the fully patched sources.
Add lines of the form
to your ~/.cvsrc file. When connecting to remote server (using the :ext: protocol), CVS will match the user@host combination to select options for the remote shell program. The possible options are
firstname.lastname@example.org --rsh=/usr/bin/ssh --X=-i -X /home/tony/.ssh/ident2 email@example.com --rsh=/usr/bin/ssh --X=-i -X /home/tony/.ssh/ident2
When CVS connects to the remote server it will match the user@host specified in CVSROOT against lines in ~/.cvsrc to select the right pairing of options. Using the example above, we would end up with different private key files being used for each of these two commands
% cvs -d:ext:firstname.lastname@example.org:/repository co aproject % cvs -d:ext:email@example.com:/archive/cvs co anotherproject
The rationales for doing it this way, rather than extending the CVSROOT syntax are
The environment variable CVS_RSH takes precedence over lookups in the ~/.cvsrc file.
I don't add specific support for SSH because it would not be much easier, and it would be less general.
Really, the question is "Should CVS provide encrypted communications over SSL right out of the box, without having to use an external program?". The answer is, I think so, but it's not an easy job. Having added OpenSSL support to my HTTP protocol tool, I discovered a lot of issues about trust and certificates that would come into play. There is also the risk of opening up a brand new security hole.
If the CVS community decides it wants direct SSL support, I would be happy to try to add it just for the personal edification. If some corporation wants that before the community can come to consensus, I can quote you a price you will find attractive. Send mail to firstname.lastname@example.org.
I access a few repositories that are totally locked down. No one is allowed to log in, and we all must connect via ssh with private keys (we don't even know our passwords). The script we run as your login shell is a simple perl one I snatched off the web.
This has not been testing on Windows. It does not work on OS/2, because that code should get refactored rather than enhanced.
I grant permission to distribute this patch under the terms of the GNU Public License