Malcolm Rowe wrote:
> (Replying to everyone in one go to reduce the spam)
>
> On Wed, Feb 14, 2007 at 01:00:39PM -0800, Blair Zajac wrote:
>> Malcolm Rowe wrote:
>>> file:/// clients, by definition, can do anything to the repository,
>>> including corrupting it beyond all recognition. Adding any kind of
>>> security to ra_local is basically not going to work - the client is
>>> responsible for enforcing it.
>> I don't see anywhere that we treat file:/// by definition any different
>> than the other protocols.
>>
>
> Well, ra_local repositories don't support any form of authz, for one.
> You're trusting that the client will be a good client and run the
> hooks, set the right author name, etc - an ra_local client using the
> Subversion API (even through the bindings) can basically do anything.
Presumably, if somebody has access to an NFS/Windows share, then they
already have the auth.
I would like to trust the client. I'm not concerned about rogue
clients, most clients that somebody doesn't know what they are doing are
well behaved and will honor the hook scripts.
>> I don't see it hard having the svn client provide an environmental
>> variable that the pre-commit script can look for the existence of.
>>
>
> It's not difficult inasmuch as it doesn't really buy you anything for
> ra_local clients: it only solves the specific problem of a well-behaved
> client using pre-1.5 libraries doing a merge and not recording history.
> It doesn't, for example, solve the problem of the same user doing a
> merge via diff/patch to his local wc and committing using a 1.5 client.
If they do that much, then they are probably more knowledged than most
users. Many people I train don't even know what a unified diff format i.
> I dunno, I just think it's a problem better solved through policy that
> via technical means.
>
> [Oh, technically, we would have to work out how to pass the client
> library version number over ra_svn, but that's just a SMOP.]
>
> On Wed, Feb 14, 2007 at 01:54:24PM -0800, Blair Zajac wrote:
>> Much easier to exclude all clients < 1.5 and have a company policy that
>> any clients that come online need to be >= 1.5 than to distinguish
>> between types of merges.
>>
>
> Those two are orthogonal. Do you _really_ need the technical part if
> you've already established a non-technical policy?
Policy is just policy, it doesn't enforce anything. We could have a
policy that nobody but committers is allowed to commit to our repository
and not have any authz, but we don't do that.
Regards,
Blair
attached mail follows:
(Replying to everyone in one go to reduce the spam)
On Wed, Feb 14, 2007 at 01:00:39PM -0800, Blair Zajac wrote:
> Malcolm Rowe wrote:
> >file:/// clients, by definition, can do anything to the repository,
> >including corrupting it beyond all recognition. Adding any kind of
> >security to ra_local is basically not going to work - the client is
> >responsible for enforcing it.
>
> I don't see anywhere that we treat file:/// by definition any different
> than the other protocols.
>
Well, ra_local repositories don't support any form of authz, for one.
You're trusting that the client will be a good client and run the
hooks, set the right author name, etc - an ra_local client using the
Subversion API (even through the bindings) can basically do anything.
> I don't see it hard having the svn client provide an environmental
> variable that the pre-commit script can look for the existence of.
>
It's not difficult inasmuch as it doesn't really buy you anything for
ra_local clients: it only solves the specific problem of a well-behaved
client using pre-1.5 libraries doing a merge and not recording history.
It doesn't, for example, solve the problem of the same user doing a
merge via diff/patch to his local wc and committing using a 1.5 client.
I dunno, I just think it's a problem better solved through policy that
via technical means.
[Oh, technically, we would have to work out how to pass the client
library version number over ra_svn, but that's just a SMOP.]
On Wed, Feb 14, 2007 at 01:54:24PM -0800, Blair Zajac wrote:
> Much easier to exclude all clients < 1.5 and have a company policy that
> any clients that come online need to be >= 1.5 than to distinguish
> between types of merges.
>
Those two are orthogonal. Do you _really_ need the technical part if
you've already established a non-technical policy?
On Wed, Feb 14, 2007 at 01:41:00PM -0800, Daniel Rall wrote:
> Indeed. I share Blair's concerns here. I know this will be a
> complaint from my customer base.
>
Dan, in your case, you serve everything over ra_dav, right? If so, you
already have the useragent string available in every request (something
like "SVN/1.4.0 (r21228) neon/0.25.5"), and so you can just install a
frontend filter to match on the UA (something I suspect that Apache can
do quite easily).
On Wed, Feb 14, 2007 at 10:47:14PM +0100, Erik Huelsmann wrote:
> When we introduced locking, didn't we do a little trick to ensure we
> were using only the right (locking) clients/servers to access a
> repository?
No, we didn't. We said 'don't do that', which IMO was the right answer.
Pre-1.2 clients just don't respect locks, but we don't lock out the
repository either.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
- application/pgp-signature attachment: stored
Received on Thu Feb 15 18:31:31 2007