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!
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.
- application/pgp-signature attachment: stored
Received on Tue Oct 23 22:58:17 2007