You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu> on 2001/08/24 19:57:25 UTC
Re: [SVN-DEV] RE: Auth in ra_dav
On Fri, 24 Aug 2001, Sander Striker wrote:
> And, I've been having a little chat with Ben Laurie that is probably
> bringing me back to reallity: client certs.
>
> I guess I will just have to forget about ssh in combination with svn :)
SSH and client certificates both use public-key cryptography, and (I
believe) the actual algorithms to use are selectable in the protocol.
Why don't you see if you can write a ssh-public-key to "public"
client-cert and ssh-private-key to "private" client-cert converter, with
the aim of making it as easy as possibly to do the migration (i.e. without
requiring another key exchange with the project host)?
--s
Milosevic RUCKUS cryptographic SDI Saddam Hussein pending Suharto
Mk 48 Yakima blowfish Richard Tomlinson Mossad NRA DC AES Dictionary
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
>
> > Then again, discussion is always ok :)
>
> IMO, not always. It can be awfully distracting sometimes. Personally, I'd
> rather spend time on 1.0 than discussing post-1.0 items.
True, but in this particular case, I think the discussion is very
helpful. Designing authorization systems is an area where experience
counts even more than usual. This list has a lot of such experience,
collectively, and Subversion should take advantage of it.
For example, there might be something better than the sentinel system
we've planning right now. I've always had the feeling that we might
be reinventing a wheel there; if someone on this list recognizes the
wheel and knows a better way to do it, that would be great. The
chance of that benefit makes the "burden" of discussion a good risk,
IMHO.
> OTOH, I don't approve of censoring or hard rules about mailing list content.
> So that puts me in a quandary :-)
Enjoy; let us know if you need pizza shipped in or anything! :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Tripp Lilley <tl...@perspex.com>.
On Fri, 24 Aug 2001, Greg Stein wrote:
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
Don't forget that there's also the tabled discussion of whether or not
there should even *be* a "local-only" mechanism, or whether someone would
make a nice, trivial, very buttoned up Apache package to ship as part of a
"local-only" binary / source distro.
Assuming that happened, "local-only" AAA would no longer be a special
case.
--
Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
--------------------------------------------------------------------------
"The human soul is the greatest anti-piracy measure in the known
world, but no major company will use it."
<http://slashdot.org/comments.pl?sid=01/07/19/007240&cid=94>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Sat, Aug 25, 2001 at 12:37:41AM +0200, Sander Striker wrote:
>>...
>> The case where apache isn't involved. We need a way to let the repos
>> handle if a user X is allowed Y on path Z. The berkeley argument won't
>> hold, since if we get around to implementing the sql backend, writing
>> to the repos isn't so easy as it is now with berkeley db. This can
>> be done through hooks. The read/write sentinels seems a pretty
>> efficient solution.
>
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
>
>> Then again, discussion is always ok :)
>
> IMO, not always. It can be awfully distracting sometimes. Personally, I'd
> rather spend time on 1.0 than discussing post-1.0 items.
'Always' was a bit of a poorly choosen word. I should have left it out.
What I meant was that discussion about a different solution for the authz
problem would probably be a good thing, once the time is there to implement
it. For now, lets please get to M3 first :) [I'll try to shut up for a
little while now].
> OTOH, I don't approve of censoring or hard rules about mailing
> list content.
> So that puts me in a quandary :-)
:)
> Cheers,
> -g
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Aug 25, 2001 at 12:37:41AM +0200, Sander Striker wrote:
>...
> The case where apache isn't involved. We need a way to let the repos
> handle if a user X is allowed Y on path Z. The berkeley argument won't
> hold, since if we get around to implementing the sql backend, writing
> to the repos isn't so easy as it is now with berkeley db. This can
> be done through hooks. The read/write sentinels seems a pretty efficient
> solution.
While true... we have a long time to worry about that. In the meantime,
having to deal with sentinels can be a distraction from what is needed for
1.0. When different backends arrive, then we can examine other mechanisms
for authorization (which may include introducing a sentinels-like system).
> Then again, discussion is always ok :)
IMO, not always. It can be awfully distracting sometimes. Personally, I'd
rather spend time on 1.0 than discussing post-1.0 items.
OTOH, I don't approve of censoring or hard rules about mailing list content.
So that puts me in a quandary :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN and Authorization
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Aug 25, 2001 at 06:48:46PM -0700, Josh Siegel wrote:
>...
> Obviously some pam-like authentication modules for LDAP/AD will have to be
> written...Currently, my version of CVS can be set to execute a external
> shell script for authentication. We use a smbclient to authenticate windows
> users but plan on switching over to LDAP once we've upgraded the core
> servers to Windows 2000
>
> Of course, we use the same authentication scripts for our apache server...
For the Apache side, you could use mod_ntlm today:
http://modntlm.sourceforge.net/
When you upgrade your servers, you could switch to mod_auth_ldap. (note that
the latter is already incorporated into the Apache 2.0 CVS, although it will
probably move from the std. distro to an ASF "rollup" distro)
One of the reasons that we chose Apache for our network server is its
flexibility in authentication systems. There was no way that we (the SVN
team) wanted to do a bunch of work for each possible authentication
mechanism out there (or come up with our own(?!!)).
Cheers,
-g
p.s. okay... so I needed to convince the other guys about using Apache to
avoid the auth situation, but it didn't take too long to show them the
Light... :-)
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN and Authorization
Posted by Josh Siegel <jo...@stormbirds.org>.
[...]
How do you -identify- somebody (and hence their privileges) in a
cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is
complex.
[...]
Obviously some pam-like authentication modules for LDAP/AD will have to be
written...Currently, my version of CVS can be set to execute a external
shell script for authentication. We use a smbclient to authenticate windows
users but plan on switching over to LDAP once we've upgraded the core
servers to Windows 2000
Of course, we use the same authentication scripts for our apache server...
-josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN and Authorization
Posted by roger day <ro...@nenuphar.freeserve.co.uk>.
How do you -identify- somebody (and hence their privileges) in a cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is complex.
----- Original Message -----
From: "Bill Tutt" <ra...@lyra.org>
To: "'C. Scott Ananian'" <ca...@lesser-magoo.lcs.mit.edu>
Cc: <de...@subversion.tigris.org>
Sent: Saturday, August 25, 2001 02:32
Subject: SVN and Authorization
>
>
> From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
>
> > On Sat, 25 Aug 2001, Sander Striker wrote:
>
> > > The case where apache isn't involved. We need a way to let the
> repos
> > > handle if a user X is allowed Y on path Z. The berkeley argument
> > > won't hold, since if we get around to implementing the sql backend,
> > > writing to the repos isn't so easy as it is now with berkeley db.
> > > This can be done through hooks. The read/write sentinels seems a
> > > pretty efficient solution. Then again, discussion is always ok :)
>
> > I read the berkeley db argument as, "The filesystem is responsible for
> > authentication and enforcing access controls for local repositories".
> > The initial file system implementation, built on Berkeley DB, seems to
> > be a 'permissions-free' file system. As you point out, implementing
> > the filesystem on top of a "real" DB would enforce whatever
> > authentication/access control mechanisms the DB enforced. I'm still
> > hoping for a plain-text unixy filesystem implementation at some point;
> > this impl would extends unix authentication/etc to SVN.
>
> Ick. You really don't want to use a unixy file system approach to
> authorization issues.
> Security models have gotten so much better since then.
>
> Here's a possible security model for SVN:
>
> There are the following access levels:
> * Read: The level ViewSVN would need. Displays file histories, and
> actual contents, but you can't actually commit any changes.
> * Write: You can commit changes, and stuff.
> * Admin: You can do anything. (user management, etc...)
>
> An SVN ACL would contain the following info:
> * Access level
> * User/Group this Access Level applies to, can apply to everyone (except
> admin).
> * Hosts this access level is allowed for. (Standard IP wildcarding stuff
> here)
> * Path of the repository that this access applies to. E.g. a path of '/'
> would mean apply to the whole repository. While a path of '/blah/blah2'
> would apply to all subdirectories of blah2.
>
> A DACL (deny ACL) would contain the exact same information, except it
> would prevent the associated user/group from obtaining the requested
> access level on a given path.
>
> Decent security models allow resources to be accessed by more than one
> group, and allow the use of DACLs to handle group overlap problem cases.
> Unix filesystems don't even come close to allowing that kind of
> flexibility.
>
> Note: The above doesn't take any kind of consideration for the current
> state of the SVN file system layer, it's just an idea. :)
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SVN and Authorization
Posted by Bill Tutt <ra...@lyra.org>.
From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
> On Sat, 25 Aug 2001, Sander Striker wrote:
> > The case where apache isn't involved. We need a way to let the
repos
> > handle if a user X is allowed Y on path Z. The berkeley argument
> > won't hold, since if we get around to implementing the sql backend,
> > writing to the repos isn't so easy as it is now with berkeley db.
> > This can be done through hooks. The read/write sentinels seems a
> > pretty efficient solution. Then again, discussion is always ok :)
> I read the berkeley db argument as, "The filesystem is responsible for
> authentication and enforcing access controls for local repositories".
> The initial file system implementation, built on Berkeley DB, seems to
> be a 'permissions-free' file system. As you point out, implementing
> the filesystem on top of a "real" DB would enforce whatever
> authentication/access control mechanisms the DB enforced. I'm still
> hoping for a plain-text unixy filesystem implementation at some point;
> this impl would extends unix authentication/etc to SVN.
Ick. You really don't want to use a unixy file system approach to
authorization issues.
Security models have gotten so much better since then.
Here's a possible security model for SVN:
There are the following access levels:
* Read: The level ViewSVN would need. Displays file histories, and
actual contents, but you can't actually commit any changes.
* Write: You can commit changes, and stuff.
* Admin: You can do anything. (user management, etc...)
An SVN ACL would contain the following info:
* Access level
* User/Group this Access Level applies to, can apply to everyone (except
admin).
* Hosts this access level is allowed for. (Standard IP wildcarding stuff
here)
* Path of the repository that this access applies to. E.g. a path of '/'
would mean apply to the whole repository. While a path of '/blah/blah2'
would apply to all subdirectories of blah2.
A DACL (deny ACL) would contain the exact same information, except it
would prevent the associated user/group from obtaining the requested
access level on a given path.
Decent security models allow resources to be accessed by more than one
group, and allow the use of DACLs to handle group overlap problem cases.
Unix filesystems don't even come close to allowing that kind of
flexibility.
Note: The above doesn't take any kind of consideration for the current
state of the SVN file system layer, it's just an idea. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On Sat, 25 Aug 2001, Sander Striker wrote:
> The case where apache isn't involved. We need a way to let the repos
> handle if a user X is allowed Y on path Z. The berkeley argument won't
> hold, since if we get around to implementing the sql backend, writing
> to the repos isn't so easy as it is now with berkeley db. This can
> be done through hooks. The read/write sentinels seems a pretty efficient
> solution. Then again, discussion is always ok :)
I read the berkeley db argument as, "The filesystem is responsible for
authentication and enforcing access controls for local repositories". The
initial file system implementation, built on Berkeley DB, seems to be a
'permissions-free' file system. As you point out, implementing the
filesystem on top of a "real" DB would enforce whatever
authentication/access control mechanisms the DB enforced. I'm still
hoping for a plain-text unixy filesystem implementation at some point;
this impl would extends unix authentication/etc to SVN.
I just hope that SVN's filesystem interface includes an errno for
'permission denied' and that SVN will do a sensible thing if/when this
error is encountered.
--s
Minister AP shortwave Hawk affinity group Milosevic interception UKUSA
Morwenstow cryptographic Richard Tomlinson Waihopai LA FSF assassination
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 10:58:04PM +0200, Sander Striker wrote:
> >...
> > Yes, that was something on my mind too :)
> > I'll speak to Ben Laurie again and see if he can explain the details
> > of the certificate generation process to me. I'll then get started
> > on such a conversion util (which we could dump in /contrib ?)
> provided it
> > is at all possible. In any case I'll report back here.
>
> I would hope that you would contribute it to the Subversion project, and
> we'd check it into the tools directory.
>
> > Greg gave a good insight on the authentication part of my
> question(s), thx.
> > As for the authorization part, that's going to work through hooks which
> > is a 'Good Thing' because it is easily custimizable. Once the protocol
> > is set for the r/w sentinels (or once you get discussing these)
> > I'll jump in again ;)
>
> Apache does both authentication and authorization. I'm still waiting for
> people to explain what kinds of authz they want that Apache can't
> handle.
The case where apache isn't involved. We need a way to let the repos
handle if a user X is allowed Y on path Z. The berkeley argument won't
hold, since if we get around to implementing the sql backend, writing
to the repos isn't so easy as it is now with berkeley db. This can
be done through hooks. The read/write sentinels seems a pretty efficient
solution. Then again, discussion is always ok :)
> Or for a specific design that they'd like to see, which we could then use
> within the standard Apache authz system.
:)
> [ as you may have guessed, I'm not a fan of external authz systems. and I
> think that I may even disagree with the sentinel concept (need more
> research and thinking on that) (it seems they just kind of
> appeared while I was away; either that, or whothehellknows where I
> was :-)) ]
That tends to happen :)
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 10:58:04PM +0200, Sander Striker wrote:
>...
> Yes, that was something on my mind too :)
> I'll speak to Ben Laurie again and see if he can explain the details
> of the certificate generation process to me. I'll then get started
> on such a conversion util (which we could dump in /contrib ?) provided it
> is at all possible. In any case I'll report back here.
I would hope that you would contribute it to the Subversion project, and
we'd check it into the tools directory.
> Greg gave a good insight on the authentication part of my question(s), thx.
> As for the authorization part, that's going to work through hooks which
> is a 'Good Thing' because it is easily custimizable. Once the protocol
> is set for the r/w sentinels (or once you get discussing these) I'll jump
> in again ;)
Apache does both authentication and authorization. I'm still waiting for
people to explain what kinds of authz they want that Apache can't handle. Or
for a specific design that they'd like to see, which we could then use
within the standard Apache authz system.
[ as you may have guessed, I'm not a fan of external authz systems. and I
think that I may even disagree with the sentinel concept (need more
research and thinking on that) (it seems they just kind of appeared while
I was away; either that, or whothehellknows where I was :-)) ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 03:57:25PM -0400, C. Scott Ananian wrote:
> > On Fri, 24 Aug 2001, Sander Striker wrote:
> > > And, I've been having a little chat with Ben Laurie that is probably
> > > bringing me back to reallity: client certs.
> > >
> > > I guess I will just have to forget about ssh in combination
> with svn :)
> >
> > SSH and client certificates both use public-key cryptography, and (I
> > believe) the actual algorithms to use are selectable in the protocol.
> > Why don't you see if you can write a ssh-public-key to "public"
> > client-cert and ssh-private-key to "private" client-cert converter, with
> > the aim of making it as easy as possibly to do the migration
> (i.e. without
> > requiring another key exchange with the project host)?
>
> Ah. Good idea... that is just the kind of idea I was hoping people would
> come up with.
Yes, that was something on my mind too :)
I'll speak to Ben Laurie again and see if he can explain the details
of the certificate generation process to me. I'll then get started
on such a conversion util (which we could dump in /contrib ?) provided it
is at all possible. In any case I'll report back here.
Greg gave a good insight on the authentication part of my question(s), thx.
As for the authorization part, that's going to work through hooks which
is a 'Good Thing' because it is easily custimizable. Once the protocol
is set for the r/w sentinels (or once you get discussing these) I'll jump
in again ;)
Sander
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 03:57:25PM -0400, C. Scott Ananian wrote:
> On Fri, 24 Aug 2001, Sander Striker wrote:
> > And, I've been having a little chat with Ben Laurie that is probably
> > bringing me back to reallity: client certs.
> >
> > I guess I will just have to forget about ssh in combination with svn :)
>
> SSH and client certificates both use public-key cryptography, and (I
> believe) the actual algorithms to use are selectable in the protocol.
> Why don't you see if you can write a ssh-public-key to "public"
> client-cert and ssh-private-key to "private" client-cert converter, with
> the aim of making it as easy as possibly to do the migration (i.e. without
> requiring another key exchange with the project host)?
Ah. Good idea... that is just the kind of idea I was hoping people would
come up with.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org