On Jul 8, 2006, at 3:47 PM, Tres Seaver wrote:

Hash: SHA1

Steve Alexander wrote:
Tres wrote:
In Zope2 land, the module is still available, and can be used by other code (which may not know of that issue). I'm *not* in favor of shipping an un-patched docutils until we work this out. For instance, perhaps we should be patching docutils to make the *default* settings disable file inclusion and 'raw'; then the trusted code which wanted to render reST which legitimately needed those features could enable them explicitly.

If we do this, it is important to communicate effectively with packagers
(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 to do bugfixes only, and are distributing a Zope that depends on the standard
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, right?

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to