More GSoC ideas from Kostya and Alexei.

1 files changed, 200 insertions, 7 deletions

diff --git a/gsoc.html b/gsoc.html
index 1423d92..0379caf 100644
--- a/gsoc.html
+++ b/gsoc.html
@@ -63,14 +63,178 @@
           <dl>
             <dt>Improve fuzzing for FreeType</dt>
             <dd>
-              <p>Description will follow.</p>
-
-              <p><em>Difficulty: </em>medium.  <em>Requirements:</em>
-                C, C++, Unix build tools.  <em>Potential mentors:</em>
-                Kostya Serebryany (Google), Werner Lemberg
-                (FreeType).</p>
+              <p>There are at least two fuzzers that constantly test
+                FreeType.  One of them
+                is <a href="https://github.com/google/oss-fuzz">OSS-Fuzz</a>,
+                and the tasks for GSoC presented here are targeted to
+                increase the efficiency of this fuzzer bot.</p>
+
+              <dl>
+                <dt>Split the existing fuzz target into many</dt>
+                <dd>
+                  <p>Right now we
+                    have <code>src/tools/ftfuzzer/ftfuzzer.cc</code>
+                    that contains</p>
+
+                  <pre>
+extern "C"
+int LLVMFuzzerTestOneInput(const uint8_t* data,
+                           size_t size_)
+{
+  ParseWhateverFontFileIGet(data, size);
+}</pre>
+
+                  <p>Instead of this monolithic approach we should
+                    split fuzzing into separate files (fuzz targets)
+                    for every font format, for example</p>
+
+                  <pre>
+src/tools/ftfuzzer/cff_fuzz.cc
+src/tools/ftfuzzer/cff2_fuzz.cc
+src/tools/ftfuzzer/cid_fuzz.cc</pre>
+
+                  <p>and every such file will have</p>
+
+                  <pre>
+extern "C"
+int LLVMFuzzerTestOneInput(const uint8_t* data,
+                           size_t size_)
+{
+  ParseOnlyMyFormatAndRejectAnythingElseQuickly(data, size);
+}</pre>
+
+                  <p>Ideally, the build rule for <code>cff_fuzz</code>
+                    will not <em>link</em> anything that CFF does not
+                    need.</p>
+
+                  <p>Such a split will make fuzzing more efficient for
+                    many reasons.</p>
+
+                  <ul>
+                    <li>Genetic mutations will not spend time crossing
+                      over files of different formats (e.g., trying to
+                      add BDF genes to a Type&nbsp;1 font).</li>
+                    <li>Data-flow guided mutations will not try to
+                      transform, say, a CID font file into a PCF font
+                      file.</li>
+                    <li>Some of the fuzzer's internal algorithms that
+                      are linear by the code size will run faster.</li>
+                    <li>Slow inputs that currently make fuzzing
+                      inefficient will cause only some of the targets
+                      suffer, not all of them.</li>
+                  </ul>
+
+                  <p>The changes will need to be reflected in the
+                    <a href="https://github.com/google/oss-fuzz/tree/master/projects/freetype2">OSS-Fuzz
+                      repository</a>.</p>
+
+                  <p><em>Difficulty: </em>medium.  <em>Requirements:</em>
+                    C, C++, Unix build tools.  <em>Potential
+                    mentors:</em> Kostya Serebryany (Google), Werner
+                    Lemberg (FreeType).</p>
+                </dd>
+              </dl>
+
+              <dl>
+                <dt>Prepare a public corpus of inputs</dt>
+                <dd>
+                  <p>The quality of the &lsquo;seed corpus&rsquo; is
+                    the key to fuzzing efficiency.  We should set up a
+                    repository (e.g., in github) that would hold</p>
+
+                  <ul>
+                    <li><em>small</em> but representative sample font
+                      files for every relevant font format (only with
+                      permissive licenses!), and</li>
+                    <li>fuzzed mutations of the above (this part will
+                      need to be periodically updated as fuzzing finds
+                      more inputs).</li>
+                  </ul>
+
+                  <p>This corpus will be used in two ways, namely</p>
+
+                  <ul>
+                    <li>to seed the fuzzing process, and</li>
+                    <li>as a regression suite (see below).</li>
+                  </ul>
+
+                  <p><em>Difficulty: </em>medium.  <em>Requirements:</em>
+                    Unix build tools, experience with
+                    scripting.  <em>Potential mentors:</em> Kostya
+                    Serebryany (Google), Werner Lemberg
+                    (FreeType).</p>
+                </dd>
+              </dl>
+
+              <dl>
+                <dt>Extend the FreeType testing process to use the
+                  above corpus</dt>
+                <dd>
+                  <p>The public corpus will allow us to use the fuzz
+                    targets as a regression test suite.  We'll need to
+                    set up a continuous integration testing (not
+                    fuzzing) to run the fuzz targets on the corpus.
+                    One way to achieve it is to have a github mirror
+                    of FreeType and set up Travis (or whatever other
+                    CI integrated with github).</p>
+
+                  <p><em>Difficulty: </em>medium.  <em>Requirements:</em>
+                    Unix build tools, experience with
+                    scripting.  <em>Potential mentors:</em> Kostya
+                    Serebryany (Google), Werner Lemberg
+                    (FreeType).</p>
+                </dd>
+              </dl>
+
+              <dl>
+                <dt>Analyze code coverage</dt>
+                <dd>
+                  <p>Once the fuzz targets are split, the public
+                    corpus is prepared, and the OSS-Fuzz integration
+                    is updated, we'll need to analyze
+                    the <a href="https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md#coverage-reports">code
+                    coverage provided by OSS-Fuzz</a> to see what code
+                    is left untested.</p>
+
+                  <p>Then either the fuzz targets or the corpus (or
+                    both) will need to be extended to cover that code.
+                    The ideal end state is to have 100% line coverage
+                    (currently, we have ~67% for the existing fuzz
+                    target).</p>
+
+                  <p><em>Difficulty: </em>medium.  <em>Requirements:</em>
+                    C, C++, Unix build tools, experience with
+                    scripting.  <em>Potential mentors:</em> Kostya
+                    Serebryany (Google), Werner Lemberg
+                    (FreeType).</p>
+                </dd>
+              </dl>
+
+              <dl>
+                <dt>Prepare fuzzing dictionaries for the font formats
+                  where relevant</dt>
+                <dd>
+                  <p>In some cases a simple dictionary (list of tokens
+                    used by the file format) may
+                    have <a href="http://libfuzzer.info/#dictionaries">dramatic
+                      effect on fuzzing</a>.</p>
+
+                  <p><em>Difficulty: </em>easy.  <em>Requirements:</em>
+                    Unix build tools, experience with
+                    scripting.  <em>Potential mentors:</em> Kostya
+                    Serebryany (Google), Werner Lemberg
+                    (FreeType).</p>
+                </dd>
+              </dl>
+
+              <p>While the subtasks themselves are quite isolated, the
+                order they have to be handled is from top to bottom as
+                shown in the descriptions above.  Consequently, the
+                project is suited to a group of students also that
+                work tightly together as a team.</p>
             </dd>
           </dl>
