[Twisted-Python] Re: More on PB Copyable Errors
justinjohnson at gmail.com
Wed Dec 29 14:47:48 EST 2004
Thanks for the reply.
In my testing it seemed that I would get an InsecureJelly error on the
sending side if I tried to send back an object that I hadn't called
pb.setUnjellyableForClass on the sending side for. In other words,
calling setUnjellyableForClass on the sending side was a way of saying
that it was okay to send over the wire, and also a way of registering
what class to use when unjellying it if it were received.
Is this not correct?
On 29 Dec 2004 14:15:57 -0500, David Bolen <db3l at fitlinxx.com> wrote:
> Justin Johnson <justinjohnson at gmail.com> writes:
> > Attached is a patch with modifications to pb.py and jelly.py. With
> > the patch applied, CopyableFailure.getStateToCopy first checks to see
> > if the actual exception instance's class has an unjellyable registered
> > so it can be unjellied on the other side. If it does, the actual
> > exception instance is passed back as failure.value. Otherwise a
> > string representation is passed back as it is today.
> I think the one big risk with this approach is that I'm not sure a
> sender can ever know accurately whether a recipient will be able to
> unjelly a particular instance. In your case, you're assuming the two
> sides are symmetrical and have imported the same definitions, but that
> need not be the case. At least in general, it's certainly possible
> for the transmitting side to not have the unjellier registered (if it
> never expects to receive such objects back, for example). Or
> conversely, the sender may have an unjellier registered but the
> recipient won't. In this latter case you'd get an exception on the
> remote side which sending the string would have avoided.
> One alternative approach to handle this is to transmit both the string
> and instance representation, and then let the decoding side trap any
> unjellier security exceptions and fall back to the string
> representation. The big question of course is whether such a fallback
> should be automatic, silent, etc..
> Another option would be to provide some sort of configurability
> (perhaps something along the lines of how unsafe traceback support is
> handled) so an application could make the choice of what mode to
> operate in, either string names, or full instances (and the latter
> just has to have unjelliers registered just as for any other remotes).
> I'm sort of in the same state you are in, in that for me the simplest
> approach is just transmit the instance because my two sides are in
> fact symmetric. So the short internal change to local source works
> fine for me too. But I think that any general addition to the twisted
> base needs to take the more general proposition (and issues) into account.
> -- David
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python