[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: noob question

From: Brett Sutton <bsutton_at_idatam.com.au>
Date: 2005-01-12 22:23:12 CET

Monks, Peter wrote:

>G'day Roel,
>
>What about those of us using the svn:// protocol who don't have (or
>want!) a web server hanging around just to display a list of
>repository URLs?
>
>Cheers,
>Peter
>
>----------------------------------------------------------------------
>Peter Monks http://www.sydneyclimbing.com/
>pmonks_at_sydneyclimbing.com http://www.geocities.com/yosemite/4455/
>----------------------------------------------------------------------
>
>
>
>
>
Exactly.

The other point I was trying to make is that svn should expose a
complete adminstration api. If you have ever used source forge with cvs
you will be aware that their are numerous operations to the repository
which can only be done via sending an email request to a source forge
admin (which is a real pain for both them and us).

If svn has a complete (remote) admin api then the complete management of
the repository can be done via remote desktop tools.

Nearly all of the staff at our organisation work from home and so there
is rarely a person capable of administrating the repository in the
office. As such we need to be able to remotely admin the repository
including listing existing repositories (makes it easy for new staff),
user administration etc.
Also a having a complete admin api will allow the creation of a complete
GUI administration tool (something I'm working on as w speak).

Brett

>
>
>
>
>>-----Original Message-----
>>From: Roel Harbers [mailto:roel@roelharbers.nl]
>>Sent: Wednesday, January 12, 2005 1:48am
>>To: users@subversion.tigris.org
>>Subject: Re: noob question
>>
>>Brett Sutton wrote:
>>
>>
>>>Roel Harbers wrote:
>>>
>>>
>>>
>>>>Robert P. J. Day wrote:
>>>>
>>>>
>>>>>i think there might be some confusion between listing the
>>>>>*repositories* on a server versus listing the *projects*
>>>>>
>>>>>
>>in a single
>>
>>
>>>>>repository, given that you already know the name of that
>>>>>
>>>>>
>>repository.
>>
>>
>>>>>the latter is easy. the former is not (at least
>>>>>
>>>>>
>>immediately) obvious.
>>
>>
>>>>>rday
>>>>>
>>>>>
>>>>
>>>>From what I understand, this is not possible for security reasons.
>>>>
>>>>If you don't know the repo name, you have no business
>>>>
>>>>
>>accessing it, or
>>
>>
>>>>something to that effect. It's like a web server denying directory
>>>>listing.
>>>>
>>>>Regards,
>>>>
>>>>Roel Harbers
>>>>
>>>>
>>>I never had much time for the security by obscurity
>>>
>>>
>>argument, especially
>>
>>
>>>if it removes a useful feature.
>>>If you were to follow that argument to its (absurd)
>>>
>>>
>>conclusion then you
>>
>>
>>>shouldn't be able to list the files or directories in a repository
>>>unless you already know their names (which is pretty much
>>>
>>>
>>what a web
>>
>>
>>>server does).
>>>
>>>Being able to list the repo's at a url seems to be
>>>
>>>
>>extremely useful and
>>
>>
>>>the security issues can be dealt with via an appropriate
>>>
>>>
>>security model.
>>
>>Obscurity != security does not mean it's a good idea to serve all
>>non-secret information to any and all interested parties.
>>
>>As an example: It might be extremely useful to get a list of
>>all valid
>>usernames, but I happen to think that in that case at least
>>the opposite
>>is true: non-obscurity = less security.
>>
>>Since user/password info is defined per repository, safely getting a
>>list of repositories would mean that yet *another*
>>authentication would
>>need to be defined to allow only trusted parties. This makes the
>>implementation non-trivial, and possibly needlessly complex,
>>and so the
>>question arises: is it worth it?
>>
>>It *is* trivial for anyone who wants to be able to list repos
>>to make a
>>webpage that lists all repo urls, so to me that would seem to be an
>>easier solution.
>>
>>Regards,
>>
>>Roel Harbers
>>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 12 22:28:57 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.