Do we really have to call it Zope 4? :-)

On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida
<> wrote:
> 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]
> , translation at:
> Cheers,
> Leo
> _______________________________________________
> Zope-Dev maillist  -
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to