[gtk-web] Small style changes to the setuid page

[Emmanuele Bassi <ebassi src gnome org>]

commit ff82186db94543cd60a2645aa8583b410ec47fd2
Author: Emmanuele Bassi <ebassi gnome org>
Date:   Thu Apr 30 13:20:32 2020 +0100

    Small style changes to the setuid page
    
    Restore the list of points that was there in the old page.

 setuid.html | 46 +++++++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 19 deletions(-)
---
diff --git a/setuid.html b/setuid.html
index d614e1e..9f7fadf 100644
--- a/setuid.html
+++ b/setuid.html
@@ -19,20 +19,28 @@
 
         <p>You should not write <code>setuid</code> GTK programs because:</p>
 
-        <p>GTK is too big. GTK+-2.0 and its dependent libraries (ignoring Xlib) total over 600,000
-        lines of code. For GTK+-3.0 (ignoring backend specific and image loading libraries), this
-        figure is over 800000 lines of code.</p>
-
-        <p>GTK is too complex. GTK takes input from dozens of sources, from drag-and-drop, to
-        root-window properties, to keyboard input, to configuration files. This is a much broader
-        scope for compromises than a typical server and makes auditing GTK especially tricky.</p>
-
-        <p>Security of GTK requires the security of the underlying windowing system backend. The
-        GTK team is not prepared to make that guarantee. Security bugs have been found in the
-        recent past in such areas of Xlib as the input method code.</p>
-
-        <p>You should not make your GUI setuid at all. Why run the risk of security bugs in code
-        that does not need to be running with elevated privileges?</p>
+        <ul>
+          <li>
+            <p>GTK is too big. GTK+-2.0 and its dependent libraries (ignoring Xlib) total over
+            600,000 lines of code. For GTK+-3.0 (ignoring backend specific and image loading
+            libraries), this figure is over 800000 lines of code.</p>
+          </li>
+          <li>
+            <p>GTK is too complex. GTK takes input from dozens of sources, from drag-and-drop,
+            to root-window properties, to keyboard input, to configuration files. This is a much
+            broader scope for compromises than a typical server and makes auditing GTK especially
+            tricky.</p>
+          </li>
+          <li>
+            <p>Securing GTK requires the security of the underlying windowing system backend. The
+            GTK team is not prepared to make that guarantee. Security bugs have been found in the
+            recent past in such areas of Xlib as the input method code.</p>
+          </li>
+          <li>
+            <p>You should <strong>not</strong> make your GUI setuid at all. Why run the risk of
+            security bugs in code that does not need to be running with elevated privileges?</p>
+          </li>
+        </ul>
 
         <p>In the opinion of the GTK team, the only correct way to write a <code>setuid</code>
         program with a graphical user interface is to have a <code>setuid</code> backend that
@@ -40,11 +48,11 @@
         such as a pipe and that considers the input it receives to be untrusted.</p>
 
         <p>For this reason, no effort is made in GTK to disable the obvious ways that you could
-        compromise a setuid GTK program - <code>GTK_MODULES</code> and the ability for the user
-        to specify theme engines, because we consider this to be only papering over the fundamental
-        problems of writing <code>setuid</code> programs with any GUI toolkit. GTK may be modified
-        in the future to simply refuse to run with elevated privileges, though it does not do this
-        currently.</p>
+        compromise a <code>setuid</code> GTK program - <code>GTK_MODULES</code> and the ability for
+        the user to specify extensions to the toolkit, because we consider this to be only papering
+        over the fundamental problems of writing <code>setuid</code> programs with any GUI toolkit.
+        GTK may be modified in the future to simply refuse to run with elevated privileges, though
+        it does not do this currently.</p>
 
         <p>Does this mean that there are no security considerations for GTK? No. In particular
         image loaders have been and will continue to be an area of special care, since users may