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?
Blair
---------------------------------------------------------------------
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:12:33 2007