[Zope-dev] Re: 2.9.4? reStructuredText support?

[Florent Guillaume]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andreas Jung wrote:
>>
>> --On 8. Juli 2006 07:45:01 -0400 Jim Fulton <jim at zope.com> wrote:
>>
>>> On Jul 8, 2006, at 1:11 AM, Andreas Jung wrote:
>>>
>>>>
>>>> --On 7. Juli 2006 11:03:06 -0400 Jim Fulton <jim at zope.com> wrote:
>>>>
>>>>> I think we should do a 2.9.4 release to incorporate the recent hot
>>>>> fix.
>>>>> This is easy for me to say, since I won't be doing it. :)
>>>>>
>>>>> Because this recent fix actually fixed the same problem that the
>>>>> previous hot fix was supposed to fix, I think someone needs to
>>>>> work up
>>>>> some decent tests.  This is not a trivial task, bit it is
>>>>> necessary.  If
>>>>> no one is willing to do this, I think we need to drop the TTW
>>>>> reStructuredText support from Zope 2, as it is too great a risk.
>>>>>
>>>> Dropping TTW reST is absolutely not an option. I breaks backward
>>>> compatibility.
>>> Sorry, security trumps backward compatibility.
>>>
>>>
>>>>> BTW, I suspect that a less violent patch could be created, if
>>>>> anyone wants to champion TTW reStructuedText support in
>>>>> Zope 2.  Personally, I'm for dropping it.
>>>> Tres' patch is looking in fine to me. I don't see a need right now
>>>> for dropping reST with having file inclusing *removed*.
>>> Has anyone written tests for Tres' patch?  Apparently no one wrote
>>> adequate tests for the last hot fix, which helped put us in this
>>> situation.
>> I've written some tests (checked in on the trunk). They test the 'raw'
>> and 'include' directives
> 
> Great!  Maybe we can add a similar set for the 'fmt="restructured-text"'
> in DTML.
> 
>> @Tres: what is the reason to keep the 'raw' code in docutils? I am in favor
>> to remove it and replace it with a NotImplementedError exception (same
>> as for the the 'include' code). The related tests (for reStructredText
>> and ZReST are commented for now) do except a NotImplementedError for a
>> 'raw' directive.
> 
> 'raw' can be used to disable ReST processing for a block, even if the
> ':file:' or ':url:' options aren't set.;  I was trying to leave the
> possibility of that use case.

Isn't that leaving the door open for XSS (cross-site scripting) attacks? 
Allowing arbitrary raw HTML to be input allows javascript in the pages, 
and therefore cookie stealing.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com