Christopher Armstrong <radeex@gmail.com> writes: (...)
Why's that actually a risk? In any case where a PB app uses Copyable and suchlike, that assumption is made. If someone is marking an exception as jellyable, then they know that their clients should also be able to unjelly that exception, and it will be a part of the protocol.
Yeah, that's reasonable. It doesn't cover a desire to transmit system exceptions (e.g., we sometimes reuse ValueError rather than redefining our own version of it), but at worst you'd just need to build a mirror hierarchy for those system exceptions you might reuse. (...)
That's exactly what the patch would do, AIUI. On the server side, you can set unsafeTracebacks if you want tracebacks to be sent to the client. The server side can also set an exception class as jellyable if you want to send exception instances to the client.
Well, the patch is checking the unjelly registry to make the encoding decision on the server side, which I don't think is the same thing as what you're saying. To check for whether the exception was marked as jellyable, it should be checking for a subclass of Jellyable and not looking in the unjelly registry (I think). But yeah, if the patch looked for a Jellyable subclass (which is the same thing the normal _Jellier class does when jellying anything else), I think that would be a reasonable approach. -- David