[Zope3-dev] Security: Do not compare symbolic constants with persistent data using "is"

[Steve Alexander]

Casey Duncan wrote:
> That was a good catch. I think the original idea was
> that these constants might eventually be objects that
> also represent booleans or somesuch.

If they are to be objects, then their classes would need to collaborate 
with the pickling machinery to make sure they remained singletons.

There's a hook in the Java serialization protocol for this. I think it's 
called "replaceObject" or something like that. Basically, when 
unserializing, you need to replace a copy of an object of a singleton 
class with the canonical singleton object for your particular runtime.


They could possibly be classes, with new-style class methods or static 
methods to do any work they need to do. IIRC, these would be serialized 
by fully-qualified class-name, and so there would still be only one 
class on unpickling. Thus, they could be compared by identity.


The simple approach where we could still compare by identity is to make 
the values of the constants numbers.

Here's a summary:

Strings:
   compare by equality
   simple implementation
   risk: must never compare by identity
   can't attach extra behaviour to constants

Numbers:
   compare by equality or identity
   simple implementation
   can't attach extra behaviour to constants

Classes:
   compare by equality or identity
   more complex implementation
   can attach extra behaviour to constants


I'm begining to like the sound of using classes for these constants.
I'll do a couple of experiments, to see if my assumptions about classes 
and pickling are correct.

--
Steve Alexander