On 8/7/14 8:50 AM, Stefan Sperling wrote:
> Oh geez... the cobwebs...
>
> I honestly don't recall, but I strongly suspect that it has something to
> do with how the mirroring filters work. These things do essentially a
> global search-and-replace on the request and response bodies and
> headers, transforming strings in requests that look like the path
> portions of the master URL into those that match the path portions of
> the slave URL; vice-versa in responses. And the protocol doesn't speak
> in terms of fully qualified URLs -- within the bodies, it's just the
> path portions. I recall running into problems when asking the C code to
> do a global search and replace of either "" or "/" with something else. :-)
>
> Now, that check I added might be something we could relax iff the slave
> URL's path portion is likewise empty -- meaning you're mapping between
> two server roots. The mirror code does detect the situation where the
> search-and-replace would be a noop (because the strings are identical),
> and avoids filtering at all in such situations. Of course, as you know,
> having matching path portions here is the *only* safe way of using the
> mirroring code at all. Yet, to my knowledge, we still don't require our
> users to set things up that way.
To add to this. I wouldn't ever recommend running Subversion at the
ServerRoot. There are all sorts of edge case bugs that have come up over the
years when doing that. I have no doubt there will be other bugs in the future
related to this. Our test suite does not test this scenario.
For example there was this situation not that long ago:
http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
Received on 2014-08-07 20:24:12 CEST