Re: [Zope-dev] zope-tests - FAILED: 8, OK: 86, UNKNOWN: 4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/06/2011 01:00 AM, Zope tests summarizer wrote: [1]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.5 : Linux https://mail.zope.org/pipermail/zope-tests/2011-April/037287.html [2]UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux https://mail.zope.org/pipermail/zope-tests/2011-April/037288.html Both of these blow up tryiing to install 'argparse==1.2.1' (I don't know why). That release is not uploaded to PyPI, nor is it in the download.zope.org index. [3]UNKNOWN UNKNOWN : winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-April/037312.html [4]UNKNOWN UNKNOWN : winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-April/037313.html Both of these are failures due to 'client disconnected' errors in ZEO tests. I have no clue about them. [5]FAILED Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win https://mail.zope.org/pipermail/zope-tests/2011-April/037266.html This one looks like a timeout during some part of the buildout step: remoteFailed: [Failure instance: Traceback (failure with no frames): class 'twisted.internet.error.ConnectionLost': Connection to the other side was lost in a non-clean fashion. 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/ iEYEARECAAYFAk2cVpAACgkQ+gerLs4ltQ6EwwCgzVxdBQIijHvfpQzMpyioapAD ovsAoJVkCa6TzLaak/R9v6RhoU10NNka =wXQa -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] CSRF protection for z3c.form
Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? Regards Roger Ineichen Laurence ___ 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] CSRF protection for z3c.form
On 4/6/11 7:43 PM, Roger wrote: [..] I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) For that reason both CMF as well as Plone clean user input by stripping nasty tags and such - at least per default. Raphael One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? Regards Roger Ineichen Laurence ___ 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 )
[Zope-dev] Recursive search of dependencies in z3c.autoinclude
Hi, I release z3c.autoinclude with a lot of attributes for directives includeDependencies and includeDependenciesOverrides. Mercurial repository with my fork - https://bitbucket.org/cykooz/z3c.autoinclude. Recursive search of dependencies includeDependencies package=. recursive=True / This looks up and includes all respective ZCML files of packages you declared to depend on in setup.py. This works recursive so that if packages in your setup.py depend on others the latters are looked up too and so on (and everything in the right order). Disabling autoinclude some packages --- includeDependencies package=. recursive=True ignore=zope.app.zcmlfiles ice.control / This not include packages `zope.app.zcmlfiles` and `ice.control`, but include their dependencies. TODO: * Add ability for create autoconfigure.zcml file for decrease startup time. PS: I would be glad if my changes will merge with main branch. ___ 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] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Laurence ___ 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] CSRF protection for z3c.form
Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Ok, it starts making sense to me. What do you think about a class property like we us in fomr classes like ignoreContext, ignoreRequest, ignoreReadonly: ignoreProtection = True/False and set it by default to True? Or even to False and we can simply set it to True if test will fail because of changed form source? Regards Roger Ineichen Laurence ___ 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] CSRF protection for z3c.form
On 6 April 2011 22:24, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Ok, it starts making sense to me. What do you think about a class property like we us in fomr classes like ignoreContext, ignoreRequest, ignoreReadonly: ignoreProtection = True/False and set it by default to True? Or even to False and we can simply set it to True if test will fail because of changed form source? My current thinking is a modification of my first proposal above:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. Laurence ___ 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] CSRF protection for z3c.form
Hi Laurence, Stephan Betreff: Re: [Zope-dev] CSRF protection for z3c.form On Wednesday, April 06, 2011, Laurence Rowe wrote: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. btw, PostOnly and the condition check if self.actions.executedActions: is probably the same. Because if executedActions is False it must be a GET request. right? I like this in combination with Rgoer's ignoreProtection, which should be false by default, because we want to make forms secure by default. It would be great, if we would ship with one non-trivial authenticator and I would love to see an add-on package providing CheckCaptcha. :-) Now it becomes interesting to me and I like it more and more, let me take a closer look and discuss some details... concept naming, if we use an ignoreProtection marker let's rename the method authenticateSubmission to updateProtection which also reflects that the method is apart of the form/update method stack. And let's rename the ISubmissionAuthenticator part to smomething like IFormProtector or so. I do not like the word authentication in this concept. Authoriastion whould probably also make sense at least if captcha is involved which is authorization and not authentication. captcha, CheckCaptcha sounds very interesting and raises some questions to me. I guess if a captcha doesn't fit we need to abort processing actions and return ASAP the plain form again with another captcha. first question, I looks to me that the concept is heavy related to the action conditions. What about if each form action has it's own for protection check? a simple example: - cancel button is allowed without a check (this really will hurt if not possible) - form submit is not allowed without a check second question, should we be able to return something if the updateProtection failes. Probably the updateProtection method should return True/False and if False is returned hookup another method call which could return content ASAP (probably not possible in update stack). Or should we set a marker called like we do in AddForm with _finishedAdd? third question, I guess we should take a closer look to the action condition. It looks to me like we should implement the check closer to the form action condition concept. E.g. an action condition defines if an action get rendered and another new action argument could be called checker. Such a checker method could then check if an action can get executed or not. This whould defently require a marker flag because an action can also not return content. Or we should use a plain python error handling if a checker fails? sidenote, such a checker argument could also be used independent from the page token concept. btw, I still do not understand how the full concept will work. Where is the hook/method which will setup a token? What do you think? Regards Roger Ineichen Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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: 8, OK: 71, UNKNOWN: 4
This is the summary for test reports received on the zope-tests list between 2011-04-05 00:00:00 UTC and 2011-04-06 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 [1]UNKNOWN : Zope-trunk Python-2.6.5 : Linux [2]UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux [3]UNKNOWN : winbot / ZODB_dev py_270_win32 [4]UNKNOWN : winbot / ZODB_dev py_270_win64 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 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 Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13_win-py2.6 slave-win Zope Buildbot / zope2.13_win-py2.7 slave-win Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 [5]Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit_win-py2.5 slave-win Zope Buildbot / zopetoolkit_win-py2.6 slave-win Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.5 : Linux Zope-2.12-alltests Python-2.6.5 : Linux Zope-2.13 Python-2.6.5 : Linux Zope-2.13-alltests Python-2.6.5 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 [6]winbot / z3c.coverage_py_265_32 [7]winbot / z3c.rml_py_265_32 [8]winbot / zc_buildout_dev py_254_win32 [9]winbot / zc_buildout_dev py_265_win32 [10] winbot / zc_buildout_dev py_265_win64 [11] winbot / zc_buildout_dev py_270_win32 [12] winbot / zc_buildout_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_dev py_254_win32 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]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.5 : Linux https://mail.zope.org/pipermail/zope-tests/2011-April/037378.html [2]UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux https://mail.zope.org/pipermail/zope-tests/2011-April/037379.html [3]UNKNOWN UNKNOWN : winbot / ZODB_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-April/037358.html [4]UNKNOWN UNKNOWN : winbot / ZODB_dev py_270_win64
