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 )