On Mon, Oct 04, 2004 at 08:47:33PM -0400, Mark Phippard wrote:
> Yes, it is "that bad". Read what Tobias posted when he began this thread:
>
> -- quote
> The security fixes introduced in 1.0.8 and 1.1.0-rc4 made RA->get_dir
> (and therefore "svn ls") over ra_dav "glacially slow" (as someone
> described it on users@). For a simple test case of mine, an ls of 412
> files that used to take 1.5 s now took around six minutes, i.e. it's 240
> times slower, but it could be a lot slower still depending on the
> circumstances. This is a showstopper performance regression for many
> users.
> -- end quote
Well what he said is a long way from calling the software unusable.
Yeah 6 minutes sucks. But if not many users are affected it's not as
big of a deal. However, it sounds like TSVN makes more use of the ls
command than command line client users do.
> Why did 1.1 "get out"? Well, how long was RC4 soaked?
1 week as per HACKING.
> Also, when RC4 was created it was well known that 1.1 release was
> coming soon. So "users", like myself, just waited for the release.
Well just waiting is a good way of ensuring that bugs that are
exceedingly annoying to you end up getting in a release. A lot of us
use the software, but most of the developers don't really use the ls
command. Not trying to lay blame here. Just pointing out that if we're
going to shorten the soak time (which we did becasue many people felt a
month was too long), users who care about having clean releases need to
be proactive in testing the release for features that matter to them.
> > We don't consider DoS issues security issues. We had a long debate
> > about this on the security list. It'll always be possible to DoS a
> > machine because the machine has limited resources...
>
> Wasn't one of the first security patches in the 1.0.x release to fix a
> potential DoS
> in svnserve?
1.0.3 and 1.0.5 both used the term DoS in their vulnerability
assessment. But in both cases that was the best case scenario of
someone taking advantage of the vulnerability. In both cases Arbitrary
Code Execution was a possibility.
However, we have just fixed issues where it was possible to crash the
server without calling it a security release. E.G. r10478 which was
included in 1.0.7.
> Fair enough, but in hindsight this was probably a faulty patch for the
> security problem. Yes, it fixed it, but it introduced a major
> performance regression.
Faulty is a bit strong. Overzealous is more correct. It does indeed do
what it was intended to. But it went too far. Some of that can
probably be attributed to a *LOT* of discussion about exactly what the
code ought to or ought not be protecting. There were some people that
felt the author and date should be protected as well. If the policy had
been decided that way the patch would have had a performance regression
that couldn't be resolved.
> Personally, I have no objection to a 2 week wait for a 1.1.1, but it
> would be nice to see some "momentum" pick up around organizing that
> release. That is, assuming the reason to wait is to get some other
> patches into the release, perhaps some kind of call to start
> nominating those patches could begin soon so that you have time to
> gather the necessary review and votes in STATUS?
Well the biggest thing that needs to be done is someone needs to go
through the issue tracker and milestone the issues for the 1.1.1
release. Usually one of the Chicago guys does that. But I think
they're busy doing other things. So someone else probably needs to
pickup the ball. Unfortunately, I'm also somewhat busy right now.
As far as the 1.0.9 release, we need to get people to move on reviewing
the patch. I suppose I'll have to set a date and chase people to bother
to review it if nobody does by the time the day for the release comes
up.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 5 04:43:29 2004