On Jul 8, 2006, at 3:47 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Steve Alexander wrote:
In Zope2 land, the module is still available, and can be used by
code (which may not know of that issue). I'm *not* in favor of
an un-patched docutils until we work this out. For instance,
should be patching docutils to make the *default* settings
inclusion and 'raw'; then the trusted code which wanted to
which legitimately needed those features could enable them
If we do this, it is important to communicate effectively with
(like, in Linux distributions) that the Zope docutils is patched as a
workaround to this.
This may be a problem for distributions that promise their users
bugfixes only, and are distributing a Zope that depends on the
docutils in their distribution.
(I cc-ed Martin Pitt, who is responsible for Ubuntu security updates.
I'll fill him in on the rest of the discussion.)
Packagers would have to do the moral equivalent of forking docutils in
order to satisfy incompatible use cases:
- Zope needs a docutils which is "safe at any speed" for TTW use.
- Other Python applications may not need that safety, and may need
the very features which Zope *must* disable.
So forking docutils inside Zope is *not* evil, even when considering
packaged versions, as long as the packagers know about the fork,
The unforked docutils provides the necessary safety when used correctly.
It is our careless use of the feature that was the cause of the problem.
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list