Different kinds of authentication

[Tony Hoyle <tm...@nodomain.org>]

Someone on the cvsnt list asked about doing this, and it sounds like an 
interesting project...  basically adding SSPI & SSL to svnserve.  I 
could lash something together in a couple of hours, probably but reckon 
it's better to ask here first & do it properly :)

Presumably this has been thought of, so someone's already gone through 
how it should hang together...  hardcode it in with #ifdef _WIN32, 
loadable shared libraries, or some other method.  For cvsnt I had a 
group of shared libraries that the program enumerated for protocols to 
support.

For the client side, is using svn+sspi:// or just sspi:// prerered? (I'd 
guess the svn+... syntax, from looking at the code).

(btw. I would do ssh, for which I have a patched Putty DLL, but you're 
already using that for external protocols :/).

In the back of my mind is an idea of writing a CVS Client/Server 
Protocol -> svnserve wrapper...  sounds easier than the effort currently 
required to take cvsnt itself to the next stage (which is ditching RCS, 
having reached the limits of its abilities) plus it'd mean I wouldn't be 
solely responsible for fixing bugs any more :)))

Is there any code at the moment for gzipping the output and/or 
encrypting it?  Certainly the gzip would help as checking out the 
subversion repository was really slow given that it's mostly text files. 
  Encryption is switchable with sspi (although it's only really 'secure' 
on an Active Directory over kerberos...  NTLM is a bit of a joke... 
people want it though).

Tony

btw.  Forgive the noob questions... I've skimmed the design document but 
haven't had time to read it properly yet.

Re: Different kinds of authentication for svnserve

[kf...@collab.net]

You might want to repost with 'svnserve' in the Subject line, so Greg
Hudson is sure to see it :-).  (I've done so in this followup.)

Tony Hoyle <tm...@nodomain.org> writes:
> Someone on the cvsnt list asked about doing this, and it sounds like
> an interesting project...  basically adding SSPI & SSL to svnserve.  I
> could lash something together in a couple of hours, probably but
> reckon it's better to ask here first & do it properly :)
> 
> Presumably this has been thought of, so someone's already gone through
> how it should hang together...  hardcode it in with #ifdef _WIN32,
> loadable shared libraries, or some other method.  For cvsnt I had a
> group of shared libraries that the program enumerated for protocols to
> support.
> 
> For the client side, is using svn+sspi:// or just sspi:// prerered?
> (I'd guess the svn+... syntax, from looking at the code).
> 
> (btw. I would do ssh, for which I have a patched Putty DLL, but you're
> already using that for external protocols :/).
> 
> In the back of my mind is an idea of writing a CVS Client/Server
> Protocol -> svnserve wrapper...  sounds easier than the effort
> currently required to take cvsnt itself to the next stage (which is
> ditching RCS, having reached the limits of its abilities) plus it'd
> mean I wouldn't be solely responsible for fixing bugs any more :)))
> 
> Is there any code at the moment for gzipping the output and/or
> encrypting it?  Certainly the gzip would help as checking out the
> subversion repository was really slow given that it's mostly text
> files. Encryption is switchable with sspi (although it's only really
> 'secure' on an Active Directory over kerberos...  NTLM is a bit of a
> joke... people want it though).
> 
> Tony
> 
> btw.  Forgive the noob questions... I've skimmed the design document
> but haven't had time to read it properly yet.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Different kinds of authentication

[Greg Hudson <gh...@MIT.EDU>]

Sorry for the slow response time.

On Tue, 2003-07-15 at 17:11, Tony Hoyle wrote:
> For the client side, is using svn+sspi:// or just sspi:// prerered? (I'd 
> guess the svn+... syntax, from looking at the code).

svn+foo:// is for using external agents.  If the code is going to be
internal to Subversion, the preferred method is to use the SASL
authentication framework within the regular svn protocol.  Of course,
that requires that there be a SASL mechanism defined for the given
security back-end.

> (btw. I would do ssh, for which I have a patched Putty DLL, but you're 
> already using that for external protocols :/).

I don't understand the frowny here.

> Is there any code at the moment for gzipping the output and/or 
> encrypting it?  Certainly the gzip would help as checking out the 
> subversion repository was really slow given that it's mostly text files. 

The only way to check out the Subversion repository is over HTTP, so why
is that relevant to ra_svn?  Also, isn't it a leap to assume that any
slowness is due to network bandwidth?  If the slowness is due to CPU
consumption, gzip will only make things worse, and if the slowness is
due to disk bandwidth on the client or server, compression won't matter.

I think checkouts are automatically compressed over ra_svn, because our
editor interface doesn't allow any way to specify file contents except
for deltas.  If there's no delta source, a delta against the empty
source still results in some level of compression.  (Currently, svndiff
self-compression is not as good as gzip, but there are modifications on
the back burner to remedy that.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org