On 10/23/07, Blair Zajac <blair@orcaware.com> wrote:
> Daniel Rall wrote:
> > On Tue, 23 Oct 2007, Blair Zajac wrote:
> >
> >> Daniel Rall wrote:
> >>> On Tue, 23 Oct 2007, C. Michael Pilato wrote:
> >>>
> >>>> Blair Zajac wrote:
> >>>>> As somebody who runs an svn server for open source code and one for
> >>>>> internal corporate use, I want to ensure that all svn clients that
> >>>>> commit send merge info to the server and I don't want to loose this
> >>>>> information. So I want to require that all clients that commit are at
> >>>>> least Subversion 1.5 or later. I can imagine that lots of corporate
> >>>>> shops will want this requirement to prevent somebody from using some
> >>>>> random svn client that does not supply merge info and makes life harder
> >>>>> for a release manager.
> >>>>>
> >>>>> Are we planning on offering such a capability? If so, how are we doing
> >>>>> this? If not, this seems like a good use for the start-commit script to
> >>>>> supply an additional parameter, say an $OPTIONS, that can be parsed for
> >>>>> the support the client offers.
> >>>> This was brought up to me personally at SubConf last week as a fairly
> >>>> serious issue in corporate environments. It was the first I could recall
> >>>> of
> >>>> hearing such a concern, but here you are echoing it. So, while I don't
> >>>> yet
> >>>> have a strong position on the matter technically, I do believe we need to
> >>>> have this discussion, and now's as good a time as any to do so.
> >>> Blair actually brought this issue up about a year ago, and the
> >>> consensus was that while it's certainly a valid issue, we currently
> >>> have no reliable way to do this. We simply can't trust the client, so
> >>> can't enforce this with 100% reliability. We can, however, put some
> >>> "guideline" constraints in place (along the lines of the suggestions
> >>> in this thread).
> >> I'm not looking for a 100% reliability. As long as somebody downloads a
> >> well known binary, say Subclipse, our .exe's or TortoiseSVN who will do a
> >> good build, or downloads and compiles from source and doesn't modify the
> >> source, that's good enough for me.
> >>
> >> If somebody wants to take a 1.4 client and have it tell the server it will
> >> send mergeinfo over when it really won't, I'm ok with that. I'm not
> >> looking to solve that problem.
> >
> > Yup, I didn't think you were. It's not the well-informed user base
> > that I'm concerned about. :-)
> >
> >> I'm assuming this is the issue you're talking about?
> >>
> >> What do you mean by guildline constraints? Anything less then a
> >> notification of the client's capabilities to the server won't be sufficient.
> >
> > Mark and I had a little over-the-cube-wall discussion about this. To
> > be painfully clear: I am in favor of this capability announcement!
>
> Ahh, great.
>
> >
> > The point I was trying to make is about how we advertise this
> > behavior.
> >
> > We need to be very clear that we're _not doing access control_ here,
> > so those looking for guaranteed protection from malicious users
> > shouldn't rely on this facility for it. What we're doing is providing
> > a nicety that'll keep 99% of the user base from shooting themselves in
> > the foot, regardless of the fact that we're providing no real
> > security.
>
> Good point. But I wasn't even really thinking about this in a security context,
> just a capability context. Do we want to conflate the two?
>
> Also, should we open a ticket with a 1.5 milestone for this?
If we advertise a way to block clients based on version, and people
can get around it, some people will accept this and others will see it
as a problem. I think Dan is just saying if we add something like
this we probably need to be careful in how we describe it to make it
clear.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 23 23:15:16 2007