small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)

[Oliver Bleutgen]

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