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

[Casey Duncan]

One man's opinion:

- Version support (at the application level) should be optional in 2.7. Y=
ou=20
should be able to turn it off (maybe through ZConfig). The default should=
=20
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=20
it to be acted upon.

2: develop a patch and submit it and/or check it in probably after vettin=
g the=20
change on a branch.

I'm afraid the only way to get your favorite issue fixed quickly is to fi=
x it=20
yourself.

The security implications do not seem dire enough to me to warrent trying=
 to=20
squeeze this into 2.6.x. If you do not use versions then none of the=20
implications apply. Perhaps it might be possible to do additional securit=
y=20
checks to make entering versions more protected. This might be an appropr=
iate=20
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=
=20
> full implications of the version functionality as it is implemented in=20
> zope. So let me summarize.
>=20
> versioning-as-implemented-in-zope consists of two parts:
>=20
> First, there's the database backend part (which I know nothing about)=20
> with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper).=
=20
> This resides where the db-connection is opened on the very start of=20
> every request.
>=20
> The second part is the Version product (capitalized to distinguish them=
)=20
> which is zope's mechanism to get a variable named 'Zope-Version'=20
> (=3D=3Dversion_support) with the value of the path to the version objec=
t=20
> inside the REQUEST (by setting a cookie).
>=20
>=20
> Bad properties of this implementation:
>=20
> 1. The "Join/Leave Versions" permission doesn't secure entering version=
s
> 2. Zope doesn't care if a correspondending Version instance to the valu=
e=20
> of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for=20
> the value of that Zope-Version variable at all.
> 3. And (minor problem, but whatever), since zope relies completely on=20
> the browser to send cookies only the right time (i.e. that the path set=
=20
>   for the cookie must match a prefix of the request-URI), this might=20
> also give unexpected results with acquisition.
>=20
>=20
> Security implications:
>=20
> Doh, anybody who can read/write to a zope server can get it to=20
> read/write from/to any version he likes, and the admin has no way of=20
> anticipating that short of patching zope. Combine that with sites like=20
> squishdot, collector.zope.org and you get chaos.
>=20
> Big plea:
>=20
> Really, this _is_ a security bug, and it should be handled that way and=
=20
> fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed=20
> above are gone.
>=20
> Sorry for getting a bit worked up about that issue.
>=20
> cheers,
> oliver
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -=20
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>=20