Do we really have to call it Zope 4? :-)
On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida <leona...@nexedi.com> 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] 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 > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )