At: http://www.zope.org/Wikis/DevSite/Proposals/Zope3ProtectionInZope2 Is a proposal to use Zope 3's protection system in Zope 2. I think that the proposed change would provide very significan't benefits, although it also presents some risks. I'm looking for volunteers to help make this happen, peferably this fall. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
At:
http://www.zope.org/Wikis/DevSite/Proposals/Zope3ProtectionInZope2
Is a proposal to use Zope 3's protection system in Zope 2.
I think that the proposed change would provide very significan't benefits, although it also presents some risks.
I'm looking for volunteers to help make this happen, peferably this fall.
Cool! Zope 3's security system is definitely quite powerful. However... You mean you're hoping this could be in Zope 2.9? Probably not surprisingly, you want put in me in the 'skeptics' camp here. :) We already have a job on our hands making Zope 2.9's Five work with Zope 3.2, and actually releasing Zope 3.2 (I'll note that Zope 3.1 is still not released as a final). I would strongly urge that this work is done on a branch so we can ship Zope 2.9 without it if necessary. I'm definitely worried about backwards compatibility -- how would the effect be handled that any filesystem-level Python code in Zope 2 is considered trusted, for instance? Would security wrappers be removed whenever code is passed along to this level? Would this also mean a port of the default Zope 3 security policy? I guess that isn't possible as the security information is stored quite differently. Would this mean we would write a new Zope 2 policy, but based on the Zope 3 security policy mechanism, or are we only porting the security-wrapper bits for now? Is any scheme possible where we could introduce this selectively and in parallel to the existing mechanisms? Like, for instance, a knob on a folderish object that could be turned on so it starts wrapping everything thereafter? I understand that one huge benefit of this change is that we can stop maintaining Zope 2's security infrastructure, but a huge benefit of doing this in parallel would be that we have some time to really shake out bugs without destabilizing everything else. This has worked very well with Five so far, as it lets people move at their own speeds. The people building the new stuff aren't making life complicated for the rest, and neither are the people who are sticking with the existing stuff slowing down or discourage the people who want to build new things. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
At:
http://www.zope.org/Wikis/DevSite/Proposals/Zope3ProtectionInZope2
Is a proposal to use Zope 3's protection system in Zope 2.
I think that the proposed change would provide very significan't benefits, although it also presents some risks.
I'm looking for volunteers to help make this happen, peferably this fall.
Cool! Zope 3's security system is definitely quite powerful.
However...
You mean you're hoping this could be in Zope 2.9? Probably not surprisingly, you want put in me in the 'skeptics' camp here. :)
That's your job. I respect that.
We already have a job on our hands making Zope 2.9's Five work with Zope 3.2, and actually releasing Zope 3.2 (I'll note that Zope 3.1 is still not released as a final). I would strongly urge that this work is done on a branch so we can ship Zope 2.9 without it if necessary.
Of course.
I'm definitely worried about backwards compatibility -- how would the effect be handled that any filesystem-level Python code in Zope 2 is considered trusted, for instance? Would security wrappers be removed whenever code is passed along to this level?
No. I noted this as a risk in the proposal. I think we should strive to make this optional -- for 2 releases.
Would this also mean a port of the default Zope 3 security policy?
No. I'm only talking about the protection system in this proposal.
I guess that isn't possible as the security information is stored quite differently.
Someday, I'd like to make the entire arhitecture available. Then the existing Zope 2 security policy would be one of several that could be pluggin in.
Would this mean we would write a new Zope 2 policy, but based on the Zope 3 security policy mechanism, or are we only porting the security-wrapper bits for now?
I'm only talking about the protection system.
Is any scheme possible where we could introduce this selectively and in parallel to the existing mechanisms?
Yes, as mentioned in the discussion of risks in the proposal.
Like, for instance, a knob on a folderish object that could be turned on so it starts wrapping everything thereafter?
This would be a system-wide option, controlled via zope.conf or zcml.
I understand that one huge benefit of this change is that we can stop maintaining Zope 2's security infrastructure, but a huge benefit of doing this in parallel would be that we have some time to really shake out bugs without destabilizing everything else.
Yes. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (2)
-
Jim Fulton -
Martijn Faassen