On Thursday 13 March 2003 5:21 am, Shane Hathaway wrote:
The only vulnerability would involve trusted users who want to vandalize Zope. So even though there have been many hotfixes, they are irrelevant--Zope is still secure. (Unless you can't trust your trusted users, which is a different problem.)
Of course you cant *completely* trust your trusted users. Thats why we have seperate user accounts, and seperate roles. IMO: Zope is sufficiently vulnerable to abuse from trusted users to justify concern. The normal zope development model is to consider normal python code as trusted - normal python code can do anything without security checks. Zope has many normal python methods that can be called by through-the-web code (after permission checking). In unix terms this is equivalent to having many setuid root programs. IMO concern can be justified without needing to find a specific exploit. From this point of view, Jamies advocacy of using Unix mechanisms to restrict this 'trusted' python code is valuable. On Thursday 13 March 2003 1:58 am, Jamie Heilman wrote:
I will go on record as saying that, recently, response times to security related issues in the Zope2 tree have been disapointing. Construe from that what you will.
It is hard to find time for security work among the feature rush of the cvs trunk, and without compromising the stability of the maintenance branch. Would there be any interest from other developers in addressing these potential security issues in a *fork* starting with the 2.6 maintenance branch? (reply-to set to zope-dev) -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson