[lug] CVSROOT and CVS/Root

[Joseph McDonald]

Kerberized CVS is also an option which provides encrypted rsh, rcp
and rshell. It doesn't get around having to add principals for each
user or using a group account but it's an option for those that need
secure software repositories. We use it at UUNET and it simply adds
encryption to CVS, and not a lot more. If you're already using krb,
then it's simple. 

	--joey



Bear Giles said:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As an aside, there are perennial projects in progress to add SSL support
> directly to CVS.
> 
> There are a several reasons for doing this.  They might seem excessive
> to you, but it can limit CVS adoption at some sites.
> 
> First, SSH tunnels require setting up an account for each user, or at
> least for a group 'cvsuser' account, on the CVS server.  This prevents
> "closed system" semantics where there are no user accounts... and that
> opens up your server for local attacks, not just remote attacks.  Of
> course, a direct connection requires you to open another hole in your
> firewall (unless you run the direct SSL connection through an SSL tunnel!).
> 
> Second, the user isn't able to verify the identity of the CVS server.
> If the SSH tunnels are set up with host authentication you can usually
> catch attempts to do a man-in-the-middle attack, but there is no
> affirmative confirmation that you're speaking with the expected CVS
> server via a fully protected communications channel.  With a server cert
> and client-side checks, you can have much more confidence in the
> identity of the server.
> 
> Third, the server isn't able to verify the identity of the CVS client.
> Again, SSH tunnels can be set up to require "RSA" authentication, but
> how many sites actually do this?  And require their clients keep their
> keys encrypted?  CVS authentication itself is trivially broken - the
> password is stored in what amounts to plaintext, so if anyone can get
> that file they can impersonate that user.  With client certs (if
> required), you can have much more confidence in the identity of the
> person grabbing files or commiting changes.
> 
> As I said, this is stuff that won't matter to most users.  But it's
> critical if you want true accountability - right now it's far too easy
> for somebody with a little bit of knowledge to impersonate another
> person while making changes.
> 
> The problem with adding SSL support is that, ironically, CVS already
> uses a STREAMS-like network layer.  So does SSL, and the implementations
> can't be intermixed.  So while other applications can simply replace the
> socket calls with the corresponding SSL calls (and stuff all of the
> initialization code that the quickie SSL support inevitably overlooks -
> ephemeral keys, sessions, etc.), with CVS it makes more sense to invest
> the effort to marry the two systems.  That's a difficult problem, esp.
> when you can't assume that everyone will be able to link in the SSL
> networking library even if they don't actually use SSL.
> 
> Bear
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE9tXB6mr0uXf8FxOURAoEfAKDOmUbFBIxAi6DH7L2LH9UMj7E4YQCgq8nP
> IBHtU1fp4aE4nhG4bBpK+FQ=
> =QL5v
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>