Bug 345970 Avoid using the string 'the web'

docs/en/xml/installation.xml

 <!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
-<!-- $Id: installation.xml,v 1.138 2008/04/04 06:48:08 vladd%bugzilla.org Exp $ -->
+<!-- $Id: installation.xml,v 1.139 2008/04/04 06:48:09 timeless%mozdev.org Exp $ -->
 <chapter id="installing-bugzilla">
   <title>Installing Bugzilla</title>
 
@@ -9,8 +9,8 @@
     <note>
       <para>If you just want to <emphasis>use</emphasis> Bugzilla, 
       you do not need to install it. None of this chapter is relevant to
-      you. Ask your Bugzilla administrator
-      for the URL to access it over the web.
+      you. Ask your Bugzilla administrator for the URL to access it from
+      your web browser.
       </para>
     </note>
 
@@ -164,7 +164,7 @@
        However, we strongly recommend using the Apache web server
        (either 1.3.x or 2.x), and 
        the installation instructions usually assume you are
-        using it. If you have got Bugzilla working using another webserver,
+        using it. If you have got Bugzilla working using another web server,
         please share your experiences with us by filing a bug in &bzg-bugs;.
       </para>
       
@@ -182,10 +182,9 @@
         Download a Bugzilla tarball (or check it out from CVS) and place
         it in a suitable directory, accessible by the default web server user 
         (probably <quote>apache</quote> or <quote>www</quote>). 
-        Good locations are either directly in the main web space for your
-        web server or perhaps in 
-        <filename>/usr/local</filename>
-        with a symbolic link from the web space.
+        Good locations are either directly in the web server's document directories or
+        in <filename>/usr/local</filename> with a symbolic link to the web server's 
+        document directories or an alias in the web server's configuration.
       </para>
 
       <caution>
@@ -197,7 +196,7 @@
       </caution>
       
       <para>Once all the files are in a web accessible directory, make that
-      directory writable by your webserver's user. This is a temporary step
+      directory writable by your web server's user. This is a temporary step
       until you run the 
       <filename>checksetup.pl</filename>
       script, which locks down your installation.</para>
@@ -1048,7 +1047,7 @@
                 <para>
                 <filename>checksetup.pl</filename> can set tighter permissions
                 on Bugzilla's files and directories if it knows what group the
-                webserver runs as. Find the <computeroutput>Group</computeroutput>
+                web server runs as. Find the <computeroutput>Group</computeroutput>
                 line in <filename>httpd.conf</filename>, place the value found
                 there in the <replaceable>$webservergroup</replaceable> variable
                 in <filename>localconfig</filename>, then rerun
@@ -1118,7 +1117,7 @@
 				<para>
 					<filename>checksetup.pl</filename> can set tighter permissions
 					on Bugzilla's files and directories if it knows what group the
-					webserver runs as. Find the <computeroutput>Group</computeroutput>
+					web server runs as. Find the <computeroutput>Group</computeroutput>
 					line in <filename>httpd.conf</filename>, place the value found
 					there in the <replaceable>$webservergroup</replaceable> variable
 					in <filename>localconfig</filename>, then rerun
@@ -1241,7 +1240,7 @@ c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
             The ActiveState install may have already created an entry for
             .pl files that is limited to <quote>GET,HEAD,POST</quote>. If
             so, this mapping should be <emphasis>removed</emphasis> as
-            Bugzilla's .pl files are not designed to be run via a webserver.
+            Bugzilla's .pl files are not designed to be run via a web server.
           </para>
         </note>
 
@@ -2223,7 +2222,7 @@ pid-file=/home/foo/mymysql/the.pid
       <title>HTTP Server</title>
 
       <para>Ideally, this also needs to be installed as root and
-      run under a special webserver account. As long as
+      run under a special web server account. As long as
       the web server will allow the running of *.cgi files outside of a
       cgi-bin, and a way of denying web access to certain files (such as a
       .htaccess file), you should be good in this department.</para>

docs/en/xml/security.xml

 <!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
-<!-- $Id: security.xml,v 1.2 2008/04/04 06:48:09 jake%bugzilla.org Exp $ -->
+<!-- $Id: security.xml,v 1.17 2008/04/04 06:48:24 timeless%mozdev.org Exp $ -->
 
 <chapter id="security">
 <title>Bugzilla Security</title>
@@ -49,15 +49,15 @@
       <quote>SYSTEM</quote> introduces obvious security concerns, the
       problems introduced by running everything as <quote>nobody</quote> may
       not be so obvious. Basically, if you run every daemon as
-      <quote>nobody</quote> and one of them gets comprimised it can
-      comprimise every other daemon running as <quote>nobody</quote> on your
+      <quote>nobody</quote> and one of them gets compromised it can
+      compromise every other daemon running as <quote>nobody</quote> on your
       machine. For this reason, it is recommended that you create a user
       account for each daemon.
       </para>
     
       <note>
         <para>You will need to set the <option>webservergroup</option> option
