[Zope-dev] Zope 4 publisher/traversal, sprint topic

[Leonardo Rochael Almeida]

Hi,

Sorry for the cross-post, but I'd like to talk about a possible sprint
topic for the next DZUG sprint[1], and invite myself to it :-)

After the last two rather serious security issues that were recently
patched in the Zope2 code base, it is increasingly clear to me that,
differently than what Hanno reported some time ago, it's not so much
the ZMI that represents a huge security liability in the Zope
codebase, but it's actually the way the current publisher happily
traverses any attribute and publishes any method with docstring by
default.

The ZMI, of course, has its problems (ugly in appearance and even
uglier in code), and I agree with Hanno on most everything he has to
say about it, but I'd like to propose we start, for Zope 4, by
tackling the potential security liability that is the Zope publisher
itself, and the fact that it makes it easy to open up large security
holes if you're not paying attention.

I'd like to propose that publishing traversal in Zope 4 would, by
default only traverse based on __getitem__ (not attribute lookup). For
a minimum of backward compatibility, it could perhaps do a single
traversal on getattr, and only after it has exhausted __getitem__
traversal.

After this, if the traversal found something, it would only be
published if there is an explicit indication of intention that the
object in question is supposed to be published. Otherwise, raise a
NotFound, as if the traversal had failed.

One example of an explicit demonstration of intent is, for example, if
it provides an IPublishable interface (I just made that up, other
names can be considered).

Taking a suggestion from Shane, we could have convenient decorators
for people who wants to explicitly publish class methods. They could
dynamically create ZTK views with the same name as the function that
they wrap and allow (or perhaps enable by default) some form of CSRF
protection.

To ease code migration, we could consider that the InitializeClass
call provides the same effect as the above decorator. This would allow
large amounts of previously existing code to work without recoding,
while at the same time avoiding the security trap of forgetting to
call InitializeClass and thus exposing unintented methods. It could
even remove the need for the "single getattr traversal" compatibility
above.

On top of that, if InitializeClass register these views to a specific
ZTK "skin", it would make it possible to disable them by default,
unless that specific skin is in effect, which would alleviate what
Hanno described as "running phpMyAdmin accessible to the world with
the same credentials and on the same domain as the rest of your
application".

Anyway, I think the above is on-topic for the next DZUG sprint and I'd
like to work on it there.

So, even if the sprint is supposed to be in German, and I don't speak
a word of it, can I attend?

[1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi
, translation at:
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi

Cheers,

Leo