On Fri, Jul 31, 2009 at 09:41:55AM -0400, Mark Phippard wrote:
> On Fri, Jul 31, 2009 at 8:59 AM, Stefan Sperling<stsp_at_elego.de> wrote:
>
> > Given this, I'd say the best way to make sure we get a fix for this quickly
> > is by providing additional developer resources which focus solely on this
> > problem. I see two ways to do this.
> >
> > One way is providing help if you have capable developers in-house.
> > More contributors are always welcome, and an active and healthy relationship
> > to Subversion's developer community can be beneficial in the long-run
> > for any business, especially if you use Subversion yourself, but also
> > from e.g. a marketing perspective. Don't dismiss the benefits of direct
> > involvement in the development process. Oh, and you also get #3242 fixed.
> >
> > The other way is to offer to fund an existing developer who can't
> > otherwise afford to pick up a task as big as #3242 due to lack of time.
> > That might convince someone already familiar with the code base to work
> > on this. Since a number of users are affected by this, and most of them
> > seem to be corporate users, funding could probably be pooled with some
> > coordination between affected parties. The Subversion Corporation
> > (http://www.subversion.org) would be the appropriate contact at our end.
>
> Someone should not have fund development to get a bug fix for a
> regression that impacts almost all our users. I realize you are not
> suggesting that, but it could be interpreted that way.
I did not mean to suggest that people would have to provide funding
or else this bug will never get fixed.
It's just that it will be fixed quicker if we get resources channelled
towards this problem. I was suggesting two possible ways to achieve this.
> Mike Pilato has raised this twice in the past:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1304305
>
> http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=2356771&dsForumId=462
Yes. I am basing my understanding of the problem on those threads.
> The problem as I see it is that the solution has become tricky. And
> the right answer potentially involves changing our authz behavior.
That's what I see it as, too.
> What we need is to get some people to respond to those threads and
> issues to see if we can reach some consensus on whether it is OK to
> make those changes. If not, then Mike lays out what needs to be done,
> which sounds fairly difficult to program.
I trust Mike in his judgement. I could not find any flaws in his
reasoning. But then again I'm not an authz expert.
To me, it looks like we don't need to wait for getting consensus.
Rather, we need someone who can spend the time to do the necessary
work to implement the solution that Mike has already started to
formulate.
One thing Mike had concerns about was that his solution would leak
information about the existence of sibling nodes all the way at
every parent directory of a path protected by authz.
I think with a "you may know that parent exists" policy, this problem
is not avoidable and people should design their directory hierarchies
appropriately if they have a problem with leaking information about siblings.
Consider this directory tree:
/--+
|
|
+-- secret/...
|
+-- pub/--+
|
|
+-- dir1/...
Someone with authz access to pub/dir1/ will be able to know about
the existence of the directory secret/ but will not be able to know
about anything inside of this directory. Correct?
If so, I don't think there is a huge problem. Just put highly
sensitive data into secret/sensitive/ and you're done.
> In short, this has not been fixed because there is no quick and obvious fix.
Precisely. Which is why we need more developers to look at this.
Which is a problem because right now everyone is pretty busy with
other stuff already.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2380004
Received on 2009-08-04 15:54:35 CEST