[Twisted-Python] Re: More on PB Copyable Errors

Justin Johnson 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
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>




More information about the Twisted-Python mailing list