38856 - all bugzilla pages should specify charset

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect, P3)

Description

[Jesse Ruderman]

to prevent untrusted content on bugzilla from executing possibly malicious 
javascript code, each page should include a charset at the top.

see http://www.cert.org/tech_tips/malicious_code_mitigation.html/#3

Comment 1

[Dave Miller [:justdave]]

moving to real milestones...

Comment 2

[Myk Melez [:myk] [@mykmelez]]

The change itself is simple. Per
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 it merely
requires us to replace:

Content-type: text/html

... with:

Content-Type: text/html; charset=ISO-8859-1

... everywhere it appears in the code.

(The name "content-type" is case-insensitive.  I capitalized the "T" in it
because that seems to be the convention in the HTTP/1.1 spec.)

However, unfortunately that means touching a large portion of the code.  Are
there best practices that should be applied here to make the check-in as smooth
as possible?  I am thinking in particular of how to make sure we break the
minimum number of existing patches with a check-in of this scope.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

An alternative solution is to use the approach recommended in the CERT advisory
of specifying the character set in the HTML HEAD section like so:

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

This isn't quite as elegant but has the advantage of touching only four files:
changepassword.cgi, CGI.pl, buglist.cgi, and reports.cgi.

Comment 4

[Tara Hernandez]

i vote for #2 for now.  myk can i impose on you to make a patch?  i'm still
working my way through my list.

Comment 5

[Tara Hernandez]

myk says dawn wants this one...

Comment 6

[Dawn Endico]

I think we should go with http headers instead. There is a bug with both
netscape 4 and mozilla (and others?) which causes pages with <meta ... charset>
to load twice.

Also, what do you do with pages with multiple charsets? For instance, when
someone types in some japanese or arabic in a comment.

If you have to do something with those pages besides the normal
charset=ISO-8859-1. then how do you determine which charsets you have?

momoi?

Comment 7

[Katsuhiko Momoi]

Much I would like to support this effort, the only way this makes sense
is for the charset to be multilingual, e.g. UTF-8, which then 
can support virtually all language scripts.  
Whatever method you take, if you insert charset=ISO-8859-1, then you
will be inconveniencing users who need to read data other than 
ISO-8859-1, e.g. people can input Japanese data and because we don't
tag the pages with the charset, you can read them just by having the
charset on the browser side to be in your own language encoding.
The moment you put in a charset tag, or have the server send it,
we will be forcing these users to override the charset if you use
Netscape 6. If you use Communicator, there is nothing you can do.
The charset tag cannot be overridden and non ISO-8859-a content
can be displayed. 

Thus, the proposal is not practical at this point. Move to UTF-8 should be
considered in the near future, but in that case, we need to consider
backend issues.

For these reasons, I recommend against doing this at this time unless
you want Bugzilla to be monolingual and inconvenience all these L10n
projects people who can read the content as well those who count on 
Bugzilla to support display of non-Latin 1 script.

We can discuss alternatives but that would require extra things.
The best thing is to do here is to include this factor in the discussion
for supporting multiple lnaguage scripts better in the future.

Comment 8

[Katsuhiko Momoi]

> The charset tag cannot be overridden and non ISO-8859-a content
> can be displayed. 

Correction:

The charset tag cannot be overridden and non ISO-8859-a content
can NOT be displayed. 

Comment 9

[Gervase Markham [:gerv]]

So we aren't doing this for 2.14, then?

Gerv

Comment 10

[Tara Hernandez]

Kat makes a whole lot of sense.  Despite the potential risk, this really belongs
as part of an overall evaluation as to how we support localization in general. 
In the meantime, a release note might not be out of the question if people want
to make this customization part of their own configuration, and pick the charset
appropriate to the their target audience.  

Reassinging to Matt Barnson and cc-ing Dave Miller.

Comment 11

[Tara Hernandez]

Moving back to 2.14.  I am completely mystified as to how I managed to change
the target milestone without noticing.

Comment 12

[Matthew Barnson]

OK, accepting bug and putting these charset instructions down as part of the
Installation section of the Bugzilla Guide.  Once I'm done, should I reassign
this back to Dawn for further looks as we try to support better
internationalization, or go ahead and resolve it fixed since it's documented?

Comment 13

[Dave Miller [:justdave]]

Dawn, there's comments directed to you on here, and you weren't cc'd.

Comment 14

[timeless]

please use the meta. the real one causes netscape0.93beta and i think some 
other versions to crash or fail to load pages. or at least sniff for old 
browsers and provide them the simple text/html

Comment 15

[Matthew Barnson]

I don't have this in the Guide yet, but I'll work on it over this weekend.

Comment 16

[Matthew Barnson]

Documented, checked in.  Marking resolved.  We may wish to address this some 
time in the future, but I'm sure it will be covered by any other 
internationalization efforts.

Comment 17

[Dave Miller [:justdave]]

Moving to Bugzilla product

Comment 18

[Dave Miller [:justdave]]

anyone still interested in this topic, please see bug 126266 and weigh in there.
We appear to have a paramaterized solution for this in the works. :)

Comment 19

[Marc Schumann [:Wurblzap]]

*** Bug 289147 has been marked as a duplicate of this bug. ***