I didn't check the sources to see what solution was finally given to the
Version DoS attack, but I have a suggestion.
The problem, IIUC, is that Zope needs to decide whether the Version
informaton it's receiving is valid without having access to ZODB data.
My suggestion is to disable Versions unless Zope is started with the
ENVVAR (or ZConfig var) VERSION_KEY, which is a password used to hash
the Version info. In this case, the version cookie would be generated
Zope-Version = <version>:MD5(<version>:VERSION_KEY)
This way the connection machinery doesn't need to open the connection in
order to verify that Zope-Version was generated from a real version
The only way to abuse the Version system is by knowing VERSION_KEY.
Looking at the cookie itself will only allow an attacker to open the
same version, but even this can be avoided if we put an expiration time
in the cookie value and encode it in the signature part as well:
Zope-Version = <version>:<expiration>:MD5(<version>:<expiration>:VERSION_KEY)
Variants of this include putting the auth info in a different cookie
(Zope-Version-Auth), using SHA instead of MD5 to make it stronger,
base64 encoding the binary flavor of the digest digest instead of using
the hexdigest to make the cookie smaller, etc.
PS: I can help coding this if anyone can help me get my subscription to
zope-coders going (I tried subscribing but nothing happened) and
checking why my public key isn't working to get a Zope checkout (my
zope.org login is LRA) :-)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -