-----BEGIN PGP SIGNED MESSAGE-----
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?
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list