The reporter should be in the summary itself, as well as the resolution of the bug (actually, only its status is given) and its description (aka comment 0).
Created attachment 201561 [details] [diff] [review]
This patch also seems to fix bug 127799 as a side effect...
list.rss.html no longer exists.
I don't have time to play with it before 3.0
Created attachment 251569 [details] [diff] [review]
Compared to the inital patch, I dropped the initial comment. We can add it separately if we want to.
Comment on attachment 251569 [details] [diff] [review]
>+ </tr><tr class="bz_feed_assignee">
> <td>[% columns.assigned_to_realname.title FILTER none %]</td>
> <td>[% bug.assigned_to_realname FILTER none %]</td>
I do not understand why this is FILTER none. If I change my realname to 'Olav <b>Vitters</b>' Firefox shows Vitters as bold within the Atom field, just as I would expect. I did see the FILTER xml, but that should is just some Atom specific thing (because the HTML has to be escaped). Bug.assigned_to_realname should still be escaped otherwise Atom clients which interpret the <td> will look at a <b> (etc) within a realname as well. Same for the other fields.
Created attachment 252207 [details] [diff] [review]
FILTER none -> FILTER html in the <summary> section as it uses type="html" and all HTML tags MUST be filtered, per the Atom specs: http://www.ietf.org/rfc/rfc4287
Comment on attachment 252207 [details] [diff] [review]
By the way, why didn't you just change it to serve up columns based on the columnlist parameter? This is what clients keep asking me for, personally.
Phil, it appears that the data in <summary> is currently incorrectly escaped, see my patch. Is there actually any *security* risk? If yes, then we will have to backport the filtering part of my patch on all branches.
I'm fairly sure that this is a security bug for the same reason that bug 313441 was.
Note that I couldn't exploit this issue with the Sage extension of Firefox. It seems to sanitize the fields for me (at least when the field contains <script>, </tr>, </td>, ...).
Sigh. Yes, it's security and needs to be backported, because an untrusted person could assign himself to a bug you'll see, with a script-injecting realname. Sorry, I'm too used to systems that would refuse or strip that realname on input, rather than escape it on output.
Since I don't see it mentioned here, the security portion of this bug was spun off as bug 367674.
Security advisory posted for bug 367674, so unlocking this bug.
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v <-- buglist.cgi
new revision: 1.352; previous revision: 1.351
Checking in template/en/default/list/list.atom.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.atom.tmpl,v <-- list.atom.tmpl
new revision: 1.3; previous revision: 1.2
*** Bug 387104 has been marked as a duplicate of this bug. ***
Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.