Re: PATCH: Support :ssh: method in CVS/Repository - How common

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


A few points of clarification may be in order concerning CVS, CVSNT and
the support for the rsh and ssh transports. I am sure that Derek or
Larry or Arthur Barrett will make corrections if any of these fact are
not correct.

The CVS code base is not itself a GNU project. However, the code has
been distributed under the GNU copyleft since it was first released to
the Internet in 1989. The latest sources for CVS may be downloaded from
ftp://ftp.gnu.org/gnu/non-gnu/cvs/source/feature/1.12.13/ or
ftp://ftp.gnu.org/gnu/non-gnu/cvs/source/stable/1.11.21/

This line of code has supported the :ext: method since 1995. The :ext:
method has always meant a particular kind of client/server interaction
that has assumed an eight-bit clean transport layer.

In addition to the :ext: method, there are other methods such as
:pserver:, :gserver: (a GSSAPI mechanism), and ":kserver:" that are able
to perform variations on the client/server protocol. The other methods
differ from the :ext: method in that the :ext: method uses a transparent
transport layer that does not have any of the system authentication code
included in CVS. As CVS has never been touted as a strong security
application implementation, reliance on :ext: to let the system do
authentication and authorization has always been considered superior.

The first transport layer was 'rsh' and later 'ssh' was available. The
CVS_RSH environment variable has existed to allow users to specify 'rsh'
or 'remsh' or 'ssh' as needed. This allowed a client user to specify
either the full pathname or the command name in $PATH to be used to
initiate the transport layer connection to the remote server and the
CVS_SERVER variable allowed the client user to specify the pathname to
the cvs executable on the remote system.

The CVS sources were forked some time back and the CVSNT project created
with the primary focus on the Windows operating system. That project
choose to add a number of different access methods including the :ssh:
and :extssh: methods.

CVS 1.12.2 added a long-standing patch used by many of the Open Source
operating system distributions (GNU/Linux, FreeBSD, NetBSD, OpenBSD) to
allow the user to specify the default transport to be used with the
:ext: method. This is the 'configure --with-rsh=ssh' option. The default
was still 'rsh' for that release.

cvs 1.12.11 enhanced the :ext: method to support the specification of
some environment settings in the CVSROOT environment variable and
command-line option. This allows a syntax such as:

   CVSROOT=":ext;CVS_RSH=ssh:address@hidden/path/to/repository"

and have the cvs 1.12.x client connect to the remote server using the
pathname to ssh in the CVS_RSH setting for all connections of that
particular checked-out tree. This is documented. I suggest the following
link:

  http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_2.html#IDX75

be considered. The cvs 1.12.11 also added the CVS_SERVER option at the
same time.

CVS 1.12.12 changed the default transport for the :ext: method to be the
'ssh' executable found in the user's path. The 'configure --with-rsh=rsh'
option could be used to select the previous default value if desired.

CVS 1.12.14 (not yet released) has added the :extssh: method as a way to
aid the Eclipse user community who were having problems getting Eclipse
to properly honor the CVS_RSH environment variable settings. (I am not
clear that this was really a good idea. Derek Price <address@hidden
added the code as a kindness to Eclipse users on 2005-12-07.)

The latest versions of CVS may be accessed via a web browser or
via anonymous CVS access. See https://savannah.nongnu.org/cvs/?group=cvs

Maintainers of Savannah.gnu.org and Savannah.nongnu.org may use the ssh
protocol to do checkouts and commits to the repository. They will do so
with a CVS client that is able to use the :ext: protocol over the ssh
transport. This may be encoded into new CVS/Root files using either
":ext:address@hidden/sources/project" with any modern CVS
which will default to using the ssh transport OR
":ext;CVS_RSH=/usr/local/bin/ssh:address@hidden/sources/project"
to specify a particular ssh client to use OR
":extssh:address@hidden/sources/project" to specify using the
first 'ssh' client in the $PATH for the user OR the user may set their
CVS_RSH environment variable to 'ssh' (or /usr/local/bin/ssh or
/usr/bin/ssh or whatever location of their ssh client is correct) and
use a CVS client that may default to using 'rsh' or 'ssh'.

