[z3-five] Re: Todo list discussion

[Philipp von Weitershausen]

Martijn Faassen wrote:
> No argument with any of these; these all sound good. The boilerplate one 
> sounds like the most involved project.
> 
> We should also partition these by 'release'. For 0.1, the upcoming 
> release (hopefully later this week, I think we should be doing):
> 
> - make five:viewable support being called several times
> 
> - support existing __bobo_traverse__methods.
> 
> These should be fairly easy to implement. We'll do the other stuff later.

+1. We should put this 'partitioning' of todo items in the todo list...

> secure page templates
> =====================
> 
> What does this mean?

I don't know exactly; I'm not too good about security, especially Zope2 
security. I just remember you saying that page templates within Five run 
"insecurely fast".

> Page templates which fail if they call a method 
> that is protected? There was actually a lament on the Zope mailing list 
> that this is wrong (Zope 2 does this, but python methods don't have this):
> 
> http://mail.zope.org/pipermail/zope-dev/2004-March/022094.html
> 
> And a post by Shane Hathaway on it:
> 
> http://mail.zope.org/pipermail/zope-dev/2004-March/022104.html
> 
> In particular:
> 
> """
> Jamie Heilman wrote:
>  > Paradoxically, by ignoring Zope's security framework in the context of
>  > on-disk methods this actually improves Zope's overall security.
> 
> I can see that.  It's interesting that when security is burdensome, it
> is often less secure overall as a result.  I see this pattern everywhere.
> """
> 
> In this thread I argued it should be an option to have the checks turned 
> on, but I've become less convinced as time passes. The only thing such 
> checks do is catch bugs in your code; if your page template is somehow 
> dependent on user permissions, there always is an explicit check hiding 
> out in your code anyway.
> 
> There's also a whole new Zope product, TrustedExecutables, which claims:
> 
> "As Zope's security checks are expensive, avoiding them can
> drastically speed things up."
> 
> So, while I wouldn't be against optionally turning this on (perhaps 
> during development mode), I'd suggest we actually already have the right 
> system right now. :)

So, to let me understand this:

- Zope 2 Page Templates, like PythonScripts, are bound so that 
everything they want to do is subject to not only expensive but also 
very restricting security checks. DTML ignores that which seems not only 
be more secure in the end, but also less error-prone and faster.

- Zope 3 Page Templates, like any other component in Zope3, doesn't do 
explicit security checks; instead, it deals with other objects as usual; 
however, security is still enforced in 'untrusted' environments, e.g. 
when objects are retrieved during a user interaction that acts with a 
certain legimitacy. These objects are security wrapped; these security 
checkers perform checks, but nearly transparently.

- In Five, we feed Zope 2 objects (which are not security wrapped) to 
Zope 3 Page Templates. That means once the Page Template is executed, 
neither the Page Template, nor some security proxies nor the objects 
themselves will perform security checks. This doesn't matter to us since 
we protect the overall Page Template with a permission, e.g. in the 
<browser:page> ZCML directive.

If that last statement is correct, why would Zope 3 need security proxies?

> now that we have zope:content, do we still need five:implements?
> =================================================================
> 
> I don't know either. The nice thing about five:implements that is it 
> short and to the point. zope:content is a bit more involved (you can 
> also do security related stuff) and implies you only do this for content 
> classes (even though it works for anything). There's also zope:class 
> which does the same but can be used with everything.
> 
> In any case, five:implements doesn't do a lot of harm; perhaps we can 
> introduce a zope:implements into Zope 3? :)

Not into Zope X3.0 whose API has already been frozen. But it'd be worth 
a shot; I wonder about good use-cases though...

Philipp