Re: cvs.debian.org problem
On Fri, Jan 31, 2003 at 01:24:45PM +0100, Thomas Wouters wrote:
> For network access, subversion uses WebDAV (with DeltaV) which is an
> extension of HTTP specifically designed to also work with HTTPS and
> proxies and such. As such, it is as secure from attacks such as
> man-in-the-middle as the SSL implementation.
I haven't investigated the situation personally, but I was told on #svn that
certificates were not verified. If this is the case, then there is zero
protection against a man-in-the-middle attack.
> > I believe it is possible with subversion to grant meaningful read-only
> > repository access, which would be better than what pserver gives you for
> > anonymous users.
>
> It is. In fact, subversion's 'read-only' access through WebDAV is simply
> 'HTTP' :) The 'properties' and 'history' features are of course only
> available to real WebDAV/DeltaV/subversion clients, but even then you don't
> have to support everything. You can always browse the trunk by using a
> simple webbrowser:
>
> http://svn.collab.net/repos/svn/trunk/
Yes, I've used precisely that URL to browse the subversion source, and I
like the idea for read-only access.
> I don't think the HTTP server needs write access to the repository (which
> is a transactioned berkeley db file) at all (for read-only operation), so
> you could set up a 'read-only' WebDAV/subversion server and do
> modifications using a different WebDAV server, or using the local-client
> or ssh-tunnelling method. If you're really paranoid (which is good), you
> can setup the readonly server on a different machine and just rsync the
> repository every now and then.
This is all fine, except that there is no ssh-tunnelling method; WebDAV is
the only remote access method. ra_pipe, as far as I could see the last time
I looked at it, is abandoned, and has never worked properly.
Also, neither of these ideas is particularly attractive to me:
- giving the web server access to content would otherwise be readable only
by specially privileged users (_especially_ write access)
- maintaining a separate authentication database for use with the web
server, when I already have a perfectly good ssh-based authentication
setup which is used for many other services
--
- mdz
Reply to: