[Zope-dev] Request For Comments: SecurityJihad

[Casey Duncan]

"Michael R. Bernstein" wrote:
> 
> If your class *depended* on some of the magic behavior such as
> docstrings making unprotected objects publishable or traversable, then
> that behavour would break, unless you also added
> security.docstringsMakeObjectsPublishable("yes").

Changing that behavior (which admittedly is unintuitive if not worse),
would break the vast majority of existing products. Why not go the other
direction and make it so new products must subclass a new base class
"DamnSecure" or somesuch that the ZPublisher looks for in order to alter
that behavior (and others gracefully). Products that do not use this
base class would cause a security warning to be outputted to the console
and/or logs. 

I'm not so much concerned about product authors, as I am the poor users
who would be trying to use old versions of products (and those not yet
or ever updated from Zope.org). I will guarantee a 1000% increase in
mailing list traffic of the nature "I upgraded to Zope 2.5 and I'm
hosed!" if some semblance of backward compatibility (with warnings)
isn't kept.

> In fact, switching to the new base classes would be unneccessary in this
> case, as mostly what they do is not mess up the 'deny unless allowed'
> policy, like Item and SimpleItem do.
> 
> So, if you switched to the new base classes, you could then eliminate
> security.setDefaultAccess("deny") from your class, but otherwise there
> would be no other change.

I could certainly live with that.

> 
> Michael Bernstein.
> 

I certainly think this proposal is a very good one. As you pointed out,
you have know alot about what specific mix-ins do to security to create
a secure product. It should take effort to create an insecure product,
not the other way around.

-- 
| Casey Duncan
| Kaivo, Inc.
| cduncan@kaivo.com
`------------------>