-        in <filename>localconfig</filename> to the group your webserver runs
+        in <filename>localconfig</filename> to the group your web server runs
         as. This will allow <filename>./checksetup.pl</filename> to set file
         permissions on Unix systems so that nothing is world-writable.
         </para>
@@ -68,9 +68,10 @@
     <section id="security-os-chroot">
     <title>The <filename>chroot</filename> Jail</title>
     
-      <para>If your system supports it, you may wish to consider running
+      <para>
+        If your system supports it, you may wish to consider running
         Bugzilla inside of a <filename>chroot</filename> jail. This option
-      provides unpresidented security by restricting anything running
+        provides unprecedented security by restricting anything running
         inside the jail from accessing any information outside of it. If you
         wish to use this option, please consult the documentation that came
         with your system.
@@ -89,7 +90,7 @@
     <title>The MySQL System Account</title>
     
       <para>As mentioned in <xref linkend="security-os-accounts"/>, the MySQL
-      daemon should run as a non-privleged, unique user. Be sure to consult
+      daemon should run as a non-privileged, unique user. Be sure to consult
       the MySQL documentation or the documentation that came with your system
       for instructions.
       </para>
@@ -136,32 +137,25 @@
     <section id="security-mysql-network">
     <title>Network Access</title>
     
-      <para>If MySQL and your webserver both run on the same machine and you
+      <para>If MySQL and your web server both run on the same machine and you
       have no other reason to access MySQL remotely, then you should disable
       the network access. This, along with the suggestion in
       <xref linkend="security-os-ports"/>, will help protect your system from
-      any remote vulnerabilites in MySQL. This is done using different
-      methods in MySQL versions 3 and 4.
+      any remote vulnerabilities in MySQL.
       </para>
       
-      <example>
-      <title>Disabling Networking in MySQL 3.x</title>
+      <example id="security-mysql-network-ex">
+      <title>Disabling Networking in MySQL</title>
       
-        <para>Simply enter the following in <filename>/etc/my.conf</filename>:
+        <para>Simply enter the following in <filename>/etc/my.cnf</filename>:
         <screen>
-[myslqd]
+[mysqld]
 # Prevent network access to MySQL.
 skip-networking
         </screen>
         </para>
       </example>
       
-      <example>
-      <title>Disabling Networking in MySQL 4.x</title>
-      
-        <para>There's a bug in Bugzilla about this</para>
-      </example>
-      
     </section>
 
 
@@ -177,20 +171,19 @@ skip-networking
   
   
   <section id="security-webserver">
-  <title>Webserver</title>
+  <title>Web server</title>
 
     <section id="security-webserver-access">
     <title>Disabling Remote Access to Bugzilla Configuration Files</title>
     
-      <para>There are many files that are placed in the Bugzilla directory
-      area that should not be accessable from the web. Because of the way
+      <para>
+        There are many files that are placed in the Bugzilla directory
+        area that should not be accessible from the web server. Because of the way
         Bugzilla is currently layed out, the list of what should and should not
-      be accessible is rather complicated. A new installation method is
-      currently in the works which should solve this by allowing files that
-      shouldn't be accessible from the web to be placed in a directory outside
-      the webroot. See 
-      <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=44659">bug 44659</ulink>
-      for more information.
+        be accessible is rather complicated. A quick way is to run
+        <filename>testserver.pl</filename> to check if your web server serves
+        Bugzilla files as expected. If not, you may want to follow the few
+        steps below.
       </para>
       
       <tip>
@@ -210,15 +203,6 @@ skip-networking
               <simplelist type="inline">
                 <member><filename>*.pl</filename></member>
                 <member><filename>*localconfig*</filename></member>
-                <member><filename>runtests.sh</filename></member>
-              </simplelist>
-              </para>
-            </listitem>
-            <listitem>
-              <para>But allow:
-              <simplelist type="inline">
-                <member><filename>localconfig.js</filename></member>
-                <member><filename>localconfig.rdf</filename></member>
               </simplelist>
               </para>
             </listitem>
@@ -308,23 +292,19 @@ skip-networking
       </itemizedlist>
 
       <para>Be sure to test that data that should not be accessed remotely is
-      properly blocked. Of particular intrest is the localconfig file which
+      properly blocked. Of particular interest is the localconfig file which
       contains your database password. Also, be aware that many editors
       create temporary and backup files in the working directory and that
-      those should also not be accessable. For more information, see 
+      those should also not be accessible. For more information, see
       <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">bug 186383</ulink>
       or
       <ulink url="http://online.securityfocus.com/bid/6501">Bugtraq ID 6501</ulink>.
