Re: assert() vs. return(error)

[Stuart Celarier]
> But, hey, at least an assert is limited to just bringing the server
> down. Not validating input to any API can presents a range of other
> threats to the system.

I think you're confused about Subversion's architecture. From your
comments, you seem to be assuming an RPC (remote procedure call)
architecture, where the client "calls" the server's "functions"
directly (from a coding standpoing). If that were the case, and the
server functions were not validating client input, your concerns would
be justified.

In reality, Subversion uses a client/server architecture with explicit
network protocol handling (that is, the protocol marshalling is done in
Subversion libraries, not in some third-party RPC structure). The
network protocol is treated as a security boundary - not as a simple
API call. So the server validates the client's input, and everyone
agrees that this is necessary. If a client can crash a server or make
it malfunction, that's considered a serious bug.

> I see it from a different perspective. A failed assert causes the
> server to call abort. That allows one user to deny service from all
> users and all repositories on the server.

Only if bad input from a client can directly cause an assert on the
server. This should never happen. Asserts in the server code should
be triggered by genuine server bugs, not by client bugs (or malicious
clients).

Since those same server bugs could also cause data loss or data
corruption, as alternatives to an outright crash, it seems to me that
you're better off getting your ulcers worrying about the postulated
existence of the bugs themselves, rather than worrying about the abends
they may cause.