Mark Phippard wrote:
>>>our compile to remove the assert(). Is this the
>>>wrong thing to be doing?
>>>
>>>
>>>
>>>
>>I'd say so, yes.
>>
>>
>
>I think it is a pretty tough decision. I do not like the idea that anyone
>could so easily just bring down a server. How is that different than a
>DoS? Would it be outside the realm of possibility for the server to just
>terminate the conversation in this situation, as opposed to aborting? Is
>the error just too deep in the Subversion library to percolate back up to
>the level that would need to do that?
>
>
Maybe I should have said this differently. The assert isn't the cause of
the bug, it's a symptom. There is a bug on the client side, which causes
it to send paths to the server that we document as invalid. There's also
a bug on the server, which should be checking untrusted input. But there
is no bug in svn_path_remove_component (<hedge>at least, aborting on
invalid parameters is not a bug...</hedge>)..
>FWIW, the latest Subclipse version does not do this, but the older
>version, which you have to use with IBM's WSAD 5.x, does.
>
>
Very good, that means at least one of the bugs is no longer in the
mainline. The bug in svnserve remains, and should be fixed -- but not by
disabling asserts.
BTW, it seems that the latest versions of MSVCRT.dll do contain runtime
support for assert. So I'm about to remove NDEBUG from our Win32 build
scripts (excepth the APR wrappers for VS.NET).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 22:34:43 2004