You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2007/02/13 00:58:14 UTC
merge tracking: rejecting commits from svn clients < 1.5
Hosting a publicly available svn repository and in our private ones, I
would like so reject merges or commits from 1.4 clients that would not
probably update the merge tracking info in a 1.5 server.
I'm thinking this is something we may want to provide, as an
administrator, I wouldn't want people committing and not properly
updating the merge info, as I'm guessing it may cause more work later on
or cause untracked merges.
Can we provide this info in the pre-commit hook somehow?
With mod_dav_svn, I guess we can get the client version string and use
that? Would the easy way be to reject commits at the Apache level and
parse the client's name?
But what about file:/// or svn:// access?
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 13 Feb 2007, Kamesh Jayachandran wrote:
> Blair wrote:
> ...
> >I presume there are new APIs that the svn HTTP client is using to send
> >to the server to update the metadata? Or this is just a property only
> >change?
>
> It is just a property change.
When necessary, the client uses a new merge info retrieval API to look
up merge info stored in the repository which may or may not be
available locally (if no merge info is set on a path, it's inheritted
from parent paths).
For ra_svn, the client uses the available capabilities detection
facilities to determine whether the repository supports this API.
For ra_dav and ra_serf, the client always tries to retrieve the merge
info, assuming there's no merge info if the repository responds with
HTTP_NOT_IMPLEMENTED (501).
For ra_local, this is obviously a non-issue.
> >Could we not have the client always make a call to some new API that
> >would indicate to mod_dav_svn that even if there's no merge metadata
> >to send, that the client would have sent it if there was info to send?
> >
> >The server could have a bit checked when it saw this call, indicating
> >that the client is merge metadata aware.
>
> Not sure how it would help.
> Let us say whenever a merge happens we mandate some indicator_API to be
> called to ensure that Caller is a 1.5.x client.
> Server is totally incapable to distinguish a commit being a result of
> merge+commit or adhoc change + commit.
>
> If it is merge+commit 1.5.x client would have called indicator_API that
> would give a clue of 'merge+commit'. But how can we differentiate from
> 'merge+commit' by <1.5.x clients and any other commit from any client.
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Kamesh Jayachandran <ka...@collab.net>.
>
> I presume there are new APIs that the svn HTTP client is using to send
> to the server to update the metadata? Or this is just a property only
> change?
>
It is just a property change.
> Could we not have the client always make a call to some new API that
> would indicate to mod_dav_svn that even if there's no merge metadata
> to send, that the client would have sent it if there was info to send?
>
> The server could have a bit checked when it saw this call, indicating
> that the client is merge metadata aware.
Not sure how it would help.
Let us say whenever a merge happens we mandate some indicator_API to be
called to ensure that Caller is a 1.5.x client.
Server is totally incapable to distinguish a commit being a result of
merge+commit or adhoc change + commit.
If it is merge+commit 1.5.x client would have called indicator_API that
would give a clue of 'merge+commit'. But how can we differentiate from
'merge+commit' by <1.5.x clients and any other commit from any client.
With regards
Kamesh Jayachandran
>
> Regards,
> Blair
>
> ---------------------------------------------------------------------
> 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: merge tracking: rejecting commits from svn clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Mon, 12 Feb 2007, John Peacock wrote:
>
>> Blair Zajac wrote:
>>> With mod_dav_svn, I guess we can get the client version string and use
>>> that? Would the easy way be to reject commits at the Apache level and
>>> parse the client's name?
>>>
>>> But what about file:/// or svn:// access?
>
> Was this in response to my recent addition to the func spec?
> http://subversion.tigris.org/merge-tracking/func-spec.html#migration-and-interoperability
>
> I tend to agree...
Yes, prompted by that commit.
>> file:/// access is, pretty much by default, not something that you would want to
>> allow any sort of public access. svn:// is only slightly better, from a
>> security standpoint. I don't think it is *too* much of a loss if we only
>> provided a way to block back-rev'd client access under Apache.
>
> We could do some type of client capabilities detection, and pass that
> on to the hook scripts via a new parameter or environment variable.
> Client capabilities aren't easily detectable in a mod_dav_svn
> environment, however...
I presume there are new APIs that the svn HTTP client is using to send
to the server to update the metadata? Or this is just a property only
change?
Could we not have the client always make a call to some new API that
would indicate to mod_dav_svn that even if there's no merge metadata to
send, that the client would have sent it if there was info to send?
The server could have a bit checked when it saw this call, indicating
that the client is merge metadata aware.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 12 Feb 2007, John Peacock wrote:
> Blair Zajac wrote:
> > With mod_dav_svn, I guess we can get the client version string and use
> > that? Would the easy way be to reject commits at the Apache level and
> > parse the client's name?
> >
> > But what about file:/// or svn:// access?
Was this in response to my recent addition to the func spec?
http://subversion.tigris.org/merge-tracking/func-spec.html#migration-and-interoperability
I tend to agree...
> file:/// access is, pretty much by default, not something that you would want to
> allow any sort of public access. svn:// is only slightly better, from a
> security standpoint. I don't think it is *too* much of a loss if we only
> provided a way to block back-rev'd client access under Apache.
We could do some type of client capabilities detection, and pass that
on to the hook scripts via a new parameter or environment variable.
Client capabilities aren't easily detectable in a mod_dav_svn
environment, however...
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Feb 12, 2007 at 08:04:57PM -0500, John Peacock wrote:
> file:/// access is, pretty much by default, not something that you would want to
> allow any sort of public access. svn:// is only slightly better, from a
> security standpoint.
I'm curious as to what particular advantages you're thinking about
that the http:// RA method has over the svn:// RA method with regards
to security?
Regards,
Malcolm
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/13/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> a generic DAV client issuing a LOCK request. )Or -- perhaps even
> simpler -- mod_dav_svn can look for the User-agent: header on the
> request, which includes "SVN/version-number". Although feature
> negotation via X-SVN-Options: is considered a better practice than
> parsing version numbers.)
FTR, ra_serf just sets the User-Agent header to: "svn/ra_serf". We
could be smarter about that though. Patches welcomed. =)
Though I agree that X-SVN-Options is a smarter move. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 2/13/07, John Peacock <jp...@rowman.com> wrote:
> This is a very different beast from http:// access, which is designed
> specifically to be handled over a public transport method, and to
> bootstrap on the existing Apache infrastructure. As much as possible,
> it would be prudent to maintain as much comparable features as possible
> between http:// and svn://, but there are limitations to the underlying
> protocols that may make some things easier and others difficult. As the
> main thread has progressed, it is even questionable whether the client
> version string is available to mod_dav_svn.
I don't understand what all the fuss is about in this thread. Both
http:// and svn:// network layers have feature negotiation abilities,
and have had them for years.
For http://, this is exactly what the OPTIONS request is for. That
method at least allows a client to query a server's abilities. Since
we want the opposite (the server to query the client's abilities), it
should be as simple as having mod_dav_svn examine the X-SVN-Options:
header attached to the client's' MERGE' request. This is the way (for
example) mod_dav_svn can tell the difference between an svn client and
a generic DAV client issuing a LOCK request. )Or -- perhaps even
simpler -- mod_dav_svn can look for the User-agent: header on the
request, which includes "SVN/version-number". Although feature
negotation via X-SVN-Options: is considered a better practice than
parsing version numbers.)
On the svnserve side, take a look at libsvn_ra_svn/protocol. In
section #2, it clearly explains how connection handshaking works.
There's a specific part where the client delineates its 'capabilities'
to the server. If svnserve doesn't see merge-tracking listed in the
client's features, it can refuse the connection.
So it's pretty easy to make svnserve and apache reject older clients.
The only real question is: what UI do we give to server
administrators to 'activate' this behavior? Could be something as
simple as new httpd.conf and svnserve.conf directives.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Alan Barrett <ap...@cequrux.com>.
On Tue, 13 Feb 2007, John Peacock wrote:
> Alan Barrett wrote:
> >No, svn+ssh:// is not morally equivalent to file:// access. It does
> >not require a local account to be associated with the ssh key.
>
> I didn't suggest that a *different* local account was required for each
> ssh key, but rather that *a* local account was required.
Sorry, I misunderstood you. I thought you were trying to use the
presence of a local account as a difference between apache and svn+ssh,
but of course apache also requires the mod_dav_svn process to run as a
local user that has access to the files that make up the backend of the
repository.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by John Peacock <jp...@rowman.com>.
Alan Barrett wrote:
> No, svn+ssh:// is not morally equivalent to file:// access. It does
> not require a local account to be associated with the ssh key.
I didn't suggest that a *different* local account was required for each
ssh key, but rather that *a* local account was required. svn+ssh
executes svnserve as some local user account which requires read/write
access to the repository (which is why multiple local accounts is a pain
to configure properly). That svnserve process then communicates via the
tunnel with the local (to the user) svn client. svn+ssh is also not
able to be used for anonymous read-only access (since you have to add
the ssh key before you can get any access). You can run svn:// access
in read-only mode, however
However, as sussman has pointed out, the svnserve protocol already has
client capabilities negotiation. It seems likely that both svnserve and
mod_dav_svn could be taught to block back-rev'd client access without
much difficulty. The question then becomes how to write that interface...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Alan Barrett <ap...@cequrux.com>.
On Tue, 13 Feb 2007, John Peacock wrote:
> Alan Barrett wrote:
> >Please don't conflate svn:// with svn+tunnel://. They have very
> >different security properties. As a user who strongly prefers
> >svn+ssh:// access (partly for ease of setup on the server side, and
> >partly because of the good security properties) , I find this idea of
> >treating non-apache access as a second class citizen very disconcerting.
>
> Blair's original question was related to *public* svn repositories.
OK. But the issue of denying certain clients by software version may
also be applicable to private repositories.
> svn+ssh:// access is morally equivalent to file:/// access, and is, as
> such, a *local* access protocol (since it requires a local account to be
> associated with the ssh key).
No, svn+ssh:// is not morally equivalent to file:// access. It does
not require a local account to be associated with the ssh key.
You can set up svn+ssh:// access in such a way that a different local
account is associated with each ssh key, in which case it probably
would be morally equivalent to file:// access, and most of the easily
discoverable documentation suggests that you do that, but I would
recommend against doing that because of the poor security properties.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by John Peacock <jp...@rowman.com>.
Alan Barrett wrote:
> Please don't conflate svn:// with svn+tunnel://. They have very
> different security properties. As a user who strongly prefers
> svn+ssh:// access (partly for ease of setup on the server side, and
> partly because of the good security properties) , I find this idea of
> treating non-apache access as a second class citizen very disconcerting.
Blair's original question was related to *public* svn repositories.
svn+ssh:// access is morally equivalent to file:/// access, and is, as
such, a *local* access protocol (since it requires a local account to be
associated with the ssh key). Additionally, the svnserve protocol was
never intended (AFAIK) to be 100% feature equivalent to mod_dav_svn, but
rather as a lower-overhead protocol.
This is a very different beast from http:// access, which is designed
specifically to be handled over a public transport method, and to
bootstrap on the existing Apache infrastructure. As much as possible,
it would be prudent to maintain as much comparable features as possible
between http:// and svn://, but there are limitations to the underlying
protocols that may make some things easier and others difficult. As the
main thread has progressed, it is even questionable whether the client
version string is available to mod_dav_svn.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Alan Barrett <ap...@cequrux.com>.
On Mon, 12 Feb 2007, John Peacock wrote:
> Blair Zajac wrote:
> > With mod_dav_svn, I guess we can get the client version string and use
> > that? Would the easy way be to reject commits at the Apache level and
> > parse the client's name?
> >
> > But what about file:/// or svn:// access?
>
> file:/// access is, pretty much by default, not something that you
> would want to allow any sort of public access. svn:// is only
> slightly better, from a security standpoint. I don't think it is
> *too* much of a loss if we only provided a way to block back-rev'd
> client access under Apache.
Please don't conflate svn:// with svn+tunnel://. They have very
different security properties. As a user who strongly prefers
svn+ssh:// access (partly for ease of setup on the server side, and
partly because of the good security properties) , I find this idea of
treating non-apache access as a second class citizen very disconcerting.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Daniel Berlin <db...@dberlin.org>.
On 2/15/07, Roy Franz <ro...@gmail.com> wrote:
> As someone who is looking forward to built-in merge tracking support,
> I think having the technical means to control which client versions
> can commit to the repository is very important. Without it, it will be very
> easy for someone to accidentally use an out of date client, and this could go
> unnoticed for some time. While this could be repaired after the fact,
> I would much rather be able to take steps to prevent that. Without
> being able to enforce
> proper client versions the built-in merge tracking loses much of it's appeal, as
> this is a recipe for having incomplete merge information.
> I won't try to make another analogy about the tags dir, but in my environment
> all tags would be suspect until verified if we didn't have a pre-commit hook.
> Not being able to do similar things to protect the merge information would be
> a big loss.
>
> Roy
>
>
We almost never enforce client versions, but rather, client functionality.
We have provisions to negotiate client functionality in both the http
and svn protocols.
We already do it with svndiff1 support.
There is no reason we can't do it with merge-tracking support and
enable one to deny clients that don't report merge-tracking
capability.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Roy Franz <ro...@gmail.com>.
As someone who is looking forward to built-in merge tracking support,
I think having the technical means to control which client versions
can commit to the repository is very important. Without it, it will be very
easy for someone to accidentally use an out of date client, and this could go
unnoticed for some time. While this could be repaired after the fact,
I would much rather be able to take steps to prevent that. Without
being able to enforce
proper client versions the built-in merge tracking loses much of it's appeal, as
this is a recipe for having incomplete merge information.
I won't try to make another analogy about the tags dir, but in my environment
all tags would be suspect until verified if we didn't have a pre-commit hook.
Not being able to do similar things to protect the merge information would be
a big loss.
Roy
On 2/15/07, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Blair Zajac]
> > Malcolm Rowe wrote:
> > >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.
>
> That's a poor example, since we're actually talking about people who
> are already trusted in the sense that they have read/write access.
> People who can be kicked out, or fired, if they misbehave. A better
> example would be: "We could have a non-technical policy that certain
> committers are only allowed to commit in certain areas, documented in a
> file like COMMITTERS, and _not_ enforce it with authz."
>
> ---------------------------------------------------------------------
> 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: merge tracking: rejecting commits from svn clients < 1.5
Posted by Peter Samuelson <pe...@p12n.org>.
[Blair Zajac]
> Malcolm Rowe wrote:
> >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.
That's a poor example, since we're actually talking about people who
are already trusted in the sense that they have read/write access.
People who can be kicked out, or fired, if they misbehave. A better
example would be: "We could have a non-technical policy that certain
committers are only allowed to commit in certain areas, documented in a
file like COMMITTERS, and _not_ enforce it with authz."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
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
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by John Szakmeister <jo...@szakmeister.net>.
Malcolm Rowe wrote:
[snip]
> Those two are orthogonal. Do you _really_ need the technical part if
> you've already established a non-technical policy?
Anyone who has had to manage a large team of devs will tell you that a
non-technical policy isn't enough, especially when it comes to tools.
You need to enforce it technically. Besides that, people make mistakes,
and a technical enforcement measure would stop it from becoming a larger
problem.
FWIW, I'd like to see this feature. And we use svnserve, since I got
tired of building Apache 2 (plus all of the modules we used), and
dealing with the authentication breakage in neon with respect to
Kerberos and AD. Plus, svnserve is just plain fast.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Malcolm Rowe <ma...@farside.org.uk>.
(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
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Erik Huelsmann <eh...@gmail.com>.
Sorry to top post here, but:
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? Can't we do the same trick on the file:// and server
levels?
What we did (I think): access the repository with the any current
format. When locking is requested: create the locks table and replace
the format file with a specific number. Older clients now can't access
the repository anymore, which is exactly what we want.
I think the same could apply here: as long as there hasn't been any
merge-tracking done on the repository, it's fine to allow all clients
access. After merge tracking has been introduced, older clients should
be rejected on a libsvn_fs_* level. We can do that with the right
format number.
bye,
Erik.
On 2/14/07, Daniel Rall <dl...@collab.net> wrote:
> On Wed, 14 Feb 2007, Blair Zajac wrote:
>
> > Malcolm Rowe wrote:
> ...
> > >But, really, what are we trying to fix here? The problems caused by
> > >someone committing using a non-merge-tracking client? Assuming you have
> > >any kind of post-commit review, you should spot the problem immediately.
> >
> > That's assuming you have a well run organization. I am aware of larger
> > organizations where many people don't know how to use svn well or where
> > there aren't reviews and then only after the fact, do you have to clean
> > up. I would rather be safe than sorry. Better some up front work than
> > clean up a mess later.
>
> Indeed. I share Blair's concerns here. I know this will be a
> complaint from my customer base.
>
> > >Even if not, once you've spotted the problem (I'm assuming the symptoms
> > >would typically be a repeated merge, so you'd probably get a conflict
> > >merging to the branch), you can just fix it using the 'svn merge'
> > >equivalent of svnmerge.py's --record-only option.
> > >
> > >You can also tell people "Don't do that". I find that frequently works
> > >a lot better than constructing a technical solution.
> >
> > Again, work after things are messed up. I would rather just have an
> > easy solution that I don't have to think about it later.
> >
> > 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.
>
> Well, Kamesh pointed out that it is actually quite hard. How can the
> repository differentiate "normal"-commit vs. commit-of-merge?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Wed, 14 Feb 2007, Blair Zajac wrote:
>
>> Malcolm Rowe wrote:
> ...
>>> Even if not, once you've spotted the problem (I'm assuming the symptoms
>>> would typically be a repeated merge, so you'd probably get a conflict
>>> merging to the branch), you can just fix it using the 'svn merge'
>>> equivalent of svnmerge.py's --record-only option.
>>>
>>> You can also tell people "Don't do that". I find that frequently works
>>> a lot better than constructing a technical solution.
>> Again, work after things are messed up. I would rather just have an
>> easy solution that I don't have to think about it later.
>>
>> 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.
>
> Well, Kamesh pointed out that it is actually quite hard. How can the
> repository differentiate "normal"-commit vs. commit-of-merge?
I don't care to distinguish the two.
I would just rather have a way to exclude any clients that don't provide
merge tracking support rather than distinguish between a normal-merge vs
a commit-of-merge.
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.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 14 Feb 2007, Blair Zajac wrote:
> Malcolm Rowe wrote:
...
> >But, really, what are we trying to fix here? The problems caused by
> >someone committing using a non-merge-tracking client? Assuming you have
> >any kind of post-commit review, you should spot the problem immediately.
>
> That's assuming you have a well run organization. I am aware of larger
> organizations where many people don't know how to use svn well or where
> there aren't reviews and then only after the fact, do you have to clean
> up. I would rather be safe than sorry. Better some up front work than
> clean up a mess later.
Indeed. I share Blair's concerns here. I know this will be a
complaint from my customer base.
> >Even if not, once you've spotted the problem (I'm assuming the symptoms
> >would typically be a repeated merge, so you'd probably get a conflict
> >merging to the branch), you can just fix it using the 'svn merge'
> >equivalent of svnmerge.py's --record-only option.
> >
> >You can also tell people "Don't do that". I find that frequently works
> >a lot better than constructing a technical solution.
>
> Again, work after things are messed up. I would rather just have an
> easy solution that I don't have to think about it later.
>
> 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.
Well, Kamesh pointed out that it is actually quite hard. How can the
repository differentiate "normal"-commit vs. commit-of-merge?
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Malcolm Rowe wrote:
> On Tue, Feb 13, 2007 at 11:58:07AM -0800, Blair Zajac wrote:
>> I think we would still want to force a way for a pre-commit script to
>> reject a client using file:///.
>>
>
> 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. Clearly, you would want to use svn:// or
http:// to be safer, but there are some shops that go with file:///.
> But, really, what are we trying to fix here? The problems caused by
> someone committing using a non-merge-tracking client? Assuming you have
> any kind of post-commit review, you should spot the problem immediately.
That's assuming you have a well run organization. I am aware of larger
organizations where many people don't know how to use svn well or where
there aren't reviews and then only after the fact, do you have to clean
up. I would rather be safe than sorry. Better some up front work than
clean up a mess later.
> Even if not, once you've spotted the problem (I'm assuming the symptoms
> would typically be a repeated merge, so you'd probably get a conflict
> merging to the branch), you can just fix it using the 'svn merge'
> equivalent of svnmerge.py's --record-only option.
>
> You can also tell people "Don't do that". I find that frequently works
> a lot better than constructing a technical solution.
Again, work after things are messed up. I would rather just have an
easy solution that I don't have to think about it later.
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.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Feb 13, 2007 at 11:58:07AM -0800, Blair Zajac wrote:
> I think we would still want to force a way for a pre-commit script to
> reject a client using file:///.
>
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.
But, really, what are we trying to fix here? The problems caused by
someone committing using a non-merge-tracking client? Assuming you have
any kind of post-commit review, you should spot the problem immediately.
Even if not, once you've spotted the problem (I'm assuming the symptoms
would typically be a repeated merge, so you'd probably get a conflict
merging to the branch), you can just fix it using the 'svn merge'
equivalent of svnmerge.py's --record-only option.
You can also tell people "Don't do that". I find that frequently works
a lot better than constructing a technical solution.
Regards,
Malcolm
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
John Peacock wrote:
> Blair Zajac wrote:
>> With mod_dav_svn, I guess we can get the client version string and use
>> that? Would the easy way be to reject commits at the Apache level and
>> parse the client's name?
>>
>> But what about file:/// or svn:// access?
>
> file:/// access is, pretty much by default, not something that you would want to
> allow any sort of public access. svn:// is only slightly better, from a
> security standpoint. I don't think it is *too* much of a loss if we only
> provided a way to block back-rev'd client access under Apache.
>
> My 2 cents...
>
> John
>
I think we would still want to force a way for a pre-commit script to
reject a client using file:///.
I'm aware of a number of shops that set up a fsfs repository on a
Windows share and you can never tell when somebody will interact with
the repository with an older client.
So maybe the way of indicating to the client is to set a
SVN_CLIENT_CAPABILITIES environmental variable to a comma separated list
or however HTTP formats capabilities to clients to be consistent. A svn
1.5 client using file:/// would set this before running the start-commit
and pre-commit hooks. That way you could easily write a test:
echo $SVN_CLIENT_CAPABILITIES | grep merge-tracking >/dev/null
if test "$?" -ne 0; then
echo "Your Subversion client needs merge tracking support" 1>&2
exit 1
fi
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge tracking: rejecting commits from svn clients < 1.5
Posted by John Peacock <jp...@rowman.com>.
Blair Zajac wrote:
> With mod_dav_svn, I guess we can get the client version string and use
> that? Would the easy way be to reject commits at the Apache level and
> parse the client's name?
>
> But what about file:/// or svn:// access?
file:/// access is, pretty much by default, not something that you would want to
allow any sort of public access. svn:// is only slightly better, from a
security standpoint. I don't think it is *too* much of a loss if we only
provided a way to block back-rev'd client access under Apache.
My 2 cents...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org