[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Input Validation in Functions

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 08 Mar 2013 09:46:41 +0100

On 08.03.2013 09:23, Ben Reser wrote:
> On Thu, Mar 7, 2013 at 11:47 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> Tend to agree but I'd restrict such checking to the APIs we consider
>> "public" -- regardless of whether or not they're exposed in the public
>> headers or not. Doing such checks in every layer is definitely overkill.
> I'd like to agree but the way our APIs are layered and actually used
> is not conducive to this.
> Case in point...
>> Furthermore, while your patch proposes checks on the FS vtable level, I
>> believe servers are supposed to use the svn_repos APIs and it would
>> therefore make sense to make those bullet-proof (svn_fs should only be
>> used directly by the admin utilities).
> Yes the servers are supposed to be using svn_repos APIs. However,
> they end up needing to use svn_fs APIs because the repos layer
> provides an svn_fs_t and some of the features of the the libsvn_fs
> layer are not provided via the repos layer. E.G. it's impossible to
> retrieve the text of a file with libsvn_repos.

Yes, I know. :(
I keep thinking we never should have invented a separate svn_repos layer
with wrappers for 80% of svn_fs. But that's crying over spilt milk.

> We could go through and figure out which bits of the various layers
> are used by the servers. But I'm not sure how much work that would
> actually be.

A lot.

So current candidates are svn_repos and svn_fs; but what about the
varioius svn_subr API groups? Retrofitting parameter checks all over the
place there seems like quite a bit of extra work, too.

-- Brane

Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-03-08 09:47:19 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.