On Mon, 2008-06-16 at 14:34 +0200, Vincent Lefevre wrote:
> On 2008-06-13 18:43:23 +0100, Julian Foad wrote:
> > The CHANGE from current behaviour to new behaviour when this macro is
> > substituted for current uses of assert() (in places where it can be
> > substituted without further changes) is:
> >
> > * if a bug is encountered that triggers one of these assertions,
> > the program will now stop through Subversion's error reporting
> > mechanism instead of by aborting, except that:
> >
> > * in cases where the software is designed to catch svn_error_t
> > error objects, it may now ignore the error or do something other
> > than the default of reporting the error and stopping.
>
> How about the security point of view? The failed assertion could come
> from some memory corruption (e.g. after a buffer overflow, possibly
Of course any behaviour at all could come from some memory corruption.
Is corruption particularly likely to be picked up by assertions compared
to by other tests? Maybe.
> due to data from a malicious user). In such a case, aborting ASAP
> would be a better solution than having the risk to let the software
> behave erratically.
Do you mean in the case of corruption caused by a malicious user? Yes,
you might well be right, but that condition is impossible to distinguish
programmatically so it's a moot point.
However, most assertions catch bugs that are not serious security holes.
Many developers agree that it is not best for all assertions in the
libraries to abort ASAP without any way for a program to handle them its
own way.
I think your concern is perhaps that higher-level code might ignore
assertions unintentionally or without due consideration. The answer here
is to help higher level code to do the right thing. For instance, we
could make the standard error-ignoring mechanisms like
"svn_error_clear(svn_error_t *err)" NOT ignore assertions, and provide a
separate "svn_assertion_clear(svn_error_t *err) for those few cases
where code needs to handle assertions in a special way.
Does that approach address your concerns?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-16 17:17:23 CEST