-      To test, simply point your web browser at the file; for example, to
-      test mozilla.org's installation, we'd try to access
-      <ulink url="http://bugzilla.mozilla.org/localconfig"/>. You should get
-      a <quote><errorcode>403</errorcode> <errorname>Forbidden</errorname></quote>
-      error.
+      To test, simply run <filename>testserver.pl</filename>, as said above.
       </para>
       
       <tip>
         <para>Be sure to check <xref linkend="http"/> for instructions
-        specific to the webserver you use.
+        specific to the web server you use.
         </para>
       </tip>
     
@@ -367,27 +347,25 @@ skip-networking
     <section id="security-bugzilla-charset">
     <title>Prevent users injecting malicious Javascript</title>
 
-      <para>It is possible for a Bugzilla user to take advantage of character
-      set encoding ambiguities to inject HTML into Bugzilla comments. This
-      could include malicious scripts. 
-      Due to internationalization concerns, we are unable to
-      incorporate by default the code changes suggested by 
+      <para>If you installed Bugzilla version 2.22 or later from scratch,
+      then the <emphasis>utf8</emphasis> parameter is switched on by default.
+      This makes Bugzilla explicitly set the character encoding, following
       <ulink
-      url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">the
-      CERT advisory</ulink> on this issue.
-      If your installation is for an English speaking audience only, making the
-      change in <xref linkend="security-bugzilla-charset-ex"/> will prevent
-      this problem. 
+      url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">a
+      CERT advisory</ulink> recommending exactly this.
+      The following therefore does not apply to you; just keep
+      <emphasis>utf8</emphasis> turned on.
       </para>
 
-      <example id="security-bugzilla-charset-ex">
-        <para>Locate the following line in
-        <filename>Bugzilla/CGI.pm</filename>:
-        <programlisting>$self->charset('');</programlisting>
-        and change it to:
-        <programlisting>$self->charset('ISO-8859-1');</programlisting>
+      <para>If you've upgraded from an older version, then it may be possible
+      for a Bugzilla user to take advantage of character set encoding
+      ambiguities to inject HTML into Bugzilla comments.
+      This could include malicious scripts. 
+      This is because due to internationalization concerns, we are unable to
+      turn the <emphasis>utf8</emphasis> parameter on by default for upgraded
+      installations.
+      Turning it on manually will prevent this problem.
       </para>
-      </example>
     </section>    
     
   </section>

docs/en/xml/troubleshooting.xml

 <!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
-<!-- $Id: troubleshooting.xml,v 1.12 2008/04/04 06:48:24 mkanat%bugzilla.org Exp $ -->
+<!-- $Id: troubleshooting.xml,v 1.13 2008/04/04 06:48:25 timeless%mozdev.org Exp $ -->
 
 <appendix id="troubleshooting">
 <title>Troubleshooting</title>
@@ -22,7 +22,7 @@
     <para>If you have made it all the way through
     <xref linkend="installation"/> (Installation) and
     <xref linkend="configuration"/> (Configuration) but accessing the Bugzilla
-    URL doesn't work, the first thing to do is to check your webserver error
+    URL doesn't work, the first thing to do is to check your web server error
     log. For Apache, this is often located at
     <filename>/etc/logs/httpd/error_log</filename>. The error messages
     you see may be self-explanatory enough to enable you to diagnose and
@@ -32,7 +32,7 @@
 
     <para>
       Bugzilla can also log all user-based errors (and many code-based errors)
-      that occur, without polluting the web server error log.  To enable
+      that occur, without polluting the web server's error log.  To enable
       Bugzilla error logging, create a file that Bugzilla can write to, named
       <filename>errorlog</filename>, in the Bugzilla <filename>data</filename>
       directory.  Errors will be logged as they occur, and will include the type
@@ -45,10 +45,10 @@
   </section>
         
   <section id="trbl-testserver">
-  <title>The Apache webserver is not serving Bugzilla pages</title>
+  <title>The Apache web server is not serving Bugzilla pages</title>
     <para>After you have run <command>checksetup.pl</command> twice,
     run <command>testserver.pl http://yoursite.yourdomain/yoururl</command>
-    to confirm that your webserver is configured properly for
+    to confirm that your web server is configured properly for
     Bugzilla.
     </para>
     <programlisting>
@@ -76,7 +76,7 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t
       </listitem>
       <listitem>
         <para>The permissions on your library directories are set incorrectly.
-	They must, at the very least, be readable by the webserver user or
+        They must, at the very least, be readable by the web server user or
         group. It is recommended that they be world readable.
         </para>
       </listitem>
@@ -144,7 +144,7 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t
   
   <para>The most-likely cause is that the <quote>cookiepath</quote> parameter
   is not set correctly in the Bugzilla configuration.  You can change this (if
-  you're a Bugzilla administrator) from the editparams.cgi page via the web.
+  you're a Bugzilla administrator) from the editparams.cgi page via the web interface.
   </para>
 
   <para>The value of the cookiepath parameter should be the actual directory