RE: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Oliver Bleutgen > Sent: Tuesday, June 10, 2003 7:35 AM > To: [EMAIL PROTECTED] > Subject: Re: small summary and big plea was:(Re: [Zope-dev] Versions: > should they die?) > > > Chris Withers wrote: > > Shane Hathaway wrote: > > > >> > >> My opinion on this is a little different. It's quite easy for anyone > >> to make mischief on any Zope server that lets people make even minor > >> changes to the site, such as giving feedback, posting a discussion > >> item, etc. > > On the weekend I had the idea that it's even easier. See > http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 > how to do that on an zope server. > > >> All you have to do is include a Zope-Version cookie in the > >> request and your changes will place a lock on any objects that the > >> request touches. Zope doesn't even check the validity of the > >> Zope-Version cookie. Anyone who is not a ZODB expert would have a > >> hard time bringing the site back to sanity. > > > > > > This was my fear, and it's pretty shocking. > > > > Maybe Oliver should do just such a thing on both collector.zope.org and > > zope.org, or maybe cbsnewyork.com to prove a point and then this issue > > will get the attention is deserves ;-) > > Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer > not to get ;). > > cheers, > oliver > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > 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 maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Toby Dickenson wrote: > No criticism was implied public exploits are valuable part of > the security process. Its nice to hear not everyone in the industry has lost their mind. /me glances at redmond -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Tuesday 10 June 2003 09:32, Jamie Heilman wrote: > Toby Dickenson wrote: > > ! # Disable nasty insecure version support. Thanks to > > ! # Jamie Heilman and everyone one zope-dev > > Unless you're damning me with faint praise for posting an exploit, > (which is fine) No criticism was implied public exploits are valuable part of the security process. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Toby Dickenson wrote: > ! # Disable nasty insecure version support. Thanks to > ! # Jamie Heilman and everyone one zope-dev Unless you're damning me with faint praise for posting an exploit, (which is fine) this issue was found by Oliver, not me. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Friday 06 June 2003 21:28, Jamie Heilman wrote: > Quick way to add 100 zodb connections and ~90M to the memory footprint > with relatively little clue of who is responsible assuming traditional > logging; presumeably one would get much trickier if they really wanted > to obfuscate the source of attack, slowly crawling the site, changing > the user-agent string, etc. Attached is a temporary patch to block this denial of service attack. This patch applies cleanly to the trunk and the 2.6 branch. This patch works by blocking all access to versions in the publisher, so dont apply it if you cant afford to stop using versions -- Toby Dickenson http://www.geminidataloggers.com/people/tdickensonIndex: lib/python/ZODB/ZApplication.py === RCS file: /cvs-repository/Zope/lib/python/ZODB/ZApplication.py,v retrieving revision 1.13 diff -c -2 -r1.13 ZApplication.py *** lib/python/ZODB/ZApplication.py 8 Apr 2003 18:48:22 - 1.13 --- lib/python/ZODB/ZApplication.py 9 Jun 2003 22:58:43 - *** *** 42,49 def __bobo_traverse__(self, REQUEST=None, name=None): ! db, aname, version_support = self._stuff ! if version_support is not None and REQUEST is not None: ! version=REQUEST.get(version_support,'') ! else: version='' conn=db.open(version) --- 42,53 def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! # db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version)
Re: [Zope-dev] Versions: should they die?
Dieter Maurer wrote: If we really think, they were evil (I do not), we should make them a separate product which can be downloaded and installed by people who want it (like I do). That seems like a good idea :-) Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Oliver Bleutgen wrote: > 2. Zope doesn't care if a correspondending Version instance to the value > of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for > the value of that Zope-Version variable at all. Hmm, it doesn't care, but it does store it in memory. Pardon my fugly non-portable bashisms here, but I just wanted to hash out an example: #!/path/to/bash exec >/dev/null h='http://victim.example.com/' for i in `seq 100`; do w3m -dump -post <(perl -e 'print "Zope-Version=",$ARGV[0]x50' $i) "$h" done Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc. Under sane resource limits the host is spared however the /Control_Panel/Database/manage_cacheParameters resource becomes unavailable due to memory constraints. Other side-effects from allowing anonymous clients to open additional zodb connections are as of yet unknown to me, anyone care to speculate on other vectors of abuse? -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
[EMAIL PROTECTED] wrote at 2003-6-4 09:21 -0700: > ... > I think I agree with the feeling that versions should stay in ZODB, but be > depreciated/marked as "official evil" in ZMI. We should not have components in the core distribution which we mark "official evil". If we really think, they were evil (I do not), we should make them a separate product which can be downloaded and installed by people who want it (like I do). Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Oliver Bleutgen wrote at 2003-6-4 18:24 +0200: > ... > As you and Guido are talking about the ZMI (which means, AFAIK, the > managament interface), let me just say that as far as I understand it, > deprecating/marking-as-evil and even removing OFSP/Version.py is not > what I would like to see happen (not only). > > The problem lies in ZODB.ZApplication.ZApplicationWrapper > > def __bobo_traverse__(self, REQUEST=None, name=None): > db, aname, version_support = self._stuff > if version_support is not None and REQUEST is not None: > version=REQUEST.get(version_support,'') > else: version='' > conn=db.open(version) >... > > As I understand it, even if the Version product is removed, just putting > at variable named 'Zope-Version' into the REQUEST will cause reads and > writes to happen in a version. > Am I missing something here? No, you are right. I see two possible solutions: 1. Make "version_support" dependent on the existence of a product that knows how to enable it. The "Version" product could use monkey patching to enable version support. 2. Use the newly opened connection to check that "version" refers to a version object. 2. is much safer but makes version requests slightly more expensive. However, this should not be a real problem. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
On Friday 06 June 2003 15:04, Shane Hathaway wrote: > I think 2.6 ought to fix this by disabling recognition of the > Zope-Version cookie Setting this individually for each http port would better support existing happy users of this feature. (Im sure there must be some ;-) Being able to set up a port that ignored cookies but always used a specific Version would avoid many of the existing problems too. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
One man's opinion: - Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them. I would suggest these approaches: 1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon. 2: develop a patch and submit it and/or check it in probably after vetting the change on a branch. I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself. The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6. -Casey On Friday 06 June 2003 05:46 am, Oliver Bleutgen wrote: > Ok, I still have the impression that not enough people are aware of the > full implications of the version functionality as it is implemented in > zope. So let me summarize. > > versioning-as-implemented-in-zope consists of two parts: > > First, there's the database backend part (which I know nothing about) > with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). > This resides where the db-connection is opened on the very start of > every request. > > The second part is the Version product (capitalized to distinguish them) > which is zope's mechanism to get a variable named 'Zope-Version' > (==version_support) with the value of the path to the version object > inside the REQUEST (by setting a cookie). > > > Bad properties of this implementation: > > 1. The "Join/Leave Versions" permission doesn't secure entering versions > 2. Zope doesn't care if a correspondending Version instance to the value > of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for > the value of that Zope-Version variable at all. > 3. And (minor problem, but whatever), since zope relies completely on > the browser to send cookies only the right time (i.e. that the path set > for the cookie must match a prefix of the request-URI), this might > also give unexpected results with acquisition. > > > Security implications: > > Doh, anybody who can read/write to a zope server can get it to > read/write from/to any version he likes, and the admin has no way of > anticipating that short of patching zope. Combine that with sites like > squishdot, collector.zope.org and you get chaos. > > Big plea: > > Really, this _is_ a security bug, and it should be handled that way and > fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed > above are gone. > > Sorry for getting a bit worked up about that issue. > > cheers, > oliver > > > > > > > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > 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 maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Sorry if is OT. I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed. DirectoryStorage allows you to designate classes that should have all their history kept indefinitely. That may not have the flexibility that you need... Does the Version mechanism contribute to this kind of functionality? I'd like to be able to "tag" revisions of wiki pages and other documents, and then be able to diff them later without having to create a special kind of product for each object type that I'd like to use revisions for. The accepted wisdom is that feature like this should be implemented in the application, above zodb. This has come up a few times on zodb-dev list. There are extant app-space version-control implementations if you want to try them. They don't do the full range of things that, say, CVS does, but they aren't chopped liver either. Look for ZopeVersioning and CMFStaging. Both can be (at least) browsed at cvs.zope.org --jcc ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Andy McKay wrote: Im not keeping up on zope-3 at the moment, whats the plan for versions there? Just wondering if there is any great solution there that can be backported. I think the solution for Zope 3 is to move all versioning to the application layer. We've been doing this with CMF (using ZopeVersionControl and CMFStaging) and it has worked out quite well for customer projects. It seems much more reliable than versioning at the database layer. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> I think that will only work if there's a Version with the specified name. Nope. One of the joys of Versions is that there is almost zero error checking - you can put content into a non-existant / deleted / moved version. And then you can't get it out. It really sucks when you are using more than one zope in the same domain that has versions, and lo and behold you start get objects locked in the other zope's version ;) The joy. -- Andy McKay ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Im not keeping up on zope-3 at the moment, whats the plan for versions there? Just wondering if there is any great solution there that can be backported. -- Andy McKay ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Brad Clements wrote: Sorry if is OT. I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed. Does the Version mechanism contribute to this kind of functionality? No, not really. Maybe it can be coached into doing it, but not without much ado. Maybe this is kind of the reverse way of doing what versions are for. We have used versions a little to work on a "live site". That seems to be the only use for it, being able to make several updates on a site without the updates being seen. It's not a bad feature, but it's too limited for much of the use, where you instead want revisions of objects and workflows where you can stage the piublishing of different revisions. And for doing that you have no use of the ZODB versions at all, as they are done today. You are better off using multiple instances of the objects, one for each revision, and then creating a staging workflow with DCWorkflow. So, I could continue to use ZMI as normal, but run "another zserver" on a different port (the one that feeds the world) with a particular revision. Or I could do this with ZEO. Probably there's too much overhead in this idea. Well, it's too much overhead in doing it with ZODB, yes. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Anthony Baxter wrote: Oliver Bleutgen wrote As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only). The problem lies in ZODB.ZApplication.ZApplicationWrapper def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ... As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here? I think that will only work if there's a Version with the specified name. Have you tried it? I have (with cookies), and it works always. Oh, and for added fun set a persistent cookie. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
On Wednesday 04 June 2003 17:40, Brad Clements wrote: > Sorry if is OT. > > I'd like ZODB and Zope to support Revisions. That is, historical copies > that do not get removed when ZODB is packed. DirectoryStorage allows you to designate classes that should have all their history kept indefinitely. That may not have the flexibility that you need... > Does the Version mechanism contribute to this kind of functionality? I'd > like to be able to "tag" revisions of wiki pages and other documents, and > then be able to diff them later without having to create a special kind of > product for each object type that I'd like to use revisions for. The accepted wisdom is that feature like this should be implemented in the application, above zodb. This has come up a few times on zodb-dev list. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
>>> Oliver Bleutgen wrote > As you and Guido are talking about the ZMI (which means, AFAIK, the > managament interface), let me just say that as far as I understand it, > deprecating/marking-as-evil and even removing OFSP/Version.py is not > what I would like to see happen (not only). > > The problem lies in ZODB.ZApplication.ZApplicationWrapper > > def __bobo_traverse__(self, REQUEST=None, name=None): > db, aname, version_support = self._stuff > if version_support is not None and REQUEST is not None: > version=REQUEST.get(version_support,'') > else: version='' > conn=db.open(version) >... > > As I understand it, even if the Version product is removed, just putting > at variable named 'Zope-Version' into the REQUEST will cause reads and > writes to happen in a version. > Am I missing something here? I think that will only work if there's a Version with the specified name. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Paul Winkler wrote at 2003-6-3 14:00 -0400: > ... > It's been proposed that Versions should be > at least stamped in the ZMI with big warnings, or possibly disabled > altogether. > ... > Comments? -3 I like versions and use them from time to time to automically install changes on life servers. Without versions, I would need to work more often late at night (when I usually read Zope mailing lists ;-) ). Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Can I, a humble Zope product developer, please make a plea that anything "marked as an 'official evil'" be made as invisible as possible? (I.e. that you make it disappear unless specifically configured as an option, as was suggested up-thread). Zope is already full of deprecated methods that make learning the "one obvious way to do it" very hard to figure out. The refrain on the ML and in other places is "if the documentation isn't good enough, 'use the Source, Luke'", but have you actually looked at the source? Sorry, I know you have -- but please try to imagine what it looks like to a newcomer who doesn't know their way around like you do. We already have same-named objects defined in multiple places -- are they really all the same object? Are they different implementations of the same object? Are they actually just imports from one module to another? Are they overloaded with additional functionality? Also lots of similar objects -- should I use "Item" or "SimpleItem". Should I inherit stuff from "Globals" or from the files they are actually defined in? It is an important point of information architecture that signs to the user must be graded in order to be most useful -- many signs with the same apparent importance are confusing, and may be worse than no signs at all. Also, whereas you, who are intimately familiar with evolutionary history of Zope's source may be completely aware of what's old and what's new, the newbie developer has little way to determine this. I can look at file dates, and occasionally I can find notes explaining this in the comments. But too often developers say something along the lines of "this is the new improved way to do X". But when did they write that? Last month? A year ago? Longer? I recognize that you all have made steps in this direction for Zope 3 (such as the interface/components concept, which IMHO is a big improvement). Reducing confusion should be a big priority, I hope. And what you don't say is just as good as what you do. Minimalism seems very pythonic to me. ;-) Just my 2 cents. Cheers, Terry On Wednesday 04 June 2003 09:21 am, [EMAIL PROTECTED] wrote: > If I remember correctly, though, there was still a lot in question about > legitimate use cases. The web-services cluster-safety use-case I sketched > out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) > is still (perhaps) a valid case, but ONLY in a very-carefully constructed > application (and even that case leaves me wanting a better app-level way to > do it). > > I think I agree with the feeling that versions should stay in ZODB, but be > depreciated/marked as "official evil" in ZMI. > > Sean > > > -Original Message- > > From: Guido van Rossum [mailto:[EMAIL PROTECTED] > > > > > To anyone not following the "Problem committing zope > > 'version' objects" > > > thread on [EMAIL PROTECTED]: It's been proposed that Versions should be > > > at least stamped in the ZMI with big warnings, or possibly disabled > > > altogether. Numerous users have been bit by the fact that versions > > > basically do not work as advertised, leading in various > > cases to zodb > > > corruption or work that can't be saved. There are other > > security issues > > > that Oliver Bleutgen raised privately which I won't state here. > > > > > > Comments? Could we get at least some warnings in the ZMI before > > > 2.6.2 final? > > > > IMO versions do nothing except complexify the code. I believe it's an > > official Zope Corp position to discourage them for new projects. Yet > > Jeremy Hylton seems to think that they are somehow useful and has > > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > > they would have been gone, with a big helping of YAGNI! > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
[EMAIL PROTECTED] wrote: If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it). I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI. As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only). The problem lies in ZODB.ZApplication.ZApplicationWrapper def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ... As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Sorry if is OT. I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed. Does the Version mechanism contribute to this kind of functionality? I'd like to be able to "tag" revisions of wiki pages and other documents, and then be able to diff them later without having to create a special kind of product for each object type that I'd like to use revisions for. Maybe this is kind of the reverse way of doing what versions are for. We have used versions a little to work on a "live site". What would be interesting is using revisions (with tags), then telling Zope to serve only objects with this revision or "older", or the current object if no revisions are on file for that object. And .. the serving up of a particular tag would be set on a Zserver instance. So, I could continue to use ZMI as normal, but run "another zserver" on a different port (the one that feeds the world) with a particular revision. Or I could do this with ZEO. Probably there's too much overhead in this idea. -- Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it). I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI. Sean > -Original Message- > From: Guido van Rossum [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2003 5:08 PM > To: Paul Winkler > Cc: [EMAIL PROTECTED] > Subject: Re: [Zope-dev] Versions: should they die? > > > > To anyone not following the "Problem committing zope > 'version' objects" > > thread on [EMAIL PROTECTED]: It's been proposed that Versions should be > > at least stamped in the ZMI with big warnings, or possibly disabled > > altogether. Numerous users have been bit by the fact that versions > > basically do not work as advertised, leading in various > cases to zodb > > corruption or work that can't be saved. There are other > security issues > > that Oliver Bleutgen raised privately which I won't state here. > > > > Comments? Could we get at least some warnings in the ZMI before > > 2.6.2 final? > > IMO versions do nothing except complexify the code. I believe it's an > official Zope Corp position to discourage them for new projects. Yet > Jeremy Hylton seems to think that they are somehow useful and has > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > they would have been gone, with a big helping of YAGNI! > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > 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 maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> Perhaps Jeremy could run through his reasons for wanting them to > stay around again? That's not necessary. They could stay in ZODB (certainly cutting them out of ZODB3 now would be more work than leaving them in) but be disabled in ZMI. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Paul Winkler wrote: To anyone not following the "Problem committing zope 'version' objects" thread on [EMAIL PROTECTED]: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? As I see it, you either have to disable the versioning functionality completely, or live with it. Raising a warning when people for instance add a Version object just gives the impression that you are safe if you don't use the Version product, which is wrong. If the version functionality would be disabled by default and could be enabled by a startup parameter without impacting performance, then this would be the way to go IMHO. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Paul Winkler wrote: To anyone not following the "Problem committing zope 'version' objects" thread on [EMAIL PROTECTED]: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Well, as they are, even when they are working, they are practically useless, since almost all even slightly complex use of Zope involves catalogs, and when using versions and catalogs, the catalog immediately gets blocked from outside change as soon as you reindex something in a version. So I have no problems with versions getting dropped altogether in 2.7. To have versions you really need a way to branch object versions and then merge them again. This COULD be implemented in the ZODB, but it might just as well be implemented on a higher level, and I'm not completely sure that the ZODB solution is wrong. But it is not nessecary. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? I think that would be good. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
Paul Winkler wrote: Comments? They really should die. They cause nothing but pain and suffering. Could we get at least some warnings in the ZMI before 2.6.2 final? I do hope so. I'd also like to see them becoming an explicit configuration option in 2.7 and not appear in any UI's unless they have been explicitly turned on... Perhaps Jeremy could run through his reasons for wanting them to stay around again? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
>>> Guido van Rossum wrote > IMO versions do nothing except complexify the code. I believe it's an > official Zope Corp position to discourage them for new projects. Yet > Jeremy Hylton seems to think that they are somehow useful and has > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > they would have been gone, with a big helping of YAGNI! Worse yet, they _seem_ like a neat/useful solution. But they're not - it's a path that leads to madness and despair. I'd prefer the approach of making you change some code in lib/python/ to enable them, with them disabled by default. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> IMO versions do nothing except complexify the code. I believe it's an > official Zope Corp position to discourage them for new projects. Yet > Jeremy Hylton seems to think that they are somehow useful and has > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > they would have been gone, with a big helping of YAGNI! I think its worth pointing out that the main part of the problem with versions is how they are implemented in Zope 2, not as they exist in the ZODB. It might be fine and useful in the ZODB, in fact I remember some use cases Jeremy pointed out that did sound useful. The main problem really is the Zope implementation for example: you can lock any object in a version that doesn't exists, it uses cookies, trouble committing... etc. -- Andy McKay ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> To anyone not following the "Problem committing zope 'version' objects" > thread on [EMAIL PROTECTED]: It's been proposed that Versions should be > at least stamped in the ZMI with big warnings, or possibly disabled > altogether. Numerous users have been bit by the fact that versions > basically do not work as advertised, leading in various cases to zodb > corruption or work that can't be saved. There are other security issues > that Oliver Bleutgen raised privately which I won't state here. > > Comments? Could we get at least some warnings in the ZMI before > 2.6.2 final? IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI! --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
To anyone not following the "Problem committing zope 'version' objects" thread on [EMAIL PROTECTED]: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE COSMIC! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
