[reproducible-website] 01/02: Refresh homepage.

Chris Lamb chris at chris-lamb.co.uk
Thu May 3 04:50:15 CEST 2018


This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository reproducible-website.

commit 5a2e8d7de7bd06a69cd3c57842cb433bd98cdbed
Author: Chris Lamb <lamby at debian.org>
Date:   Wed May 2 19:49:32 2018 -0700

    Refresh homepage.
---
 index.html | 87 +++++++++++++++++++++++++++++++++++++++++---------------------
 1 file changed, 58 insertions(+), 29 deletions(-)

diff --git a/index.html b/index.html
index f7c885f..275f3c3 100644
--- a/index.html
+++ b/index.html
@@ -17,53 +17,77 @@ layout: home
     </select>
   </div>
 </nav>
+
 <div class="row">
   <div class="four columns title">
     <h2 id="what">What is it about?</h1>
   </div>
   <div class="eight columns text">
     <p>
-      <strong>Reproducible builds</strong> are a set of software development practices that
-      create a <strong>verifiable path from</strong> human-readable
-      <strong>source code to</strong> the <strong>binary</strong> code used by
-      computers.
+      <strong>Reproducible builds</strong> are a set of software development
+      practices that create an <strong>independently-verifiable path</strong>
+      from <strong>source code to the binary code</strong> used by computers.
       (<a href="{{ "/docs/definition/" | prepend: site.baseurl }}">Full definition</a>)
     </p>
   </div>
 </div>
 
+<br>
+
 <div class="row">
   <div class="four columns title">
     <h2 id="why">Why does it matter?</h1>
   </div>
   <div class="eight columns text">
     <p>
-      Most aspects of software verification are done on source code, as that is
-      what humans can reasonably understand. But most of the time, computers
-      require software to be first built into a long string of numbers to be
-      used. With <em>reproducible builds</em>, multiple parties can
-      <strong>redo this process independently</strong> and ensure they
-      <strong>all get <em>exactly</em> the same result</strong>. We can thus
-      <strong>gain confidence</strong> that a distributed binary code is indeed
-      coming from a given source code.
+      Whilst anyone can inspect the source code of free and open source
+      software for malicious flaws, most software is distributed pre-compiled
+      with no method to confirm whether they correspond.
+    </p>
+    <p>
+      This incentivises attacks on developers who release software, not only
+      via traditional exploitation but moreover in the forms of political
+      influence, blackmail or even threats of violence.
+    </p>
+    <p>
+      This is particularly a concern for developers collaborating on privacy or
+      security software: attacking these typically result in compromising
+      particularly politically-sensitive targets such as dissidents,
+      journalists and whistleblowers, as well as anyone wishing to communicate
+      securely under a repressive regime.
     </p>
     <p>
-      What made the recent <a style="text-decoration: none;"
-      href="https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal">Volkswagen
-      emissions scandal</a> possible is software that has been designed to lie
-      about its sensors in a lab environment. Having the source code under
-      public scrutiny would have made adding such a misfeature only a little
-      more difficult. Without <em>reproducible builds</em>, it is hard to
-      confirm that the binary code installed in the car was actually made using
-      the source code that has been verified.
+      Whilst individual developers are a natural target, it additionally
+      encourages attacks on build infrastructure as an successful attack would
+      provide access to a large number of downstream computer systems. By
+      modifying the generated binaries here instead of modifying the upstream
+      source code, illicit changes are essentially invisible to its original
+      authors and users alike.
     </p>
     <p>
+      The motivation behind <em>reproducible Builds</em> project is therefore
+      to allow verification that no vulnerabilities or backdoors have been
+      introduced during this compilation process. By promising
+      <strong>identical results</strong> are always generated from a given
+      source, this allows <strong>multiple third-parties</strong> to come to a
+      consensus on a "correct" result, highlighting any deviations as suspect
+      and worthy of scrutiny.
+    </p>
+    <p>
+      This ability to notice if a developer has been compromised then
+      deters such threats or attacks ocurring in the first place as any
+      compromise would be quickly detected. This offers comfort to front-liners
+      that they not only can be threatened, but they would not be co-erced into
+      exploiting or exposing their colleagues or end-users.
+    <p>
       <a href="/who/"><strong>Several free software projects</strong></a>
       already, or will soon, provide reproducible builds.
     </p>
   </div>
 </div>
 
+<br>
+
 <div class="row">
   <div class="four columns title">
     <h2 id="how">How?</h1>
@@ -71,33 +95,38 @@ layout: home
   <div class="eight columns text">
     <p>
       First, the <strong>build system needs to be made entirely
-      deterministic</strong>: transforming a given source must always
-      create the same result. Typically, the current date and time must not be
+      deterministic</strong>: transforming a given source must always create
+      the same result. For example, the current date and time must not be
       recorded and output always has to be written in the same order.
     </p>
     <p>
-      Second, the set of tools used to perform the build and more generally
-      the <strong>build environment</strong> should either be <strong>recorded
-      or pre-defined</strong>.
+      Second, the set of tools used to perform the build and more generally the
+      <strong>build environment</strong> should either be <strong>recorded or
+      pre-defined</strong>.
     <p>
       Third, users should be given a way to recreate a close enough build
-      environment, perform the build process, and <strong>verify that the output
-      matches the original build</strong>.
+      environment, perform the build process, and <strong>validate that the
+      output matches the original build</strong>.
     </p>
     <p>
-      Learn more on <a href="/docs/"><strong>how to make your software build
+      Learn more about <a href="/docs/"><strong>how to make your software build
       reproducibly…</strong></a>
     </p>
   </div>
 </div>
 
+<br>
+
 <div class="row">
   <div class="four columns title">
     <h2 id="news">News</h1>
   </div>
   <div class="eight columns">
+    <br>
+    <p class="rss-subscribe"><a href="{{ "/blog" | prepend: site.baseurl }}">Read our most recent weekly report</a>.</p>
+    <br>
     <ul class="posts">
-      {% for post in site.posts %}
+      {% for post in site.posts limit:3 %}
         <li>
           <span class="post-date">{{ post.date | date: "%b %-d, %Y" }}</span>
           <a class="post-link" href="{{ post.url | prepend: site.baseurl }}">{{ post.title }}</a>

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git


More information about the rb-commits mailing list