Package: wnpp
Severity: wishlist

* Package name    : cvssh
  Version         : 0.3
  Upstream Author : <[EMAIL PROTECTED]>
* URL             : http://sabren.net/code/cvssh/
* License         : GPL
  Description     : a secure bridge for cvs pservers using SSL tunnel

Language: python.

(Include the long description here.)

[From the above URL]

The cvs pserver option is a useful but insecure tool for managing cvs
repositories. Most approaches to securing cvs either involve ssh
tunneling or avoid pserver altogether. The cvssh program offers a
third alternative, which combines the simplicity of ext on the client
with the flexibility of a pserver-based repository.

There are actually several other ways to access cvs:

    method              pros                    cons    
    ---------------------------------------------------------------------
    pserver             easy to manage          horribly insecure       
    chrooted            pserver + ssh           can be fairly secure    
                                                complex setup   
    ext (CVS_RSH=ssh)   security through ssh    requires shell accounts 
    kserver/gserver     kerberos security       no win32 support (??)
    ---------------------------------------------------------------------

The ext method is interesting, because it lets you specify an external
program for connecting to the repository. By default, that program is
RSH (remote shell), but usually, people change this to ssh (secure
shell) because it encrypts your data as it moves across the net.

A basic pserver setup has no encryption, which is one reason it's
insecure. Most schemes to secure pserver involve setting up ssh to
listen on the local cvspserver port (2401) and securely forward
connections to the cvspserver port on the real server. This is called
tunnelling.

The tunnelling concept is a good one, but it can be somewhat confusing
for users to set up, and it still requires at least one shell account
to work.

I wanted something that would be simpler for my customers to set up,
so I came up with my own tunnelling scheme that does not rely on ssh
port forwarding.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to