SteveKing wrote:
> On Tue, 08 Feb 2005 10:12:58 +0000, Will Dean <svn@indcomp.co.uk> wrote:
>
>
>>I'm not overjoyed about some of the changes in 2634, particularly the
>>wrapping of code in SVNFolderStatus in a catch(...) block.
>>
>>The response from the cache (after the pointer fix-up which occurs in
>>RemoteCacheLink) should be consistent, and shouldn't have broken data in it.
>
>
> As you say: _shoud_ be consistent! But you can't be sure here. And I'd
> rather have a catch block around such code than have the shell crash.
> Also, you must consider the data coming from another application than
> our own (e.g. a 'bad' program trying to do some nasty things).
If you are worried about this, a catch(...) doesn't
really help-- it only catches bad programs that screw
up trying to do nasty things.
The bad programs that successfully do nasty things
don't crash (or at least they don't crash until after
the nasty things are done.)
>>If we feel we need to be defensive about data coming in from the cache (I
>>don't think we do, actually), then I think we should validate it in
>>RemoteCacheLink, and not just munge around it with catch(...) blocks in the
>>code which uses the data.
>
> That may be better, yes.
I think this (data validation) is the only way you can protect
against bad programs trying to do nasty things. (Though to
be honest, if someone has control over the cache program, I'm
not sure what additional 'bad things' they can accomplish by
taking control of the shell.
BTW, this uses named pipes, right? (It seems like that was the
mechanism mentioned, but I don't recall for sure.)
Who is the listener, the shell or cache?
And what happens if it gets a connection attempt from a
remote client?
This might be a reason you need to worry about bad data.
I.e., if machine A is compromised, there are additional
bad things to be done by compromising machine B (by
connecting to the TSVN cache pipe and sending garbage.)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 8 17:05:53 2005