[Zope-dev] Zope 4 publisher/traversal, sprint topic
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=ensl=autotl=enu=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 )
Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
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=ensl=autotl=enu=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 )
Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
On Oct 27, 2011, at 16:07 , Lennart Regebro wrote: Do we really have to call it Zope 4? :-) Yes. jens ___ 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] Zope 4?
I saw Zope 4 mentioned in public today. This is the first time I'd seen it mentioned in public. Is there a more formal announcement anywhere? Is there a description of what it is envisioned to be? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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 )
Re: [Zope-dev] Zope 4?
On 10/27/11 9:05 AM, Jim Fulton wrote: I saw Zope 4 mentioned in public today. This is the first time I'd seen it mentioned in public. Is there a more formal announcement anywhere? Is there a description of what it is envisioned to be? That came out of this thread on zope-dev back in July: https://mail.zope.org/pipermail/zope-dev/2011-July/043158.html David -- David Glick Web Developer davidgl...@groundwireconsulting.com 206.286.1235x32 Groundwire Consulting is here. http://groundwire.org/about/FAQ-gw-consulting ___ 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 )
Re: [Zope-dev] zope-tests - FAILED: 12, OK: 39
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [1]FAILED ZTK 1.0 / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051738.html This one 404s for me. [2]FAILED ZTK 1.0 / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051782.html The failures here look to be due to binary incompatbility (old Python was UCS4, new one is UCS2) in already-built eggs. Christophe, can you remove any 'py2.6-linux-x86_64' eggs and let them get rebuilt? [3]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051784.html This is the unexpected Data.fs bug in zope/testing/setupstack.txt. 'svn log' suggests that Jim, Fred, and Lennart are best suited to diagnose. ;) [4]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051736.html Ditto. [5]FAILED ZTK 1.1 / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051735.html 404. [6]FAILED ZTK 1.1 / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051781.html Same as #2. [7]FAILED ZTK 1.1 / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051783.html Same as #3. [8]FAILED ZTK 1.1 / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051734.html Same as #3. [9]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051751.html Same as #3. [10] FAILED ZTK 1.1dev / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051749.html 404. [11] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051750.html Same as #3. [12] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-October/051752.html Same failure as yesterday: perhaps it ran before Hanno's pinning fix. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6pimIACgkQ+gerLs4ltQ5eZgCg1ww3wG9CaYW8KQfkH7lZwjPp fYoAoNIi7kL7eHwAzRyUcFbRngdgOeLQ =BCRR -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Zope 4?
On Thu, Oct 27, 2011 at 6:26 PM, David Glick davidgl...@groundwire.org wrote: On 10/27/11 9:05 AM, Jim Fulton wrote: Is there a more formal announcement anywhere? Is there a description of what it is envisioned to be? That came out of this thread on zope-dev back in July: https://mail.zope.org/pipermail/zope-dev/2011-July/043158.html There's no more public announcement, as it's all just work in progress. I made up a bad list of bullet points at: http://docs.zope.org/zope2/releases/4.0/WHATSNEW.html But the gist is: There's no point in doing a Zope 2.14 release with incremental improvements, as there's nothing such a release could contain. So it makes sense to do a less backwards compatible release and bump the major version number. People rightfully complained that doing a Zope2 3.0 release is a bit insane. So the next number up for grasp is Zope2 4.0 - at which point it can be called Zope 4.0 again. Hanno ___ 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 )
Re: [Zope-dev] zope-tests - FAILED: 12, OK: 39
On Thu, Oct 27, 2011 at 6:44 PM, Tres Seaver tsea...@palladion.com wrote: [12] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-October/051752.html Same failure as yesterday: perhaps it ran before Hanno's pinning fix. Yep. There's two green builds for this one now: http://winbot.zope.org/builders/z3c.form_py_265_32 Hanno ___ 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] zope-tests - FAILED: 9, OK: 37
This is the summary for test reports received on the zope-tests list between 2011-10-26 00:00:00 UTC and 2011-10-27 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux [1]Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit [2]ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit [3]ZTK 1.0dev / Python2.6.7 Linux 64bit [4]ZTK 1.1 / Python2.5.5 Linux 64bit [5]ZTK 1.1 / Python2.6.7 Linux 64bit [6]ZTK 1.1 / Python2.7.2 Linux 64bit [7]ZTK 1.1dev / Python2.5.5 Linux 64bit [8]ZTK 1.1dev / Python2.6.7 Linux 64bit [9]ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED Bluebream / Python2.6.7 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-October/051792.html [2]FAILED ZTK 1.0 / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051828.html [3]FAILED ZTK 1.0dev / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051799.html [4]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051830.html [5]FAILED ZTK 1.1 / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051827.html [6]FAILED ZTK 1.1 / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051829.html [7]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051798.html [8]FAILED ZTK 1.1dev / Python2.6.7 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051790.html [9]FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-October/051797.html ___ 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 )