Due to the way that lists.gnu.org threads its archives, you will find it
desirable to read the first message started last month with the first
link and then the thread for the rest of the topic with the second link:

  http://lists.gnu.org/archive/html/info-cvs/2006-03/msg00269.html
  http://lists.gnu.org/archive/html/info-cvs/2006-04/msg00000.html

CVS 1.12.14 (not yet released) will be adding the :extssh: method (or,
at least that patch is presently part of our unreleased sources in the
repository). This patch was in aid of the open source Eclipse IDE which
apparently had problems using the CVS_RSH environment variable. The
:extssh: method is effectively a shorthand for :ext;CVS_RSH=ssh: and
does NOT allow for the specification of a password on the host
specification. The template for :ext: is this:
  "[:ext[;keyword=value...]:address@hidden:]/path"

In the past have objected to the method name :ssh: which CVSNT
implemented (as well as the CVSNT :rsh: method). The :ssh: method which
CVSNT implements also has this template:
":ssh[;keyword=value...]:[username[:address@hidden:port][:]/path", and
I do NOT like to have a password in the CVS/Root file on a multi-user
platform of any kind.

Finally, the :ssh: name implies to my mind that there is a copy of the
SecSH protocol stack implemented directly into the CVS executable (which
is NOT the case).

In the best of all possible worlds, it should be possible for any CVS
client product to parse any existing CVS/Root file and do the "Right
Thing[TM]" as well as writing the most conservative CVS/Root file
possible so that even the 'STABLE' release of cvs 1.11.21 which does not
support the :ext;CVS_RSH=ssh: or :extssh: syntax would still work.

At present, to the best of my understanding, CVS 1.11.x is still the
largest installed base of clients and servers. However, the Windows
market uses CVSNT which comes bundled with TortoiseCVS and WinCVS GUI
packages. There are currently fewer CVS 1.12.x servers in the field than
CVSNT installations.

CVSNT does support a number of methods that CVS does not support and
probably never will support. A breakdown of the various major releases
of CVS and CVS methods follows.

CVS methods for STABLE (CVS 1.11.x):
  "[:local:[letter:]]/path"
  ":(gserver|kserver|pserver):[[user][:address@hidden:[port]]/path
  "[:(ext|server):address@hidden:]/path"
  ":fork:/path"
  
CVS methods for FEATURE (CVS 1.12.13):
  "[:local:[letter:]]/path"
  ":(gserver|kserver|pserver):[[user][:address@hidden:[port]]/path
  "[:(ext|server)[;keyword=value...]:address@hidden:]/path"
  ":fork:/path"

  where valid keyword options are:
    proxy=<hostname>
    proxyport=<integer>
    CVS_RSH=<pathname>
    CVS_SERVER=<pathname>
    Redirect

CVS methods added for non-released sources (targeted for CVS 1.12.14):
  ":extssh[;keyword=value...]:address@hidden:]/path"


CVSNT methods as of 2.6.x:
  ":ext[{program}][;keyword=value...]:address@hidden:]/path",
  ":fork[;keyword=value...]:/path",
  ":gserver[;keyword=value...]:host[:port][:]/path",
  ":sspi[;keyword=value...]:[username[:address@hidden:port][:]/path",
  ":ssh[;keyword=value...]:[username[:address@hidden:port][:]/path",
  ":rsh[;keyword=value...]:[username[:address@hidden:port][:]/path",
  ":extssh[;keyword=value...]:[username[:address@hidden:port][:]/path",
  ":sserver[;keyword=value...]:[username[:address@hidden:port][:]/path",
  ":pserver[;keyword=value...]:[username[:address@hidden:port][:]/path",

I would have thought that supporting :ext: and CVS_RSH was sufficient to
inter-operate with both CVS and CVSNT. It is a pity that this does not
apparently work for the IDEA product.

I hope you find the above information useful.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQFEMAAKCg7APGsDnFERAkEkAJ91SdF1cWXIbDSTF/eWW0ePeMlCXACgraM+
aRrnkUF7vU8cIdw6U8PinzA=
=JMrd
-----END PGP SIGNATURE-----