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