+
           <dl>
             <dt>Develop a test framework for checking FreeType's
               rendering output</dt>
@@ -103,6 +267,35 @@
             </dd>
           </dl>
 
+          <dl>
+            <dt>Improve the &lsquo;ftinspect&rsquo; demo program</dt>
+            <dd>
+              <p>Right now, FreeType comes with a suite of small
+                graphic tools to test the library, most notably
+                &lsquo;ftview&rsquo; and &lsquo;ftgrid&rsquo;.  The
+                used graphics library, while working more or less, is
+                very archaic, not having any comfort that modern GUIs
+                are providing.</p>
+
+              <p>To improve this, a new demo program called
+                &lsquo;ftinspect&rsquo; was started, based on the Qt
+                GUI toolkit.  However, the development is currently
+                stalled, mainly for lack of time.</p>
+
+              <p>The idea is to finish ftinspect,
+                handling <em>all</em> aspects of the other demo
+                programs.  Currently, it only provides the
+                functionality of &lsquo;ftgrid&rsquo;.</p>
+
+              <p>If the student prefers, the Qt toolkit could be
+                replaced with GTK.<p>
+
+              <p><em>Difficulty:</em> medium.  <em>Requirements:</em>
+                C, C++, Qt, Unix build tools.  <em>Potential
+                mentor:</em> Werner Lemberg (FreeType).</p>
+            </dd>
+          </dl>
+
           <p>Do you have more ideas?  Please write to
               our <a href="mailto:freetype-devel@nongnu.org">mailing
               list</a> so that we can discuss your suggestions,
@@ -112,7 +305,7 @@
         <!-- ************************************************** -->
 
         <div class="updated">
-          <p>Last update: 2-Feb-2017</p>
+          <p>Last update: 3-Feb-2017</p>
         </div>
       </div>
     </div>