314659 - Provide more information for the Atom summary

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Frédéric Buclin]

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).

Comment 1

[Frédéric Buclin]

Attachment: patch, v1

Comment 2

[Dave Miller [:justdave]]

This patch also seems to fix bug 127799 as a side effect...

Comment 3

[Frédéric Buclin]

list.rss.html no longer exists.

Comment 4

[Frédéric Buclin]

I don't have time to play with it before 3.0

Comment 5

[Frédéric Buclin]

Attachment: patch, v2

Compared to the inital patch, I dropped the initial comment. We can add it separately if we want to.

Comment 6

[Olav Vitters]

Comment on attachment 251569 [details] [diff] [review]
patch, v2

>Index: template/en/default/list/list.atom.tmpl

>+      </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.

Comment 7

[Frédéric Buclin]

Attachment: patch, v3

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 8

[Max Kanat-Alexander]

Comment on attachment 252207 [details] [diff] [review]
patch, v3

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.

Comment 9

[Frédéric Buclin]

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.

Comment 10

[Max Kanat-Alexander]

I'm fairly sure that this is a security bug for the same reason that bug 313441 was.

Comment 11

[Frédéric Buclin]

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>, ...).

Comment 12

[Phil Ringnalda (:philor)]

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. 

Comment 13

[Dave Miller [:justdave]]

Since I don't see it mentioned here, the security portion of this bug was spun off as bug 367674.

Comment 14

[Max Kanat-Alexander]

Security advisory posted for bug 367674, so unlocking this bug.

Comment 15

[Frédéric Buclin]

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.352; previous revision: 1.351
done
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
done

Comment 17

[Max Kanat-Alexander]

Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.