Description of problem: text/plain attachments don't open in the browser. Apparently it's a security setting? I dunno, if we're not confident in the browser to do the right thing on text/plain I think we have larger issues.
I've maintained many of our web browsers (Firefox, Netscape 4.x when we still shipped that, Mozilla, SeaMonkey, etc.) offered in Red Hat Enterprise Linux and Fedora, for nigh on 5 years for Red Hat, and several years prior to that working at Netscape. I'm extremely curious to know what specific security issues we're concerned about, especially given the fact that the Mozilla guys (who just so happen to be the upstream for Bugzilla) have not disabled viewing attachments inline, and defects in the browser would impact customers. If this is for an alternative (non-default) browser, might I suggest using browser detection for the specific browser, and then offering users of that browser a warning with an option to continue? Feel free to respond directly to me via private e-mail.
It was disabled until we can find a better way due to security problems with cross site scripting. http://www.bugzilla.org/security/2.22.6/: Vulnerability Details ===================== Class: Abuse of Functionality (Attachments) Versions: Every version before 2.22.7, 3.0.7, 3.2.1, or 3.3.2 Fixed In: 2.22.7, 3.0.7, 3.2.1, 3.3.2 Description: Bugzilla users can upload HTML or JavaScript attachments that are then viewed by other users in their web browsers. A malicious user could trick another Bugzilla user into viewing a malicious attachment that could then operate as that user. Since Bugzilla would view attachments using the same domain name as the rest of the application, such malicious attachments could access the cookies of the user and perform other activities usually restricted by the cross-site request protections of web browsers. Bugzilla now provides a two-fold solution to this problem: Bugzilla 2.22.7, 3.0.7, 3.2.1, and 3.3.2 now prevent users from viewing attachments in their browsers, by default. There is a new parameter named "allow_attachment_display" that administrators can enable to override this protection. Once this parameter is turned on, Bugzilla 3.0.7, 3.2.1, and 3.3.2 allow administrators to specify that attachments should be viewed using a different domain. This increases safety for the end user by enabling the browser's cross-domain request protections. References: https://bugzilla.mozilla.org/show_bug.cgi?id=38862 https://bugzilla.mozilla.org/show_bug.cgi?id=472206 ----------- bugzilla.mozilla.org is able to go the alternative domain name route to continue to allow displaying of attachments where we could not do that here due to our system configuration. We may start to allow displaying of specific attachment types such as text/plain but we need to make sure we can sanitize others first. Dave
*** Bug 485329 has been marked as a duplicate of this bug. ***
Can we please exempt text/plain starting yesterday? This is very very annoying and seriously disrupts our workflow. For an example just look at bug 485331, which has 6! plain text attachments, this is not unusual for an anaconda bug and we have 200 open anaconda bugs! We've regressed from: click attachment -> see it To: click, save as dialog pops up, save, open texteditor, click on open file, search file, click, see it And that multiplied by 6 for just one bug! Since browsers do not parse text/plain, but simply display it, their is no scripting here and thus also no cross site scripting.
Please please exempt text/plain from this blocking ASAP. It makes bugzilla seriously unpleasant to use.
This could be mitigated temporarily by setting 209.132.176.231 as the hostname of the attachment server. Of course, anyone that visited bugzilla via the hostname would still be at risk, however, anyone that does is more likely to understand the risks of doing so.
Changes committed to cvs and will be included in the next update (likely Mon Feb 16 earliest).