Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martijn > Betreff: [Zope-dev] who wants to maintain Zope 3? > > Hi there, > > Is anyone interested in maintaining Zope 3? > > With Zope 3 I mean: > > * the thing with the ZMI - do you care about the ZMI? Of corse do we all need the UI part for manage the components we install. But the old style ZMI views are obsolate this days. Right now we have to write this part for each project by ourself if they need to depend on z3c.form and z3c.pagelet. > * the thing that can be installed as a particular development > platform - do you care about the installation story for Zope > 3? (as opposed to Grok or your own application's?) Yes, I don't use it but I think we should have something available as a starting point for newcomers. This could be something like zopeproject or a minimalistic setup with as less as possible zope.*, z3c.* and repoze packages. > * the thing that has some kind of documentation website - do > you care about providing documentation for Zope 3 as opposed > to documentation for Grok or individual libraries? > > People who are interested in these aspects please speak up, > so we can figure out what this all means for the future of Zope 3. I think we should take a look if we can build a minimal setup which Plone, Grok and other projects can use. Do you think there could be such a based configuration? Or is there to much difference in each of Plone, Grok, repoze etc? > If nobody is interested, we should perhaps stop talking about > it entirely. If people are just interested in the ZMI, > perhaps we should form a ZMI project. The question is, can we find browser page pattern which Grok, Plone, repoze and others can use? Everybody needs to have at least management views for manage the components they install in some ways. So the question is not if we skip the ZMI or not. I think the question is can we improve and share such views in the different projects or do we have to develop views for each of them? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 3:20 PM, Shane Hathaway wrote: > Martijn Faassen wrote: >> Stephan Richter wrote: >>> On Friday 10 April 2009, Jim Fulton wrote: > Unfortunately these are ZC's use cases. They are not just ZC's use cases. >>> Keas is relying on that safety heavily too. Anyone who wants to >>> build a secure >>> DSL based on Python really wants zope.security. >> >> Okay, second case of such usage noticed. >> >> One thing that worries me is that PyPy folks keep saying it probably >> isn't really secure, though they refuse to specify why not when Chris >> Withers tried to find out last year at EuroPython. > > I suspect that's because Python allows anything by default; > zope.security and RestrictedPython only provide a way to close known > holes. Wrong in the case of zope.security. zope.security uses security proxies that only allow what is specifically allowed and deny everything else. Because zope.proxy is written in C, there's no way to defeat it in Python. The other potential holes I'm aware of are with: - rocks, which I'm very conservative with, and - __builtins__. You have to construct builtins very carefully, which we do and make sure you avoid certain problematic builtins, which we also do. It's hard to guess what they might be referring to, since they don't provide any specifics. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Martijn Faassen wrote: > Stephan Richter wrote: >> On Friday 10 April 2009, Jim Fulton wrote: Unfortunately these are ZC's use cases. >>> They are not just ZC's use cases. >> Keas is relying on that safety heavily too. Anyone who wants to build a >> secure >> DSL based on Python really wants zope.security. > > Okay, second case of such usage noticed. > > One thing that worries me is that PyPy folks keep saying it probably > isn't really secure, though they refuse to specify why not when Chris > Withers tried to find out last year at EuroPython. I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes. The security model of Javascript running in a browser is very similar, though, and that seems to be good enough for most people. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hey, Jim Fulton wrote: [snip] > I don't see the point of a separate package. This is a very small > corner of zope.security. Sure, it could be solved within zope.security as well. > A simple API for extending the definition of rocks would be enough to > deal with this particular issue. > > Note that "considered immutable" is rather vague. UUIDs aren't > immutable if you're willing to be only slightly devious. But if you > aren't worried about that in an application, then that isn't a > problem. You might even choose to make truly mutable objects into > rocks if you know your application is going to play nice. Right, I meant "considered immutable" in the dynamically typed sense. I can make classes that I consider to be immutable after creation in Python, even though I don't actually enforce it by preventing people from setting attributes on them. >> People trying to port zope.security dependent code to the google app >> engine seem to have yet another use case. This is fulfilled right >> now by >> a hacked up fork that at least makes import works, even though none of >> the actual functionality is there. We might want to put a knob in >> zope.security to support this hack out of the box too. > > Or tell them to use something else altogether. It all depends on > their use cases. If they want a seatbelt rather than a space suit, I > suppose a python-based proxy could be good enough, although it would > likely be too slow for that environment. The use case appears to be to use code that depends on zope.security on the google app engine. We have quite few libraries that do that out there. I think they just simply hack the proxy creation out completely, meaning that zope.security is basically a no-op. I asked what exactly is going on in another thread, so we just wait until we find out. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote: > We are in the business of content management. The most valuable > information the system and the entire physical machine has is the > content in the system. You don't run web applications on any kind of > shared servers where the system has any more valuable data. > > A person who is allowed to steal or delete the entire content is > what I call trusted. The potential additional damage of that person > breaking out of the web application is a minor concern compared to > this. Allowing any kind of TTW development is always going to be an > explicit opt-in, but if you are willing to allow this, we won't try > to stop you with limited access anymore. So, it's quite black and white. I would argue that there are several classes of users. At least these: 1. Trusted users inside your organization that makes the software.The role they get through their credentials has highest trust level and they could be allowed to do the most TTW. 2. Trusted users inside your customer organization. Those are usually the techies in the customer organization who configure your software to run the way they want. The role they get through their credentials has some trust level. They can change certain things TTW. 3. Untrusted users in your customer organization. These users get a role through their credentials that allows them to configure the software parts, but cannot do any TTW changes. 4. Untrusted customers of your customer organization. Plain web users. They just view the content. The granularity levels can be even finer between 1, 2, and 3 above. This allows for various shades of grey. However, since anybody's credentials can be stolen, I do not want to allow rock changes and arbitrary imports even to the users in class 1 above. Because: 1. they have the highest trust level in that web app, but 2. they are just an ordinary user on a machine running that web app, and 3. there are people who have higher credentials on that machine -- sysadmins. That's why leaving zope.security safer by default is the right thing. If you want to allow more, wrap around it someorg.lesssecurity or even someorg.nosecurity. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 12:26 PM, Martijn Faassen wrote: ... >>> b) prevent someone from viewing something with a public view because >>> they don't have access to content-level methods and attributes. >>> (which I >>> take is your "HTTP request as untrusted code" scenario). >> >> It is an example of that scenario, yes. > > Do you have other examples? The view doesn't have to be public. For example, the view might only be accessible to people with a particular role, and you might further limit what they can do based on the data they can access. ... >> It's worth noting that applications that don't allow untrusted code >> (other than the request) but that still want to use the protection >> system to protect content can can be much more liberal about what is >> treated as a rock by declaring rock classes themselves. The >> mechanisms >> support this now, although there may not be an API. > > This is what I was aiming at. Would it be possible to have a > zope.sandbox that builds on zope.security that does the whole > untrusted > execution thing, and then we have another profile of zope.security > that > just allows everything considered immutable as rocks? Can such things > exist in parallel in the same code base? I don't see the point of a separate package. This is a very small corner of zope.security. A simple API for extending the definition of rocks would be enough to deal with this particular issue. Note that "considered immutable" is rather vague. UUIDs aren't immutable if you're willing to be only slightly devious. But if you aren't worried about that in an application, then that isn't a problem. You might even choose to make truly mutable objects into rocks if you know your application is going to play nice. ... > People trying to port zope.security dependent code to the google app > engine seem to have yet another use case. This is fulfilled right > now by > a hacked up fork that at least makes import works, even though none of > the actual functionality is there. We might want to put a knob in > zope.security to support this hack out of the box too. Or tell them to use something else altogether. It all depends on their use cases. If they want a seatbelt rather than a space suit, I suppose a python-based proxy could be good enough, although it would likely be too slow for that environment. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] who wants to maintain Zope 3?
Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. What I'm *not* talking about is: * maintaining, documenting and installing Grok. * maintaining and documenting any particular Zope Toolkit library (outside of those bits that do ZMI-stuff, those aren't supposed to be in the toolkit) We know people are interested in doing all that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Zvezdan Petkovic wrote: > On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote: >> We do have the use-case of allowing trusted people to add templates or >> code TTW and many other things like data level and view based >> security. >> The RestrictedPython case however is something we will gladly give up. > > Trusted people!? > Are you checking their ID at the door? > > All you have in terms of trust are their credentials. Sure, that's called authentication. Happens to be the same in any technical or physical world. > You don't want to allow many, many things TTW, even if they logged in > with the trusted credentials. We are in the business of content management. The most valuable information the system and the entire physical machine has is the content in the system. You don't run web applications on any kind of shared servers where the system has any more valuable data. A person who is allowed to steal or delete the entire content is what I call trusted. The potential additional damage of that person breaking out of the web application is a minor concern compared to this. Allowing any kind of TTW development is always going to be an explicit opt-in, but if you are willing to allow this, we won't try to stop you with limited access anymore. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Stephan Richter wrote: > On Friday 10 April 2009, Dieter Maurer wrote: >>> think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 >>> developers are okay with this, let's go right ahead. >> I will continue to speak of Zope 2 (not Zope Classic). > > +1. I think we gain nothing by renaming Zope 2 to anything else. I agree with > all arguments made in favor of keeping the Zope 2 name. It's not necessary anymore to pile this on; before Dieter even spoke up today this branch of the discussion was dead anyway. :) I'd rather have your opinions about the future of Zope 3 elsewhere in this thread... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hey, Jim Fulton wrote: > On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: >> and Zope 2 isn't >> using zope.security anyway. > > That's immaterial. I was talking about the use case. It's hard to tell whether Zope 2 will ever adopt zope.security to fulfill this use case - I have the impression the big apps are trying to move away from Zope 2, and Plone at least seems to be moving away from untrusted code. I think that's interesting in figuring out where we can and cannot go with zope.security. [snip] >> I take it that zope.security is supporting three use cases: >> >> a) prevent an application developer for making mistakes concerning >> security, > > Yes > >> or alternatively, forcing developers to think about security >> in-depth. > > That is obviously not a goal. No one is forcing anyone to do anything. > You don't have to use zope.security. Some systems come with zope.security out of the box, such as traditional Zope 3, meaning normal development with it forces developers to think about this. I'm not saying this is a bad thing; it is a different perspective on "preventing an application developer from making mistakes". >> b) prevent someone from viewing something with a public view because >> they don't have access to content-level methods and attributes. >> (which I >> take is your "HTTP request as untrusted code" scenario). > > It is an example of that scenario, yes. Do you have other examples? [snip] >> c) allow Python/template untrusted code > > Yes. This is where proper handling of "rocks" is most important. > >> As far as I now know, the only actual applications of zope.security to >> accomplish c) are ZC's. > > I'm sure there are others. Yes, as Stephan said, Keas. > Zope 2's protection scheme addresses this > use case as well, although not as well. >> a) and b) would be served well enough if zope.security only cared >> about >> preventing accidental security violations. > > I'm not sure what you mean by "accidental" here, but I suspect I > disagree. I would agree that handling of rocks is far less important > in this context. Okay, let's just agree on the latter. :) [snip] >> Would there be a way to isolate these use cases so that other users in >> the community did not have to worry about this anymore? I ask because >> the topic has come up a few times already (now, and with the >> Python-based i18n message ids a while back). [snip] > It's worth noting that applications that don't allow untrusted code > (other than the request) but that still want to use the protection > system to protect content can can be much more liberal about what is > treated as a rock by declaring rock classes themselves. The mechanisms > support this now, although there may not be an API. This is what I was aiming at. Would it be possible to have a zope.sandbox that builds on zope.security that does the whole untrusted execution thing, and then we have another profile of zope.security that just allows everything considered immutable as rocks? Can such things exist in parallel in the same code base? I'm not saying that if so, we're going to do the work immediately. I just want to explore what directions we could go in if someone does want to do the work. People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Stephan Richter wrote: > On Friday 10 April 2009, Jim Fulton wrote: >>> Unfortunately these are ZC's use cases. >> They are not just ZC's use cases. > > Keas is relying on that safety heavily too. Anyone who wants to build a > secure > DSL based on Python really wants zope.security. Okay, second case of such usage noticed. One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Stephan Richter wrote: > On Friday 10 April 2009, Martin Aspeli wrote: >> "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386 >> .egg/zope/container/traversal.py", line 26, in ? >> from zope.publisher.interfaces import IDefaultViewName, NotFound >> ImportError: cannot import name IDefaultViewName > > zope.container 3.8.1 seems pretty high. I have noticed that if you use the > latest versions of everything, things break recently. Sigh. This is exactely > why we have the KGS. (Not your fault though.) The buildout used index = so I don't see why the KGS hasn't solved this problem. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote: > We do have the use-case of allowing trusted people to add templates or > code TTW and many other things like data level and view based > security. > The RestrictedPython case however is something we will gladly give up. Trusted people!? Are you checking their ID at the door? All you have in terms of trust are their credentials. You don't want to allow many, many things TTW, even if they logged in with the trusted credentials. Otherwise, you give them the same credentials on your physical machine that serves that app (e.g. they import os TTW). Finally, even if you are fine with allowing that because you trust them, who guarantees that every login with those credentials is really that trusted person? Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Jim Fulton wrote: > On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: > >> I know that Plone is moving away from untrusted code, > > I predict they won't, but we'll see. Well, it's on the roadmap to move away from it. The use case of allowing untrusted users to add Python code TTW to the system simply doesn't exist anymore. We do have the use-case of allowing trusted people to add templates or code TTW and many other things like data level and view based security. The RestrictedPython case however is something we will gladly give up. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
On Friday 10 April 2009, Dieter Maurer wrote: > >think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 > >developers are okay with this, let's go right ahead. > > I will continue to speak of Zope 2 (not Zope Classic). +1. I think we gain nothing by renaming Zope 2 to anything else. I agree with all arguments made in favor of keeping the Zope 2 name. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Friday 10 April 2009, Jim Fulton wrote: > > Unfortunately these are ZC's use cases. > > They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
On Friday 10 April 2009, Martin Aspeli wrote: > "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386 >.egg/zope/container/traversal.py", line 26, in ? > from zope.publisher.interfaces import IDefaultViewName, NotFound > ImportError: cannot import name IDefaultViewName zope.container 3.8.1 seems pretty high. I have noticed that if you use the latest versions of everything, things break recently. Sigh. This is exactely why we have the KGS. (Not your fault though.) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: ... > I know that Plone is moving away from untrusted code, I predict they won't, but we'll see. > and Zope 2 isn't > using zope.security anyway. That's immaterial. I was talking about the use case. > That leaves ZC's applications, which I > imagine are based on zope.security? Yes, not that it is really relevant to the discussion. >> (Note that, in some ways, HTTP requests represent untrusted code. >> This case can often be handled by simple resource-protection schemes, >> although some applications can still benefit from the Zope 3 >> protection scheme, which can help mediate access to content when >> fine- >> grained control is needed.) > > I take it that zope.security is supporting three use cases: > > a) prevent an application developer for making mistakes concerning > security, Yes > or alternatively, forcing developers to think about security > in-depth. That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security. > b) prevent someone from viewing something with a public view because > they don't have access to content-level methods and attributes. > (which I > take is your "HTTP request as untrusted code" scenario). It is an example of that scenario, yes. > (alternate > strategies are Grok's, which has view-level security but allows > content-level declarations about what's accessible or not. But > prominent > Grok users are clamoring for something closer to the traditional > approach with real content level protections) Interesting. Note that Zope 3's protection system addresses this case while Zope 2's system doesn't. This is one of the reasons I'd like to see Zope 2 move to the Zope 3 protection system. > c) allow Python/template untrusted code Yes. This is where proper handling of "rocks" is most important. > As far as I now know, the only actual applications of zope.security to > accomplish c) are ZC's. I'm sure there are others. Zope 2's protection scheme addresses this use case as well, although not as well. > a) and b) would be served well enough if zope.security only cared > about > preventing accidental security violations. I'm not sure what you mean by "accidental" here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context. > If this is correct, this is interesting; we are taking on a burden > for a > rather limited set of use cases. What burden? The protection system benefits all the use cases. It's also a burden that is easily removed if you don't have these use cases. > Unfortunately these are ZC's use cases. They are not just ZC's use cases. > Would there be a way to isolate these use cases so that other users in > the community did not have to worry about this anymore? I ask because > the topic has come up a few times already (now, and with the > Python-based i18n message ids a while back). Sure. If you (think you) don't need a protection system, or think you can design a lighter weight one that meets your needs, then don't use zope.security. By far, most of the pain of Zope 3 protection system, as well as it's power, comes from the use of security proxies. The handling of rocks is a minor issue. It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Jim Fulton wrote: > On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote: [snip] >> Protecting against workarounds is useful if you allow through the web >> manipulation of code itself. But who is actually doing this? > The purpose of the protection system is to protect an application > against untrusted code provided by people other than the application > develoer. If an application has no untrusted code, then the > protection system isn't necessary. I'll guess that 99% of applications > don't support untrusted code and don't need the Zope protection > system(s). The applications people build with Grok probably fall in > this category, or one would hope. :) > There are some applications, such as Zope 2, Plone, and many of our > (ZC's) applications that support untrusted code and, for these > systems, the protection system is critical. It doesn't protect the > application developer from herself, it protects her from the people > writing the untrusted code. I know that Plone is moving away from untrusted code, and Zope 2 isn't using zope.security anyway. That leaves ZC's applications, which I imagine are based on zope.security? > (Note that, in some ways, HTTP requests represent untrusted code. > This case can often be handled by simple resource-protection schemes, > although some applications can still benefit from the Zope 3 > protection scheme, which can help mediate access to content when fine- > grained control is needed.) I take it that zope.security is supporting three use cases: a) prevent an application developer for making mistakes concerning security, or alternatively, forcing developers to think about security in-depth. b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your "HTTP request as untrusted code" scenario). (alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections) c) allow Python/template untrusted code As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's. a) and b) would be served well enough if zope.security only cared about preventing accidental security violations. If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases. Unfortunately these are ZC's use cases. Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). It could be that c) grows more important again over time in case of a "rebirth of the ZMI", but that doesn't look like it's about to happen any time soon. And if it does it might happen in a more limited way that doesn't require a sophisticated untrusted code infrastructure. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Adam GROSZER wrote: > Hello, > > I would add TEMPORARYLY (for testing) the KGS to buildout.cfg: > > [buildout] > extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg > versions = versions > > develop = . benchmark > parts = test checker coverage-test coverage-report docs i18n benchmark python > ... > > But do not commit that! > I think people will use KGS in their buildout if they want and that > will nail versions appropriately. > > Later we might backport the [3.5/trunk]-compatibility which I'd like > to finish this weekend to 1.9. The tests now fail with: $ ./bin/test Running unit tests: Failure in test /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt Failed doctest test for zcml.txt File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt", line 0 -- File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt", line 67, in zcml.txt Failed example: from z3c.template.interfaces import IPageTemplate Exception raised: Traceback (most recent call last): File "/Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py", line 1356, in __run compileflags, 1) in test.globs File "", line 1, in ? from z3c.template.interfaces import IPageTemplate ImportError: No module named template.interfaces -- File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt", line 68, in zcml.txt Failed example: template = zope.component.queryMultiAdapter((None, request, None, None, myWidget), interface=IPageTemplate, name='input') Exception raised: Traceback (most recent call last): File "/Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py", line 1356, in __run compileflags, 1) in test.globs File "", line 2, in ? myWidget), interface=IPageTemplate, name='input') NameError: name 'IPageTemplate' is not defined -- File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt", line 73, in zcml.txt Failed example: template Exception raised: Traceback (most recent call last): File "/Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py", line 1356, in __run compileflags, 1) in test.globs File "", line 1, in ? template NameError: name 'template' is not defined -- File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt", line 78, in zcml.txt Failed example: print template(myWidget) Exception raised: Traceback (most recent call last): File "/Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py", line 1356, in __run compileflags, 1) in test.globs File "", line 1, in ? print template(myWidget) NameError: name 'template' is not defined Ran 740 tests with 1 failures and 0 errors in 4.211 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) I don't really feel confident to fix bugs in z3c.form until I can have a stable build environment, but I may check in some fixes anyway if I find time this weekend and aim to keep the number of failures constant. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote: > Hi there, > > One fundamental question about this that I have is why we want to > protect the user against such loopholes anyway? > > Isn't zope.security a protection system against *accidental* > mistakes in > building secure applications? No > I.e. I call a method and then I find out I > have no such access. Do we really need to protect the developer > against > more arcane workarounds? > > If I *want* to work around the security system deliberately I can > simply > remove the security proxy and be done with it. It's not like the > system > is protecting against this anyway. > > Protecting against workarounds is useful if you allow through the web > manipulation of code itself. But who is actually doing this? The purpose of the protection system is to protect an application against untrusted code provided by people other than the application develoer. If an application has no untrusted code, then the protection system isn't necessary. I'll guess that 99% of applications don't support untrusted code and don't need the Zope protection system(s). The applications people build with Grok probably fall in this category, or one would hope. :) There are some applications, such as Zope 2, Plone, and many of our (ZC's) applications that support untrusted code and, for these systems, the protection system is critical. It doesn't protect the application developer from herself, it protects her from the people writing the untrusted code. (Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hi there, One fundamental question about this that I have is why we want to protect the user against such loopholes anyway? Isn't zope.security a protection system against *accidental* mistakes in building secure applications? I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds? If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway. Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Heads up: Zope Framework -> Zope Toolkit
Hi there, The Zope Framework is now renamed to be the "Zope Toolkit". "Framework" proved to be a controversial name that implies a range of things to people we do not want to imply - in particular that you have to buy into the whole in order to use some of its parts. Zope Toolkit is a more neutral name that still implies we manage this as a whole, but doesn't imply you have to buy into the whole in order to use some of the parts. The Zope Toolkit contains a lot of libraries and frameworks, and also an overarching approach to how such frameworks are generally constructed (the component architecture). We now therefore have a Zope Toolkit Steering Group. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 3, 2009, at 2:57 AM, Brian Sutherland wrote:
> Hi,
>
> We're using UUIDs a lot, and it's pretty painful that they are
> security
> proxied. They're in the standard library from python 2.5
> (http://docs.python.org/library/uuid.html) and are immutable according
> to the documentation.
"According to the documentation" isn't good enough.
> I think they meet all the all the requirements to be rocks. So unless
> someone complains, I'll commit the attached patch in a few days.
>>> u = uuid.UUID('{12345678-1234-5678-1234-567812345678}')
>>> u.__dict__['int'] = 1
>>> u
UUID('----0001')
This isn't exactly immutable. The protection system would prevent
this sort of mutation, but I'm still nervous about a rock implemented
in Python. We have to be darn sure that there isn't some sort of loop
hole here. Really we have to do this with any rock and I'm not sure
we have the formalisms necessary to guide this.
Oh wait:
>>> del u.int
>>> u
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/python/2.5.1/lib/python2.5/uuid.py", line 192, in
__repr__
return 'UUID(%r)' % str(self)
File "/usr/local/python/2.5.1/lib/python2.5/uuid.py", line 198, in
__str__
hex = '%032x' % self.int
AttributeError: 'UUID' object has no attribute 'int'
Oops. This would not be prevented by the protection system. -1 for
making uuids rocks.
Jim
--
Jim Fulton
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Hello, I would add TEMPORARYLY (for testing) the KGS to buildout.cfg: [buildout] extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions develop = . benchmark parts = test checker coverage-test coverage-report docs i18n benchmark python ... But do not commit that! I think people will use KGS in their buildout if they want and that will nail versions appropriately. Later we might backport the [3.5/trunk]-compatibility which I'd like to finish this weekend to 1.9. Friday, April 10, 2009, 1:02:53 PM, you wrote: MA> Stephan Richter wrote: >> On Thursday 09 April 2009, Martin Aspeli wrote: >>> Clearly, I'm getting too new a version of RestrictedPython, but this is >>> running against the 3.4 KGS, so I don't see how that could really happen. >> >> This is not a problem. Ignore those errors as they happen in the Python 2.6 >> support code.Everything installed fine. >> >> Got RestrictedPython 3.5.0. MA> Mmm... it doesn't let me run the tests though: MA> $ ./bin/test MA> Test-module import failures: MA> Module: z3c.form.browser.tests MA> Traceback (most recent call last): MA>File MA> "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/browser/tests.py", MA> line 16, in ? MA> from z3c.form import testing MA>File MA> "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/testing.py", MA> line 28, in ? MA> from zope.app.testing import setup MA>File MA> "/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/setup.py", MA> line 47, in ? MA> from zope.container.traversal import ContainerTraversable MA>File MA> "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py", MA> line 26, in ? MA> from zope.publisher.interfaces import IDefaultViewName, NotFound MA> ImportError: cannot import name IDefaultViewName MA> Module: z3c.form.tests.test_doc MA> Traceback (most recent call last): MA>File MA> "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/test_doc.py", MA> line 23, in ? MA> from zope.app.testing import placelesssetup MA>File MA> "/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/placelesssetup.py", MA> line 26, in ? MA> from zope.container.testing \ MA>File MA> "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/testing.py", MA> line 29, in ? MA> from zope.container.traversal import ContainerTraversable MA>File MA> "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py", MA> line 26, in ? MA> from zope.publisher.interfaces import IDefaultViewName, NotFound MA> ImportError: cannot import name IDefaultViewName MA> Test-modules with import problems: MA>z3c.form.browser.tests MA>z3c.form.tests.test_doc MA> Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. MA> (optilude)(~/Development/Plone/Code/Products/z3c.form) MA> $ MA> My working set is pretty weird too. Lots of 3.5.x and 3.6.x and even a MA> 3.8.x. MA> $ cat bin/test MA> #!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python MA> import sys MA> sys.path[0:0] = [ MA>'/users/optilude/Development/Plone/Code/Products/z3c.form/src', MA>'/Users/optilude/.buildout/eggs/zope.testing-3.7.1-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.interface-3.5.0-py2.4-macosx-10.3-i386.egg', MA>'/Users/optilude/.buildout/eggs/setuptools-0.6c9-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.app.i18n-3.4.4-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/z3c.template-1.1a1-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/z3c.coverage-0.1.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.app.container-3.7.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.security-3.6.0-py2.4-macosx-10.3-i386.egg', MA>'/Users/optilude/.buildout/eggs/zope.schema-3.5.2-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.publisher-3.5.5-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.pagetemplate-3.4.1-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.location-3.5.3-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.lifecycleevent-3.5.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg', MA>'/Users/optilude/.buildout/eggs/zope.i18n-3.6.0-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.event-3.4.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.configuration-3.4.1-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.component-3.5.1-py2.4.egg', MA>'/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/zope.app.pagetemplate-3.5.0-py2.4.egg', MA> MA> '/Users/optilude/.buildout/eggs/ZODB3-3.9.0a12-py2.4-macosx-10.3-i386.egg', M
Re: [Zope-dev] naming Zope
Hey, Chris McDonough wrote: > All done except for the renaming of the steering group. Yay! Thanks Chris. > I'm not sure where to rename that. It got renamed automatically when you renamed Framework to Toolkit. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Apr 9 12:00:00 2009 UTC to Fri Apr 10 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:44:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011427.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:46:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011428.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:48:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011429.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 9 20:50:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011430.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 9 20:52:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011431.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:54:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011432.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 9 20:56:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011433.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 9 20:58:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011434.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Stephan Richter wrote: > On Thursday 09 April 2009, Martin Aspeli wrote: >> Clearly, I'm getting too new a version of RestrictedPython, but this is >> running against the 3.4 KGS, so I don't see how that could really happen. > > This is not a problem. Ignore those errors as they happen in the Python 2.6 > support code.Everything installed fine. > > Got RestrictedPython 3.5.0. Mmm... it doesn't let me run the tests though: $ ./bin/test Test-module import failures: Module: z3c.form.browser.tests Traceback (most recent call last): File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/browser/tests.py", line 16, in ? from z3c.form import testing File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/testing.py", line 28, in ? from zope.app.testing import setup File "/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/setup.py", line 47, in ? from zope.container.traversal import ContainerTraversable File "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py", line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Module: z3c.form.tests.test_doc Traceback (most recent call last): File "/users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/test_doc.py", line 23, in ? from zope.app.testing import placelesssetup File "/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/placelesssetup.py", line 26, in ? from zope.container.testing \ File "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/testing.py", line 29, in ? from zope.container.traversal import ContainerTraversable File "/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py", line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Test-modules with import problems: z3c.form.browser.tests z3c.form.tests.test_doc Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) $ My working set is pretty weird too. Lots of 3.5.x and 3.6.x and even a 3.8.x. $ cat bin/test #!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python import sys sys.path[0:0] = [ '/users/optilude/Development/Plone/Code/Products/z3c.form/src', '/Users/optilude/.buildout/eggs/zope.testing-3.7.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.interface-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/setuptools-0.6c9-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.i18n-3.4.4-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.template-1.1a1-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.coverage-0.1.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.container-3.7.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.security-3.6.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.schema-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.publisher-3.5.5-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.pagetemplate-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.location-3.5.3-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.lifecycleevent-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.i18n-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.event-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.configuration-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.component-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.pagetemplate-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/ZODB3-3.9.0a12-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.app.publisher-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.component-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.tal-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.copypastemove-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.dublincore-3.4.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.traversing-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.size-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.exceptions-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.proxy-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.deferredimport-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/pytz-2009a-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.depr
Re: [Zope-dev] naming Zope
On Fri, Apr 10, 2009 at 09:23, Dieter Maurer wrote: > I will continue to speak of Zope 2 (not Zope Classic). Right. The classic/legacy renaming is only necessary if we were to move to Zope 4, which we aren't, or continue to talk about Zope 3, which we aren't. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Wichert Akkerman wrote at 2009-4-9 10:40 +0200: >Previously Shane Hathaway wrote: >> >> >> Tres Seaver wrote: >> > WRT the "Framework" name: "framework" is a misleading name for the >> > collection of packages salvaged from the "new Coke" effort: it is >> > actually a *bunch* of frameworks, in the classic software engineering >> > sense, along with some "pure" libraries. >> >> Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) > >+1 If you want to attract non-Zope people, then "Zope Toolkit" may not be optimal. The term suggests: the toolkit for Zope users. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Martijn Faassen wrote at 2009-4-8 15:31 +0200: > ... >In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they >had names that fit the "Zope is a project, not software" pattern. We >could rename Zope 2 to Zope Classic, as was suggested. I think we should >also rename Zope 3 to something else (that doesn't imply it's the modern >future, as there are other alternatives at least as modern around that >are more recently developed - we want to get out of that bind). "Zope 2" and "Zope 3" is not ideal but by now familiar. I do not think a renaming effort would be worth at the current time. Avoid misleading names in the future >think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 >developers are okay with this, let's go right ahead. I will continue to speak of Zope 2 (not Zope Classic). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
