[Reproducible-commits] [reproducible-website] 01/55: Initial version of reproducible-builds.org website
Chris Lamb
chris at chris-lamb.co.uk
Tue Aug 23 13:39:49 UTC 2016
This is an automated email from the git hooks/post-receive script.
lamby pushed a commit to branch master
in repository reproducible-website.
commit fdf20c6f9875e242e862f26c2092733ab6749a0f
Author: Jérémy Bobbio <lunar at debian.org>
Date: Sun Oct 25 12:27:48 2015 +0000
Initial version of reproducible-builds.org website
Ready for reviews.
---
.gitignore | 5 +
README | 55 ++++
_config.yml | 22 ++
_data/docs.yml | 35 +++
_data/projects.yml | 54 ++++
_docs/archives.md | 167 ++++++++++++
_docs/build_path.md | 31 +++
_docs/build_toolchain_from_source.md | 62 +++++
_docs/buy_in.md | 108 ++++++++
_docs/checksums.md | 24 ++
_docs/definition_strategies.md | 65 +++++
_docs/deterministic_build_systems.md | 58 ++++
_docs/embedded_signatures.md | 54 ++++
_docs/formal_definition.md | 15 +
_docs/locales.md | 94 +++++++
_docs/perimeter.md | 66 +++++
_docs/plans.md | 69 +++++
_docs/proprietary_os.md | 39 +++
_docs/randomness.md | 23 ++
_docs/recording.md | 27 ++
_docs/sharing_certifications.md | 22 ++
_docs/stable_inputs.md | 90 ++++++
_docs/stable_outputs.md | 44 +++
_docs/test_bench.md | 51 ++++
_docs/timestamps.md | 70 +++++
_docs/timezones.md | 66 +++++
_docs/value_initialization.md | 36 +++
_docs/version_information.md | 22 ++
_docs/virtual_machine_drivers.md | 60 ++++
_docs/volatile_inputs.md | 26 ++
_events/athens2015.html | 33 +++
_includes/docs_contents.html | 8 +
_includes/docs_contents_mobile.html | 10 +
_includes/docs_option.html | 11 +
_includes/docs_ul.html | 21 ++
_includes/footer.html | 50 ++++
_includes/head.html | 15 +
_includes/header.html | 27 ++
_includes/section_nav.html | 39 +++
_layouts/default.html | 14 +
_layouts/docs.html | 20 ++
_layouts/home.html | 16 ++
_layouts/page.html | 17 ++
_layouts/post.html | 25 ++
_posts/2015-10-16-new-homepage.markdown | 24 ++
css/Raleway/Raleway-Black.ttf | Bin 0 -> 177664 bytes
css/Raleway/Raleway-BlackItalic.ttf | Bin 0 -> 145676 bytes
css/Raleway/Raleway-Bold.ttf | Bin 0 -> 176280 bytes
css/Raleway/Raleway-BoldItalic.ttf | Bin 0 -> 146180 bytes
css/Raleway/Raleway-ExtraBold.ttf | Bin 0 -> 174492 bytes
css/Raleway/Raleway-ExtraBoldItalic.ttf | Bin 0 -> 145532 bytes
css/Raleway/Raleway-ExtraLight.ttf | Bin 0 -> 174176 bytes
css/Raleway/Raleway-ExtraLightItalic.ttf | Bin 0 -> 141688 bytes
css/Raleway/Raleway-Italic.ttf | Bin 0 -> 144500 bytes
css/Raleway/Raleway-Light.ttf | Bin 0 -> 180680 bytes
css/Raleway/Raleway-LightItalic.ttf | Bin 0 -> 146512 bytes
css/Raleway/Raleway-Medium.ttf | Bin 0 -> 178116 bytes
css/Raleway/Raleway-MediumItalic.ttf | Bin 0 -> 146304 bytes
css/Raleway/Raleway-Regular.ttf | Bin 0 -> 176188 bytes
css/Raleway/Raleway-SemiBold.ttf | Bin 0 -> 177968 bytes
css/Raleway/Raleway-SemiBoldItalic.ttf | Bin 0 -> 145556 bytes
css/Raleway/Raleway-Thin.ttf | Bin 0 -> 175316 bytes
css/Raleway/Raleway-ThinItalic.ttf | Bin 0 -> 141964 bytes
css/Raleway/SIL Open Font License.txt | 43 +++
css/main.css | 451 +++++++++++++++++++++++++++++++
css/normalize.css | 427 +++++++++++++++++++++++++++++
css/skeleton.css | 415 ++++++++++++++++++++++++++++
docs.html | 70 +++++
events.html | 30 ++
feed.xml | 30 ++
images/basic-principle.png | Bin 0 -> 19542 bytes
images/docs/uninitialized_memory.png | Bin 0 -> 139413 bytes
images/logos/archlinux.png | Bin 0 -> 7149 bytes
images/logos/bitcoin.png | Bin 0 -> 10897 bytes
images/logos/cii.png | Bin 0 -> 8275 bytes
images/logos/coreboot.png | Bin 0 -> 3764 bytes
images/logos/debian.png | Bin 0 -> 1470 bytes
images/logos/freebsd.png | Bin 0 -> 21100 bytes
images/logos/netbsd.png | Bin 0 -> 7978 bytes
images/logos/openwrt.png | Bin 0 -> 6785 bytes
images/logos/profitbricks.png | Bin 0 -> 4942 bytes
images/logos/tor.png | Bin 0 -> 9704 bytes
index.html | 111 ++++++++
news.html | 20 ++
tools.html | 62 +++++
who.html | 62 +++++
86 files changed, 3611 insertions(+)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..31d6218
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,5 @@
+*.sw[p-z]
+*~
+#*
+
+/_site
diff --git a/README b/README
new file mode 100644
index 0000000..69e30dd
--- /dev/null
+++ b/README
@@ -0,0 +1,55 @@
+Source for the reproducible-builds.org website
+==============================================
+
+The website for reproducible-builds.org is made with [Jekyll]. It has
+been initially created and tested with version 2.2.0 in Debian unstable
+available in the `jekyll` package.
+
+The boilerplate CSS is provided by [Skeleton].
+
+[Jekyll]: http://jekyllrb.com/
+[Skeleton]: http://www.getskeleton.com/
+
+Viewing the website
+-------------------
+
+It's possible to view the website while making changes:
+
+ $ jekyll serve --watch
+
+A local webserver will be started which can be accessed using a browser
+to see changes as they are made.
+
+Build the website
+-----------------
+
+Building the website is made by running:
+
+ $ jekyll build
+
+The result will be available in the `_site` directory.
+
+News
+----
+
+News are made using Jekyll blog posts. Adding news is a matter of
+creating new pages in th `_posts` directory.
+
+Documentation
+-------------
+
+The documentation homepage is in `docs.html`. Individual pages are kept
+in the `_docs` folder.
+
+The order in the index and the title of subsection is defined in
+`_data/docs.yml`. The order defined using permalinks (and not
+file names).
+
+Projects
+--------
+
+The list of project involved in reproducible builds is kept as YAML
+in `_data/projects.yml`.
+
+Logos must be in the `images/logos` folder. Images should be 124×124
+pixels large.
diff --git a/_config.yml b/_config.yml
new file mode 100644
index 0000000..883e8fd
--- /dev/null
+++ b/_config.yml
@@ -0,0 +1,22 @@
+markdown: kramdown
+highlighter: pygments
+permalink: /news/:year/:month/:day/:title/
+
+# Site settings
+title: reproducible-builds.org
+email: contact at reproducible-builds.org
+description: |
+ “Reproducible builds” aim to provide a verifiable path from software source code to its compiled binary form.
+baseurl: ""
+url: "https://reproducible-builds.org/"
+
+collections:
+ docs:
+ output: true
+ events:
+ output: true
+
+exclude:
+- README
+- .git
+- .gitignore
diff --git a/_data/docs.yml b/_data/docs.yml
new file mode 100644
index 0000000..dd85141
--- /dev/null
+++ b/_data/docs.yml
@@ -0,0 +1,35 @@
+- title: Best practices
+ docs:
+ - plans
+ - buy-in
+ - test-bench
+- title: Get deterministic builds
+ docs:
+ - deterministic-build-systems
+ - volatile-inputs
+ - stable-inputs
+ - value-initialization
+ - version-information
+ - timestamps
+ - timezones
+ - locales
+ - archives
+ - stable-outputs
+ - randomness
+ - build-path
+- title: Define a build environment
+ docs:
+ - perimeter
+ - recording
+ - definition-strategies
+ - proprietary-os
+- title: Distribute the environment
+ docs:
+ - build-toolchain-from-source
+ - virtual-machine-drivers
+ - formal-definition
+- title: Comparison protocol
+ docs:
+ - checksums
+ - embedded-signatures
+ - sharing-certifications
diff --git a/_data/projects.yml b/_data/projects.yml
new file mode 100644
index 0000000..b11597c
--- /dev/null
+++ b/_data/projects.yml
@@ -0,0 +1,54 @@
+- name: Debian
+ url: https://www.debian.org/
+ logo: debian.png
+ resources:
+ - name: Wiki pages
+ url: https://wiki.debian.org/ReproducibleBuilds
+ - name: Continuous tests
+ url: https://reproducible.debian.net/
+- name: Tor Browser
+ url: https://www.torproject.org/
+ logo: tor.png
+ resources:
+ - name: Building guide
+ url: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingOfficialTorBrowserReleaseBinaries
+- name: Bitcoin
+ url: https://github.com/bitcoin/bitcoin
+ logo: bitcoin.png
+ resources:
+ - name: Gitian building guide
+ url: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
+- name: FreeBSD
+ url: https://www.freebsd.org/
+ logo: freebsd.png
+ resources:
+ - name: Base system
+ url: https://wiki.freebsd.org/ReproducibleBuilds
+ - name: Ports
+ url: https://wiki.freebsd.org/PortsReproducibleBuilds
+ - name: Continuous tests
+ url: https://reproducible.debian.net/freebsd/
+- name: Coreboot
+ url: http:///www.coreboot.org/
+ logo: coreboot.png
+ resources:
+ - name: Continuous tests
+ url: https://reproducible.debian.net/coreboot/
+- name: OpenWrt
+ url: https://openwrt.org/
+ logo: openwrt.png
+ resources:
+ - name: Continuous tests
+ url: https://reproducible.debian.net/openwrt/
+- name: NetBSD
+ url: https://www.netbsd.org/
+ logo: netbsd.png
+ resources:
+ - name: Continuous tests
+ url: https://reproducible.debian.net/netbsd/
+- name: Arch Linux
+ url: https://www.archlinux.org/
+ logo: archlinux.png
+ resources:
+ - name: Continuous tests
+ url: https://reproducible.debian.net/archlinux/
diff --git a/_docs/archives.md b/_docs/archives.md
new file mode 100644
index 0000000..91959f4
--- /dev/null
+++ b/_docs/archives.md
@@ -0,0 +1,167 @@
+---
+title: Archive metadata
+layout: docs
+permalink: /docs/archives/
+---
+
+Most archive formats record metadata that will capture details about the
+build environment if care is not taken. File last modification time is
+obvious, but file ordering, users, groups, numeric ids, and permissions
+can also be concerns. Tar is going to be used as the main example but
+these tips should apply to other archive formats as well.
+
+File modification times
+-----------------------
+
+Most archive formats will, be default, record file last modification
+times. Some will also record file creation times.
+
+Tar has a way to specify the modification time that must be used for all
+files:
+
+{% highlight sh %}
+$ tar --mtime='2015-10-21 00:00Z' -cf product.tar build
+{% endhighlight %}
+
+(Notice how `Z` is used to specify that time is in the UTC
+[timezone]({{ "/docs/timezones/" | prepend: site.baseurl }}).)
+
+For other achive formats, it is always possible to use `touch` to reset
+the modification times to a [predefined value]({{ "/docs/timestamps/" |
+prepend: site.baseurl }}) before creating the archive:
+
+{% highlight sh %}
+$ find build -print0 |
+ xargs -0r touch --no-dereference --date="@${SOURCE_DATE_EPOCH}"
+$ zip -r product.zip build
+{% endhighlight %}
+
+In some cases, it can be preferable to keep the original times for files
+that have not been created or modified during the build process:
+
+{% highlight sh %}
+$ find build -newermt "@${SOURCE_DATE_EPOCH}" -print0 |
+ xargs -0r touch --no-dereference --date="@${SOURCE_DATE_EPOCH}"
+$ zip -r product.zip build
+{% endhighlight %}
+
+A patch has been written to make the latter operation easier with GNU
+Tar. It is currently available in Debian since
+[tar](https://packages.qa.debian.org/tar) version 1.28-1. Hopefully it
+will be integrated upstream soon but you might want to use it with
+caution. It adds a new `--clamp-mtime` flag which will only set time
+when the file is more recent than what was given with `--mtime`:
+
+{% highlight sh %}
+# Only in Debian unstable for now
+$ tar --mtime='2015-10-21 00:00Z' --clamp-mtime -cf product.tar build
+{% endhighlight %}
+
+This has the benefit of leaving the original file modification time
+untouched.
+
+File ordering
+-------------
+
+When asked to record directories, most archive formats will read their
+content in the order returned by the filesystem which is [likely to be
+different on every run]({{ "/docs/stable-inputs/" | prepend:
+site.baseurl }}).
+
+With version 1.28, GNU Tar has gained `--sort=name` option which will
+sort filenames in a locale independent manner:
+
+{% highlight sh %}
+# Works with GNU Tar 1.28
+$ tar --sort=name -cf product.tar build
+{% endhighlight %}
+
+For older versions or other archive formats, it is possible to use
+`find` and `sort` to achieve the same effect:
+
+{% highlight sh %}
+$ find build -print0 | LC_ALL=C sort -z |
+ tar --null -T - --no-recursion -cf product.tar
+{% endhighlight %}
+
+Care must be taken to ensure that `sort` is called in the context of the
+C locale to avoid any surprises related to collation order.
+
+Users, groups and numeric ids
+-----------------------------
+
+Depending on the archive format, the user and group owning the file
+can be recorded. Sometimes it will be using a string, sometimes using
+the associated numeric ids.
+
+When files belong to predefined system groups, this is not a problem,
+but builds most often are made using regular users. Recording of the
+account name or its associated ids might be a source of reproducibility
+issues.
+
+Tar offers a way to specify the user and group owning the file. Using
+`root`/`root` and `--numeric-ids` is a safe bet, as it will effectively
+record 0 as values:
+
+{% highlight sh %}
+$ tar --owner=root --group=root --numeric-ids -cf product.tar build
+{% endhighlight %}
+
+Full example
+------------
+
+The recommended way to create a Tar archive is thus:
+
+<div class="correct">
+{% highlight sh %}
+# requires GNU Tar 1.28+
+$ tar --sort=name \
+ --mtime="@${SOURCE_DATE_EPOCH}" \
+ --owner=root --group=root --numeric-ids \
+ -cf product.tar build
+{% endhighlight %}
+</div>
+
+Post-processing
+---------------
+
+If tools do not support options to create reproducible archives, it is
+always possible to perform post-processing.
+
+[strip-nondeterminism](https://packages.debian.org/sid/strip-nondeterminism)
+already has support to normalize Zip and Jar archives. Custom scripts
+like Tor Browser's
+[re-dzip.sh](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/re-dzip.sh)
+might also be an option.
+
+Static libraries
+----------------
+
+Static libraries (`.a`) on Unix-like systems are *ar* archives. Like
+other archive formats, they contain metadata, namely timestamps, UIDs,
+GIDs, and permissions. None are actually required for using them as
+libraries.
+
+GNU `ar` and other tools from
+[binutils](https://www.gnu.org/software/binutils/) have a *deterministic
+mode* which will use zero for UIDs, GIDs, timestamps, and use consistent
+file modes for all files. It can be made the default by passing the
+`--enable-deterministic-archives` option to `./configure`. It is already
+enabled by default for some distributions[^distros-with-default] and so
+far it seemed to be pretty safe [except for
+Makefiles](https://bugs.debian.org/798804) using targets like
+`archive.a(foo.o)`.
+
+When binutils is not built with deterministic archives by default, build
+systems have to be changed to pass the right options to `ar` and
+friends. `ARFLAGS` can be set to `Dcvr` with many build systems to turn on the
+deterministic mode. Care must be also taken to pass `-D` if `ranlib` is
+used to create the function index.
+
+Another option is to do post-processing by using
+[strip-nondeterminism](https://packages.debian.org/sid/strip-nondeterminism)
+or `objcopy`:
+
+ objcopy --enable-deterministic-archives libfoo.a
+
+[^distros-with-default]: Debian since [version 2.25-6](https://tracker.debian.org/news/675691), Ubuntu since version 2.25-8ubuntu1. It is the default for Fedora 22 and Fedora 23, but it seems this will be [reverted in Fedora 24](https://bugzilla.redhat.com/show_bug.cgi?id=1195883).
diff --git a/_docs/build_path.md b/_docs/build_path.md
new file mode 100644
index 0000000..5a64564
--- /dev/null
+++ b/_docs/build_path.md
@@ -0,0 +1,31 @@
+---
+title: Build path
+layout: docs
+permalink: /docs/build-path/
+---
+
+Some tools will record the path of the source files in their output.
+
+Most compilers will write the path of the source in the debug
+information in order to locate the associated source files.
+
+Some tools have flags (like gzip's `-n`) that will prevent them to write
+the path in their output. Proposing patches to add similar feature in
+other tools might be sufficiently easy.
+
+But in most cases, post-processing will be required to either remove the
+build path or normalize it to a predefined value.
+
+For the specific case of [DWARF
+symbols](https://en.wikipedia.org/wiki/DWARF), there is currently no good
+tool to
+change them after a build to a pre-determined value[^debugedit]. A work-around is to
+[define the build path as part of the build environment]({{
+"/docs/perimeter/" | prepend: site.baseurl }}).
+
+[^debugedit]: [debugedit](https://fedoraproject.org/wiki/Releases/FeatureBuildId) can replace the path used at build time by a predefined one but it will do it by rewriting bytes in place. As this does not reorder the hash table of strings, the resulting bytes will still be different depending on the original build path.
+
+This is also problematic because this will also apply to intermediate
+source file that other tools generate. As they typically will use [random
+file names]({{ "/docs/randomness/" | prepend: site.baseurl }}), having a
+fixed build path will not be enough in such cases.
diff --git a/_docs/build_toolchain_from_source.md b/_docs/build_toolchain_from_source.md
new file mode 100644
index 0000000..92aa95d
--- /dev/null
+++ b/_docs/build_toolchain_from_source.md
@@ -0,0 +1,62 @@
+---
+title: Building from source
+layout: docs
+permalink: /docs/build-toolchain-from-source/
+---
+
+Building the tools that make the environment from source is one way to
+allow user to reproduce it. Using source directly makes it easier to
+rely on new features, and easily works on a variety of platforms. It
+might not scale well for a long list of dependencies, and asking users
+to rebuild GCC for every piece of software they use might make them
+slightly unhappy.
+
+What follows are suggestions on how to handle building the compilation
+tools from source.
+
+Building using external resources
+---------------------------------
+
+The source for the different components can be retrieved from online
+repository. Using release tarballs might be preferable as they are
+easier to cache, [mirror, checksum and verify]({{
+"/docs/volatile-inputs/" | prepend: site.baseurl }}). When retrieving
+the source from a version control system repository, it's best to have a
+precise reference to the code version. With Git, using a tag with a
+verified signature or a commit hash will work best.
+
+The compilation itself can be driven by shell scripts or an extra target
+in the project `Makefile`.
+
+Coreboot is a good example. The build documetation mandates to first run
+`make crossgcc` before building Coreboot itself.
+
+Check-in everything
+-------------------
+
+Another approach is to check the source of the entire toolchain in the
+project's version control system.
+
+This is how several integrated operating systems like *BSD are
+developped. “Building the world” will start by building the toolchain in
+the version control system before building the rest of the system.
+
+It's also how it is done for Google's internal projects. They have
+released [Bazel](http://bazel.io/) which is based on their
+internal compilation tool. Bazel is designed to drive such large scale
+builds with speed and reproducibility in mind.
+
+Outside of fully integrated operating systems or corporate environment,
+it might be hard to push the idea of adding ten or more times the actual
+code base in toolchain…
+
+Ship the toolchain as a build product
+-------------------------------------
+
+As it might be hard to ask every user to spend time rebuilding a whole
+toolchain, OpenWrt gives a good example of a middle middle ground. An
+“SDK” that can be downloaded alongside the system images which
+contains everything that is needed to build—or rebuild—extra packages.
+
+In that case the SDK becomes another build product, and it has to be
+possible to build it reproducibly.
diff --git a/_docs/buy_in.md b/_docs/buy_in.md
new file mode 100644
index 0000000..7cd1fc2
--- /dev/null
+++ b/_docs/buy_in.md
@@ -0,0 +1,108 @@
+---
+title: Buy-in
+layout: docs
+permalink: /docs/buy-in/
+---
+
+Working on reproducible builds might look like a lot of efforts with
+little gain at first. While [this apply to many types of work related
+to
+security](https://www.schneier.com/blog/archives/2008/09/security_roi_1.html),
+there are already some good arguments and testimonies
+on why *reproducible builds* matter.
+
+Resisting attacks
+-----------------
+
+In March 2015, The Intercept
+[published](https://theintercept.com/2015/03/10/ispy-cia-campaign-steal-apples-secrets/)
+from the Snowden leaks the abstract of a talk at an
+[internal CIA conference in
+2012](https://theintercept.com/document/2015/03/10/tcb-jamboree-2012-invitation/) about
+[Strawhorse: Attacking the MacOS and iOS Software Development
+Kit](https://theintercept.com/document/2015/03/10/strawhorse-attacking-macos-ios-software-development-kit/).
+The abstract clearly explains how unnamed researchers have been creating
+modified version of XCode that would—without any knowledge of the
+developper—watermark or insert spyware in the compiled applications.
+
+A few months later, a malware dubbed “XcodeGhost” has been found
+targeting developers to make them unknowingly distribute malware
+embedded in iOS applications. Palo Alto Networks
+[describes](http://researchcenter.paloaltonetworks.com/2015/09/novel-malware-xcodeghost-modifies-xcode-infects-apple-ios-apps-and-hits-app-store/) it as:
+
+> XcodeGhost is the first compiler malware in OS X. Its malicious code is
+> located in a Mach-O object file that was repackaged into some versions
+> of Xcode installers. These malicious installers were then uploaded to
+> Baidu’s cloud file sharing service for used by Chinese iOS/OS X
+> developers
+
+The purpose of reproducible builds is exactly to resist such attacks.
+Recompiling these applications with a clean compiler would have made
+the problem easily visible, especially given the size of the added
+payload.
+
+As Mike Perry and Seth Schoen explained in December 2014 during [a talk at
+31C3](https://media.ccc.de/events/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner)
+in December, problematic changes might be more subtle, and a single bit
+might be the only thing required to create a remotely exploitable
+security hole. Seth Schoen also made the demonstration of a kernel-level
+malware that would compromise the source code while it was being read by
+the compiler, without leaving any traces on disk. While to the best of
+our knowledge such attacks have not been observed in the wild,
+<strong>reproducible builds is the only way to detect them
+early</strong>.
+
+Quality assurance
+-----------------
+
+Regular tests are required to make sure that the software can be built
+reproducibly in various environments. Debian and other free software
+distributions consider that their users must be able to build the
+software they distribute. Such regular tests helps to avoid *fail to
+build from source* bugs.
+
+Build environments may evolve after a project is no longer receiving
+major developments. While working on Debian, several high impact but
+hard to detect bugs were identified by testing builds in varying
+environments. To give some examples: [a library had a different
+application binary interface for every
+build](https://bugs.debian.org/773916), [garbled strings due to
+encoding mismatch](https://bugs.debian.org/801855), [missing
+translations](https://bugs.debian.org/778486), or [changing
+dependencies](https://bugs.debian.org/778707).
+
+The constraint of having to reflect about the build environment also
+helps developers to think the relationship with external software or
+data providers. Relying on external sources with no backup plans might
+cause serious troubles in the long term.
+
+Having reproducible builds also allow to recreate matching [debug
+symbols](https://en.wikipedia.org/wiki/Debugging_data_format) for a
+distributed build which can help understanding issues in software used
+in production.
+
+“But how can I trust my compiler?”
+----------------------------------
+
+A common question related to reproducible builds is how is it possible
+to know if the build environment is not compromised if everyone is using
+the same binaries? Or how can I trust that the compiler I just built
+was not compromised by a backdoor in the compiler I used to build it?
+
+The latter is known in the academic litterature since the
+[Reflections on trusting
+trust](https://dx.doi.org/10.1145%2F358198.358210) paper from
+Ken Thompson published in 1984. It's the paper mentioned in the
+description of the talk about “Strawhorse” mentioned earlier.
+
+The technique known as [Diverse
+Double-Compilation](http://www.dwheeler.com/trusting-trust/) formally
+defined and resarched by David A. Wheeler can answer this question.
+To sum up quickly how it works: taking two compilers, one trusted and
+one under test trusted, the compiler under test is built twice,
+once with each compiler. Using the compilers created from this build,
+the compiler under test is built again. If the output is the same, then
+we have a proof that no backdoors have been inserted during the
+compilation. For this scheme to work, the output of the final
+compilations need to be the same. And that's exactly where reproducible
+builds are useful.
diff --git a/_docs/checksums.md b/_docs/checksums.md
new file mode 100644
index 0000000..27fc6d5
--- /dev/null
+++ b/_docs/checksums.md
@@ -0,0 +1,24 @@
+---
+title: Cryptographic checksums
+layout: docs
+permalink: /docs/checksums/
+---
+
+How can users know that the build they just made has successfully
+reproduced the original build?
+
+The easiest way is to make sure that the build output are always
+byte-for-byte identical. Byte for byte comparison is a trivial operation
+and can be performed in many different environments.
+
+The other benefit of having identical bytes is that it makes possible to
+use [cryptographic
+checksums](https://en.wikipedia.org/wiki/Cryptographic_hash_function).
+Such checksums are really tiny compared to the full build products. They
+are easily exchanged even in very low bandwidth situation.
+
+For example, it makes it possible to build a software release both on a
+well-connected (but hard to trust) server and on a laptop behind a bad
+mobile connection. The digital signature can be made locally on the
+laptop. As the build products will be identical, the signature will be
+valid for the files produced on the well-connected server.
diff --git a/_docs/definition_strategies.md b/_docs/definition_strategies.md
new file mode 100644
index 0000000..a5461e1
--- /dev/null
+++ b/_docs/definition_strategies.md
@@ -0,0 +1,65 @@
+---
+title: Definition strategies
+layout: docs
+permalink: /docs/definition-strategies/
+---
+
+They are multiple ways to define the build environment in a way that it
+can be distributed. The following methods are not exclusive and multiple
+aspects can be used for a single project. One can specify a reference
+Linux distribution and build a specific compiler version from source.
+
+Defining the build environment as part of the development process has a
+very desirable aspect: changes in the build environment can be vetted
+like any other changes. Updating to a new compiler version can be
+subject to reviews, automatic testing, and in case things
+break, rollback.
+
+{% comment %}
+XXX: maybe we want to add examples?
+{% endcomment %}
+
+Build from source
+-----------------
+
+One way to have users reproduce the tools used to perform the build
+is simply to have them start by building the right version of these
+tools from source.
+
+Using `make` or any other compilation driver, the required tools will be
+downloaded, built, and locally installed before compiling the software.
+
+Like any other [inputs from the network]({{ "/docs/volatile-inputs/" |
+prepend: site.baseurl }}), the content of the archive should be backed
+up and verified using cryptographic checksums.
+
+Reference distribution
+----------------------
+
+Using a specific version of free software distribution is another viable
+options for a build environment.
+
+Ideally, it should offer stable releases (like Debian, CentOS, or
+FreeBSD) to avoid having constant updates to the documentation or
+building scripts.
+
+Recording the exact versions of the installed packages might be helpful
+to diagnose issues. Some distributions also keep a complete history
+of source packages or binary packages available for later
+reinstallation.
+
+Virtual machines / containers
+-----------------------------
+
+Some aspects of the build environment can be quite simplified by using
+virtual machines or containers. With a virtual machine you can
+easily perform the build in a more controlled environment. The build
+user, system hostname, network configuration, or other aspects can be
+enforced easily on all systems.
+
+The downside is that it can introduce a lot of software that has be
+trusted somehow. For example, it's currently not possible to install
+Debian in a reproducible manner[^reproducible-install]. This makes it
+harder to compare different installations.
+
+[^reproducible-install]: Some [preliminary work](https://wiki.debian.org/ReproducibleInstalls) has been done, mainly to identify the issues. Having byte-for-byte identical installations is a requirement to make *live* distributions build in a reproducible manner, so there is some interest by multiple parties in fixing the problem.
diff --git a/_docs/deterministic_build_systems.md b/_docs/deterministic_build_systems.md
new file mode 100644
index 0000000..c767b0e
--- /dev/null
+++ b/_docs/deterministic_build_systems.md
@@ -0,0 +1,58 @@
+---
+title: Deterministic build systems
+layout: docs
+permalink: /docs/deterministic-build-systems/
+---
+
+A software cannot be easily be built reproducibly if the source varies
+depending on factors that are hard or impossible to control like the
+ordering of files on a filesystem or the current time.
+
+Drawing the line
+----------------
+
+Which aspect of the build system needs to be made deterministic is
+deeply linked to what is defined as part of the
+[build environment]({{ "/docs/perimeter/" | prepend: site.basurl }}).
+
+For example, we assume that different versions of a compiler will
+produce different output and so usage of a specific
+compiler version is mandated as part of the build environment. The same
+assumption does not necessarily hold for more simple tools like `grep`
+or `sed` where the requirement for the environment can be as loose as
+“any recent Unix-like system”.
+
+But it's hardly a good idea to mandate that the system pseudo-random
+number generator be initialized with a given value before performing a
+build, so better not have randomness affect a build output.
+
+Another concrete example on where to draw the line: there is no need to
+care about making the build system give constant output when run in
+different build paths when the build path is considered part of the
+build environment, and thus requiring rebuilds to be performed in the
+same directory as the original build.
+
+In a nutshell
+-------------
+
+The basics on how to make a build system deterministic can be summarized
+as:
+
+ * Ensure stable inputs.
+ * Ensure stable outputs.
+ * Capture as little as possible from the environment.
+
+What follows are some advices on common issues that can affect source
+code or build systems that makes multiple builds from the exact same
+source different.
+
+Disclaimer
+----------
+
+Not all problems currently have solutions. Some tools that might be used
+in a build process might require fixes to become non-deterministic. The
+Debian effort keep a list of [all issues
+found](https://reproducible.debian.net/index_issues.html) while
+investigating reproducibility problems in its 22,000+ source packages.
+While some requires changes in the package source itself, some can be
+fixed by improving or fixing the tools used to perform the builds.
diff --git a/_docs/embedded_signatures.md b/_docs/embedded_signatures.md
new file mode 100644
index 0000000..34460dd
--- /dev/null
+++ b/_docs/embedded_signatures.md
@@ -0,0 +1,54 @@
+---
+title: Embedded signatures
+layout: docs
+permalink: /docs/embedded-signatures/
+---
+
+Software that are distributed using embedded cryptographic signatures
+can pose a challenge to allow users to reproduce identical results.
+By definition, they will not be able to generate an identical signature.
+This can either be solved by making the signature part of the build
+process input or by offering tools to transform the distributed binaries
+to pristine build results.
+
+Pasting signatures
+------------------
+
+One way to handle embedded cryptographic signatures is to make the
+signature an (optional) input of the build process. When a signature
+is available, it just get copied at the right location.
+
+This enables the following workflow:
+
+1. An initial build is made by the developers who have access to the private key.
+2. The build result is signed to an external file.
+3. The signature is made part of the released source code.
+4. The build that is going to be distributed is made from the latter source.
+
+The `wireless-regdb` package in Debian is an example on [how this can be
+be
+implemented](https://sources.debian.net/src/wireless-regdb/latest/debian/rules/).
+
+Ignoring signatures
+-------------------
+
+A specific comparison tool can be made available that is able to compare
+to builds skipping the signatures. Ideally, it should also be able to
+produce cryptographic checksums to make downloading the original build
+unneeded to solely compare the results.
+
+Such a tool must be **very** easy to audit and understand. Otherwise,
+it's hard to trust that the script is not ignoring bytes that would make
+it behave differently.
+
+Stripping signatures
+--------------------
+
+Another option is to ship a tool that can strip the signatures from the
+official releases. The result can then be compared byte-for-byte with
+the results from the user.
+
+This method has the downside that it requires user to download the
+official releases to do the comparison. It's also harder to attest that
+the data that is being removed will not make the software behave
+differently.
diff --git a/_docs/formal_definition.md b/_docs/formal_definition.md
new file mode 100644
index 0000000..3243709
--- /dev/null
+++ b/_docs/formal_definition.md
@@ -0,0 +1,15 @@
+---
+title: Formal definition
+layout: docs
+permalink: /docs/formal-definition/
+---
+
+Most free software distribution are self-contained: all tools required
+to build its component are part of the distribution. In such cases, it's
+possible to specify the build environment in a machine readable format
+that can be later used to reinstall the environment.
+
+As example, the [.buildinfo control files used by
+Debian](https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification)
+tie in the same file: the sources, the generated binaries, and all
+packages used to perform the build (with the exact version number).
diff --git a/_docs/locales.md b/_docs/locales.md
new file mode 100644
index 0000000..4f775b7
--- /dev/null
+++ b/_docs/locales.md
@@ -0,0 +1,94 @@
+---
+title: Locales
+layout: docs
+permalink: /docs/locales/
+---
+
+The locale of the build system might affect the build products. While
+it is important that developers have access to error messages in the
+language of their choice, tools which output is influenced by the
+current locale can make locale source of reproducibility issues.
+
+There are many aspects regarding locales (see [GNU libc locale(1)
+manpage](http://manpages.debian.org/locale)). The ones that follow are those
+who have most often been important to consider in the context of
+reproducible builds.
+
+Time format
+-----------
+
+Several common time formatting functions will have an output depending
+on the current locale. On POSIX system the formatting will be depend on
+the `LC_CTIME` environment variable, which can be overriden by
+`LC_ALL`.
+
+For build systems, it's thus best to use `LC_ALL` directly:
+
+<div class="correct">
+{% highlight sh %}
+$ LC_ALL=C date -u -d '2015-10-21'
+Wed Oct 21 00:00:00 UTC 2015
+{% endhighlight %}
+</div>
+
+The system [timezone]({{ "/docs/timezones/" | prepend: site.baseurl }})
+and `TZ` environment variable will also affect the output of time
+formatting functions.
+
+Collation order
+---------------
+
+Common sorting functions are affected by the `LC_COLLATE` environment
+variable, which can which can be overriden by `LC_ALL`. Some locales can
+be quite surprising:
+
+This typically shows when using `sort`. The `fr_FR` locale will sort
+independently of the character case:
+
+<div class="wrong">
+{% highlight sh %}
+$ echo B a c | tr ' ' '\n' | LC_ALL=fr_FR.UTF-8 sort
+a
+B
+c
+{% endhighlight %}
+</div>
+
+The `C` locale will sort according to the byte values and is always
+available:
+
+<div class="correct">
+{% highlight sh %}
+$ echo B a c | tr ' ' '\n' | LC_ALL=C sort
+B
+a
+c
+{% endhighlight %}
+</div>
+
+Default character encoding
+--------------------------
+
+The default system character encoding will affect both the input and
+output of many tools. It is defined using the `LC_CTYPE` environment
+variable, and can also be overriden using `LC_ALL`.
+
+Here's an example when using `lynx` to convert HTML documentation into
+text:
+
+<div class="wrong">
+{% highlight sh %}
+LC_ALL=fr_FR lynx -dump -width 72 docs.html | file -
+/dev/stdin: ISO-8859 text
+{% endhighlight %}
+</div>
+
+The `C.UTF-8` pseudo-locale always to get the default strings with UTF-8
+output:
+
+<div class="correct">
+{% highlight sh %}
+LC_ALL=C.UTF-8 lynx -dump -width 72 docs.html | file -
+/dev/stdin: UTF-8 Unicode text
+{% endhighlight %}
+</div>
diff --git a/_docs/perimeter.md b/_docs/perimeter.md
new file mode 100644
index 0000000..041e700
--- /dev/null
+++ b/_docs/perimeter.md
@@ -0,0 +1,66 @@
+---
+title: What's in a build environment?
+layout: docs
+permalink: /docs/perimeter/
+---
+
+Reproducible builds does not mandate that a given piece of source code
+be turned into the same bytes in all situations. This would be
+infeasible. The output of a compiler is likely to be different from one
+version to another as better optimizations are integrated all the time.
+
+Instead, reproducible builds happen in the context of a *build
+environment*. It usually comprises the set of tools, required versions,
+and other assumptions about the operating system and its configuration.
+A description of this environment should typically be provided alongside
+any distributed binary package.
+
+Requirements
+------------
+
+What exactly makes the build environment is going to be different for
+each project. There might even be several build environments for a
+single release to accommodate different target operating systems.
+But there are some important aspects common to all environments.
+
+It should be **easy to install** a matching build environment on their
+system. Ideally it should only be made of free software available on
+public Internet sites. The best way to provide the environment is
+probably using a documented and easily understood script.
+
+It should be **auditable**. It must be easy to understand what tools
+are part of the build environment, and ideally review and rebuild them.
+
+Content
+-------
+
+{% comment %}
+XXX: Not really happy with this section. Please help!
+-- Lunar
+{% endcomment %}
+
+What is exactly defined as the build environment needs to be properly
+specified as this will determine how much of the build system will need
+to be [made deterministic]({{ "/docs/deterministic-build-systems/" |
+prepend: site.baseurl }}).
+
+The defined environment will have the list of the tools used by the
+build process and versions that must be used.
+
+The rest can be different from one project to the next, as long as it
+can be reproduced by interested users. To give some examples:
+
+ * specific operating system if cross-compiling is not supported),
+ * build system architecture if cross-compiling is not supported),
+ * directory where the build must happen,
+ * name of the user running the build,
+ * locale,
+ * timezone,
+ * specific environment variables (like
+ [`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/)).
+
+Using virtual machines or containers as the recommended build
+environment can make it easier to ensure a specific operating system or
+user configuration. But they might also hide some assumptions on the
+environment, like specific optimizations enabled because of the [system
+CPU type](https://trac.torproject.org/projects/tor/ticket/12238#comment:4).
diff --git a/_docs/plans.md b/_docs/plans.md
new file mode 100644
index 0000000..a3a4106
--- /dev/null
+++ b/_docs/plans.md
@@ -0,0 +1,69 @@
+---
+title: Making plans
+layout: docs
+permalink: /docs/plans/
+---
+
+The idea of “reproducible” builds is to empower anyone to verify that no
+flaws have been introduced during the build process by reproducing
+byte-for-byte identical binary packages from a given source.
+
+Achieving reproducible builds require cooperation from multiple roles
+involved in software production. On small projects, all these roles
+might be carried by a single person, but it helps to differentiate the
+responsibilities.
+
+Getting a deterministic build system
+------------------------------------
+
+In order for software to allow reproducible builds, the source code must
+not introduce uncontrollable variations in the build output.
+
+Things will work better if such variations are discovered before users
+are confronted with unreproducible binaries. Setting up a test
+protocol in which rebuilds are performed under variations in the
+environment (aspects like time, *username*, CPU, system version,
+filesystems amongst many others) will greatly help.
+
+Defining a build environment
+----------------------------
+
+As different versions of compilation tools are likely to produce
+different outputs, users must be able to recreate a build environment
+close enough to the original build. It is not required that the
+toolchain[^toolchain] itself be byte-for-byte identical, but its
+output has to stay the same.
+
+The build environment can either be defined while the software is being
+developped or recorded at build time.
+
+Distributing the build environment
+----------------------------------
+
+Users need to be able to know what build environment needs to be setup
+to rebuild the software.
+
+If the build environment is defined ahead and part of the source code,
+then no further steps are required.
+
+In other cases, it needs to be made available alongside the binaries.
+The ideal form is a description that can be both understand by human and
+machine to make automatic verification possible, while making people
+able to review that the environment is sane.
+
+Providing a comparison protocol
+-------------------------------
+
+Users must have an easy way to recreate the build environment, get the
+source code, perform the build, and compare the results.
+
+Ideally, the comparison protocol should be simply to see if resulting
+bytes are identical. Comparing directly bytes or cryptographic hashes
+function is easy to do and understand.
+
+Other technologies might require removing cryptographic signatures or
+ignore specific parts. Such operations must be both documented and
+scripted. The rationale and code must be easy to understand by
+reviewers.
+
+[^toolchain]: By *toolchain*, we mean any piece of software needed to create the build output.
diff --git a/_docs/proprietary_os.md b/_docs/proprietary_os.md
new file mode 100644
index 0000000..d048925
--- /dev/null
+++ b/_docs/proprietary_os.md
@@ -0,0 +1,39 @@
+---
+title: Proprietary operating systems
+layout: docs
+permalink: /docs/proprietary-os/
+---
+
+
+It's hard to assess that proprietary operating systems have not been
+tampered with. They also require non-free compilation tools that can be
+hard to get for users.
+
+The good news is that for some cases, we have free software tools which
+are able to cross-compile software for proprietary operating systems
+from free operating systems. Both Bitcoin and Tor Browser have pioneered
+the technic to build their Windows and Mac OS X versions.
+
+Windows
+-------
+
+For Windows, [ming-w64](http://mingw-w64.org/) will build Windows
+binaries from POSIX compatible operating systems.
+
+[NSIS](http://nsis.sourceforge.net/) can be used to create integrated
+installation package.
+
+Both are readily available in several free software distributions.
+
+Mac OS X
+--------
+
+crosstool-ng [should work](https://bugs.torproject.org/9711#comment:73)
+to build software for Mac OS X. Sadly this seems to be require a
+non-redistributable part of the Apple SDK. It can extracted from XCode
+which can be downloaded at no charge.
+
+Software from Mac OS X is often distributed as disk images (`.dmg`)
+which can be created under GNU/Linux, but it seems to [require multiple
+tools at the
+moment](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/ddmg.sh).
diff --git a/_docs/randomness.md b/_docs/randomness.md
new file mode 100644
index 0000000..03e0bf4
--- /dev/null
+++ b/_docs/randomness.md
@@ -0,0 +1,23 @@
+---
+title: Randomness
+layout: docs
+permalink: /docs/randomness/
+---
+
+Random data will make builds unreproducible and must be avoided.
+
+If random-like input is required, the solution is to use a predetermined value
+to seed a [pseudo-random number
+generator](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). This
+value can be read from some file, a changelog or the version control system.
+
+When Link-Time Optimizations are turned on, GCC users will write random
+identifiers to binary objects it creates. Using `-frandom-seed` can be used for
+this particular case. As it will hash arbitrary data, passing the file name
+should work in most cases.
+
+Some compilation tools will write intermediate temporary files. This might lead
+to reproducibility issues if paths get embedded in the final output. There's no
+general solutions for such cases, better fix the code directly. One way is to
+use the `.file` assembler directive [like it has been done in
+O'Caml](https://sources.debian.net/src/ocaml/4.02.3-5/debian/patches/0010-Add-a-.file-directive-to-generated-.s-files.patch/).
diff --git a/_docs/recording.md b/_docs/recording.md
new file mode 100644
index 0000000..e6c54c9
--- /dev/null
+++ b/_docs/recording.md
@@ -0,0 +1,27 @@
+---
+title: Recording the build environment
+layout: docs
+permalink: /docs/recording/
+---
+
+It is been customary in user facing software to provide a way for
+developpers investigating bugs to learn how the software has been
+built. The “about dialog” or output of `--version` would contain
+information about the build environment.
+
+In the context of reproducible builds, we either actively make aspects
+of the build environment irrelevant to the build output, or ensure they
+are mandatory to rebuild the software exactly as it distributed.
+
+Any irrelevant information should not be recorded. This depends on what
+has been made [part of the build environment]({{ "/docs/perimeter/" |
+prepend: site.baseurl }}), but likely includes information such as date
+and time of the build, build system hostname, path, network
+configuration, CPU type, memory size, environment variables…
+
+The rest of the build environment should either be defined as part of
+the development process or recorded during the build process.
+
+Anything recorded is best recorded as a separate build product that can
+be easily ignored or distributed separately. This will help identify
+which variation is irrelevant to the software itself.
diff --git a/_docs/sharing_certifications.md b/_docs/sharing_certifications.md
new file mode 100644
index 0000000..7303ef3
--- /dev/null
+++ b/_docs/sharing_certifications.md
@@ -0,0 +1,22 @@
+---
+title: Sharing certifications
+layout: docs
+permalink: /docs/sharing-certifications/
+---
+
+How could users gain trust that a build has not been compromised by
+exchanging certifications attesting that they all have been able to
+get the same build results?
+
+Debian is thinking of allowing [multiple Debian Developers to upload
+signatures](https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification#buildinfo_signatures)
+attesting that they have been to reproduce a build.
+
+The question is also related to the work lead by Ben Laurie on [binary
+transparency](https://groups.google.com/forum/#!forum/binary-transparency).
+The idea is to have an append-only log similar to [Certificate
+Transparency](https://www.certificate-transparency.org/) which could be
+used to authenticate binaries.
+
+More research is required in this area to make reproducible builds more
+effective in detecting compromise early.
diff --git a/_docs/stable_inputs.md b/_docs/stable_inputs.md
new file mode 100644
index 0000000..61a44eb
--- /dev/null
+++ b/_docs/stable_inputs.md
@@ -0,0 +1,90 @@
+---
+title: Stable order for inputs
+layout: docs
+permalink: /docs/stable-inputs/
+---
+
+If building your software requires processing several inputs at once,
+make sure the order is stable accross builds.
+
+A typical example is creating an archive from the content of a
+directory. Most filesystems do not guarantee that listing files in a
+directory will always result in the same order.
+
+Example Makefile
+----------------
+
+The following `Makefile` will result in unreproducible
+builds[^sorted-wildcard]:
+
+<div class="wrong">
+{% highlight makefile %}
+SRCS = $(wildcard *.c)
+tool: $(SRCS:.c=.o)
+ $(CC) -o $@ $^
+{% endhighlight %}
+</div>
+
+Solutions:
+
+a) List all inputs explicitely and ensure they will be processed in that order.
+
+<div class="correct">
+{% highlight makefile %}
+SRCS = util.c helper.c main.c
+tool: $(SRCS:.c=.o)
+ $(CC) -o $@ $^
+{% endhighlight %}
+</div>
+
+b) Sort inputs:
+
+<div class="correct">
+{% highlight makefile %}
+SRCS = $(sort $(wildcard *.c))
+tool: $(SRCS:.c=.o)
+ $(CC) -o $@ $^
+{% endhighlight %}
+</div>
+
+[^sorted-wildcard]: GNU Make used to sort the output of the [wildcard](https://www.gnu.org/software/make/manual/html_node/Wildcard-Function.html#Wildcard-Function) function until version 3.82.
+
+Watch out for locale-related issues
+-----------------------------------
+
+When sorting inputs, one must ensure that the sorting order is not affected by
+the system locale settings. For example, some locale will not make differences
+between uppercase and lowercase.
+
+For example, `tar` will by default use the filesystem order when
+descending directories:
+
+<div class="wrong">
+{% highlight sh %}
+$ tar -cf archive.tar src
+{% endhighlight %}
+</div>
+
+A solution is to use `find` and `sort` but the following might still
+have differences when run under different locales:
+
+<div class="wrong">
+{% highlight sh %}
+$ find src -print0 | sort -z |
+ tar --null -T - --no-recursion -cf archive.tar
+{% endhighlight %}
+</div>
+
+The locale used to sort files must be specified to avoid any surprises:
+
+<div class="correct">
+{% highlight sh %}
+$ find src -print0 | LC_ALL=C sort -z |
+ tar --null -T - --no-recursion -cf archive.tar
+{% endhighlight %}
+</div>
+
+This might not be the only changes required for [Tar and other archive
+formats]({{ "/docs/archives/" | prepend: site.baseurl }}) as they
+usually embed more metadata.
+problems.
diff --git a/_docs/stable_outputs.md b/_docs/stable_outputs.md
new file mode 100644
index 0000000..fd181b2
--- /dev/null
+++ b/_docs/stable_outputs.md
@@ -0,0 +1,44 @@
+---
+title: Stable order for outputs
+layout: docs
+permalink: /docs/stable-outputs/
+---
+
+Data structures such as [Perl
+hashes](http://perldoc.perl.org/functions/keys.html), [Python
+dictionaries](https://docs.python.org/2/library/stdtypes.html#mapping-types-dict),
+or [Ruby Hash objects](http://ruby-doc.org/core/Hash.html) will list their keys
+in a different order on every run to limit [algorithmic complexity
+attacks](http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks).
+
+The following Perl code will output the list in a different order on every run:
+
+<div class="wrong">
+{% highlight perl %}
+foreach my $package (keys %deps) {
+ print MANIFEST, "$package: $deps[$packages]";
+}
+{% endhighlight %}
+</div>
+
+To get a deterministic output, the easiest way is to explicitely sort the keys:
+
+<div class="correct">
+{% highlight perl %}
+foreach my $package (sort keys %deps) {
+ print MANIFEST, "$package: $deps[$packages]";
+}
+{% endhighlight %}
+</div>
+
+For Perl, it is possible to set `PERL_HASH_SEED=0` in the environment. This
+will result in hash keys always being in the same order. See
+[perlrun(1)](http://perldoc.perl.org/perlrun.html) for more information.
+
+Python users can similarily set the environment variable
+[PYTHONHASHSEED](https://docs.python.org/2/using/cmdline.html#envvar-PYTHONHASHSEED).
+When set to a given integer value, orders in dictionnaries will be the same on
+every run.
+
+Beware that the [locale settings]({{ "/docs/locales/ | prepend: site.baseurl }})
+might affect the output of some sorting functions or the `sort` command.
diff --git a/_docs/test_bench.md b/_docs/test_bench.md
new file mode 100644
index 0000000..d9d52ef
--- /dev/null
+++ b/_docs/test_bench.md
@@ -0,0 +1,51 @@
+---
+title: Test bench
+layout: docs
+permalink: /docs/test-bench/
+---
+
+It is important to detect reproducibility problems in the build system
+before users to avoid any false alarms.
+
+The method is usually as follow:
+
+ 1. Build a first time.
+ 2. Save the result.
+ 3. Perform as many changes to the environment as possible.
+ 4. Build a second time.
+ 5. Compare the results.
+
+[diffoscope](http://diffoscope.org/) is a tool that has been initially
+designed to help understand issues when comparing build results.
+
+Here is a list of interesting variations that have been identified so
+far:
+
+ * date and time,
+ * build path,
+ * hostname,
+ * domain name,
+ * filesystem,
+ * environment variables,
+ * timezone,
+ * language,
+ * locale,
+ * user name,
+ * user id,
+ * group name,
+ * group id,
+ * kernel version,
+ * umask,
+ * CPU type,
+ * number of CPU cores.
+
+[disorderfs](https://packages.debian.org/sid/disorderfs) can help to
+test variations due to the filesystem in a deterministic manner.
+
+The list of [variations tested for
+Debian](https://reproducible.debian.net/reproducible.html#variation) is
+available as an actual example.
+
+{% comment %}
+XXX: We should probably mention reproducible.debian.net, add contact info and mention ProfitBricks.
+{% endcomment %}
diff --git a/_docs/timestamps.md b/_docs/timestamps.md
new file mode 100644
index 0000000..d6f7de0
--- /dev/null
+++ b/_docs/timestamps.md
@@ -0,0 +1,70 @@
+---
+title: Timestamps
+layout: docs
+permalink: /docs/timestamps/
+---
+
+Timestamps make the biggest source of reproducibility issues. Many build
+tools fancy recording the current date and time. The filesystem does,
+and [most archive formats]({{ "/docs/archives/" | prepend: site.baseurl
+}}) will happily record modification times on top of their own
+timestamps. It is also customary to record the date of the build in the
+software itself…
+
+Timestamps are best avoided
+---------------------------
+
+The time of the build has usually been used as an approximate way
+to know which version of the source has been built, and which tools had
+been used to do it. With reproducible builds, recording the time of the
+build becomes meaningless: on one side, the source code needs to be
+tracked more accurately that just a time, and the build environment
+needs to be defined or extensively recorded.
+
+If a date is required to give users an idea on when the software was
+made, it is better to use a date that is relevant to the source code
+instead of the build: old software can always be built later. Like
+[version information]({{ "/docs/version-information/" | prepend:
+site.baseurl }}), it's best to extract such a date from the revision
+control system or from a *changelog*.
+
+External tools
+--------------
+
+Some tools used in build processes, like code or documentation
+generator, write timestamps which will create unreproducible build
+products.
+
+The Debian reproducible builds effort proposed the
+`SOURCE_DATE_EPOCH` environment variable to address the problem. Tools
+that support it[^list] will use its value—a number of seconds since January 1st
+1970, 00:00 UTC—when set instead of the current date and time. The
+variable has been [formally
+defined](https://reproducible-builds.org/specs/source-date-epoch/) in
+the hope of wider adoption.
+
+[^list]: As of 2015-10-26, the following tools are known to support `SOURCE_DATE_EPOCH`: help2man, Sphinx. And [more where modified in Debian](https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Reading_the_variable) already.
+
+Changes required to support `SOURCE_DATE_EPOCH` are usually fairly
+small and easy to write. Patches for tools which don't yet support the
+environment variable have been usually well received and help all users
+wanting *reproducible builds*.
+
+In case where that's not possible, an option is to do post processing on
+the outputs. The idea is either to remove the timestamps entirely or
+normalize them to a predetermined date and time.
+[strip-nondeterminism](https://packages.debian.org/sid/strip-nondeterminism)
+was designed as an extensible program to perform such normalizations on
+a various file formats.
+
+Another option is to run these tools using
+[libfaketime](http://www.code-wizards.com/projects/libfaketime/).
+This library is loaded through the `LD_PRELOAD` environment variable and
+will intercept function calls retrieving the current time of day to
+reply instead a predefined date and time. In some cases, it works
+just fine and can solve problems without requiring many
+changes to a given build system. But if any part of the build process is
+relying on time differences, things will start to go wrong. One case
+of a bad interaction between `libfaketime` and parallel
+compilation has been identified as a source of [reproducibility issue in
+the Tor Browser](https://bugs.torproject.org/12240). So beware.
diff --git a/_docs/timezones.md b/_docs/timezones.md
new file mode 100644
index 0000000..aa4b815
--- /dev/null
+++ b/_docs/timezones.md
@@ -0,0 +1,66 @@
+---
+title: Timezones
+layout: docs
+permalink: /docs/timezones/
+---
+
+Unless the build timezone is [made part of the build environment]({{
+"/docs/perimeter/" | prepend: site.baseurl }}), care must be taken to
+get the build output when the build is run in two different timezones.
+
+Avoid writing the current timezone
+----------------------------------
+
+Some tools will write date and time with the associated timezone:
+
+<div class="wrong">
+{% highlight sh %}
+$ LC_ALL=C date -d'@2147483647' --rfc-2822
+Tue, 19 Jan 2038 04:14:07 +0100
+{% endhighlight %}
+</div>
+
+Despite being given a pre-determined time in the form of an [Unix
+time](https://en.wikipedia.org/wiki/Unix_time) (also called *epoch*),
+this output would fail to be reproducible in a different timezone
+than UTC+0100. The easy solution is to set the required environment
+variable to force tools to use UTC as the timezone:
+
+<div class="correct">
+{% highlight sh %}
+$ LC_ALL=C date -u -d'@2147483647' --rfc-2822
+Tue, 19 Jan 2038 03:14:07 +0000
+{% endhighlight %}
+</div>
+
+When there is no dedicated option, it is most often possible to set the `TZ`
+environment variable:
+
+<div class="correct">
+{% highlight sh %}
+$ TZ=UTC LC_ALL=C date -d'@2147483647' --rfc-2822
+Tue, 19 Jan 2038 03:14:07 +0000
+{% endhighlight %}
+</div>
+
+A related concern is for formats which don't contain timezone
+information. Zip archives are a good example: the same timezone must
+always be used to unpack them to prevent variations on the file
+modification times.
+
+Use date string with timezone information
+-----------------------------------------
+
+Time strings like “Wed, 21 Oct 2015 11:18:50” are inherently ambigious.
+For which timezone does it apply? How should it be understood?
+
+In the context of reproducible builds, it's best if time strings all
+contain timezone information. A fallback option is to assume they are all
+specificied as UTC.
+
+If times trings without timezone specification are parsed in the
+timezone of the build system, hard to understand behavior might happen.
+An example is extra hours when doing time computations accross two days
+with different daylight saving changes. As different timezones have
+different policies, one user might get different results depending on
+the timezone used to perform the build.
diff --git a/_docs/value_initialization.md b/_docs/value_initialization.md
new file mode 100644
index 0000000..48e4ad6
--- /dev/null
+++ b/_docs/value_initialization.md
@@ -0,0 +1,36 @@
+---
+title: Value initialization
+layout: docs
+permalink: /docs/value-initialization/
+---
+
+In languages which don't initialize values, this needs to be explicitely
+done in order to avoid capturing what random bytes are in memory when
+run.
+
+An
+[example](http://review.coreboot.org/gitweb?p=coreboot.git;a=commitdiff;h=2d119a3f01eee6c4e86248b17b4c9ce14ab77836)
+taken from Coreboot:
+
+![diffoscope output of the two different builds of the same Coreboot image]({{ "/images/docs/uninitialized_memory.png" | prepend: site.basurl }})
+
+The code used to write a data structure directly without initializing
+all its fields. The fix was pretty simple once identified:
+
+{% highlight diff %}
+--- a/util/bimgtool/bimgtool.c
++++ b/util/bimgtool/bimgtool.c
+@@ -160,7 +160,7 @@ static const struct crc_t crc_type = {
+ static int write_binary(FILE *out, FILE *in, struct bimg_header *hdr)
+ {
+ static uint8_t file_buf[MAX_RECORD_BYTES];
+- struct bimg_data_header data_hdr;
++ struct bimg_data_header data_hdr = { 0 };
+ size_t n_written;
+
+ data_hdr.dest_addr = hdr->entry_addr;
+{% endhighlight %}
+
+Usage of instrumentation tools able to detect such cases like
+[Valgrind](http://www.valgrind.org/) should help identifying such
+problems.
diff --git a/_docs/version_information.md b/_docs/version_information.md
new file mode 100644
index 0000000..dca49ba
--- /dev/null
+++ b/_docs/version_information.md
@@ -0,0 +1,22 @@
+---
+title: Version information
+layout: docs
+permalink: /docs/version-information/
+---
+
+Version information embedded in the software need to be made
+deterministic. Counter-examples are using the current date or an
+incremental build counter.
+
+The date and time of the build itself is hardly of value as an old
+source code can always be compiled long after it has been released.
+It's best when version information give a good indication of what source
+code has been built.
+
+The version number can come from a dedicated source file, a *changelog*,
+or from a version control system. If a date is needed, it can be
+extracted from the *changelog* or the version control system. A
+cryptographic checksum can also help to pinpoint the exact source
+content. This makes [Git](https://git-scm.com/) commit ids good
+candidates as part of version information.
+
diff --git a/_docs/virtual_machine_drivers.md b/_docs/virtual_machine_drivers.md
new file mode 100644
index 0000000..fe644be
--- /dev/null
+++ b/_docs/virtual_machine_drivers.md
@@ -0,0 +1,60 @@
+---
+title: Virtual machine drivers
+layout: docs
+permalink: /docs/virtual-machine-drivers/
+---
+
+If the build environment is defined using a reference free operating
+system, forcing users to reinstall an entire computer just to reproduce
+a build is a lot to ask.
+
+Thankfully, nowadays we have virtual machine and containers which can
+give easy access to wide range of operating systems for a small
+overhead. Several tools have been designed to help driving virtual
+machines and containers, some with the explicit goal of reproducible
+builds in mind.
+
+Gitian
+------
+
+[Gitian](https://gitian.org/) is the tool [used by
+Bitcoin](https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md)
+and the Tor Browser. It either drives a Linux container using LXC, or a
+virtual machine using KVM.
+
+Gitian takes
+“[descriptors](https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/)”
+as input which tells which base GNU/Linux distribution to use, which
+packages to install, which Git remotes must be fetched, any other input
+files, and a build script to be run with all of that. As explained
+earlier, using a virtual machine helps to get rid of several extra
+variations that can happen from one system to the next. But this is
+more complicated to setup for users.
+
+Docker
+------
+
+Making containers easy to setup and use is the problem that Docker is trying to solve.
+`Dockerfiles` are used to describe how to create a container, and how
+applications can be run in there.
+
+A tool often used in Docker images, `gosu` can be [built reproducibly
+using Docker](https://github.com/tianon/gosu/blob/master/Dockerfile).
+Using the reference container made available to build Go applications,
+it then installs the necessary dependencies, and calls the Go compiler
+in that environment which should be pretty much the same all the time.
+
+To be sure that the base compiler is the same, one could use the fact
+that Docker images can actually be addressed by a hash of their content.
+Another option is to build the Docker image itself in a reproducible
+manner, something that can be done using
+[Bazel](http://bazel.io/docs/be/docker.html).
+
+Vagrant
+-------
+
+[Vagrant](https://www.vagrantup.com/) is another tool, written in Ruby,
+that can drive virtual machines with VirtualBox. It can also be used to
+get a controlled build environment. The upside of Vagrant and VirtualBox
+is that they works on Mac OS X and Windows, and so this might help more
+users to actually check that a build has not been tempered with.
diff --git a/_docs/volatile_inputs.md b/_docs/volatile_inputs.md
new file mode 100644
index 0000000..8e563ab
--- /dev/null
+++ b/_docs/volatile_inputs.md
@@ -0,0 +1,26 @@
+---
+title: Volatile inputs can disappear
+layout: docs
+permalink: /docs/volatile-inputs/
+---
+
+Inputs from the network—even if it doesn’t seem like
+it—are volatile. It's best to make a build system not rely
+on remote data.
+
+If it must be the case, then:
+
+ 1. ensure integrity using cryptographic checksums,
+ 2. keep backups.
+
+Ideally, a fallback location should be available with the backups.
+
+A good example is how the [FreeBSD](https://www.freebsd.org/) ports
+work. Port descriptions
+contain a list of
+[`MASTER_SITES`](https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites),
+a list of files to be retrieved in `DISTFILES`, and a `distinfo` file
+with cryptographic checksums for each of these files. The FreeBSD
+infrastructure ensure that a copy of all *distfiles* are kept available
+on a mirror network. When building a port, the files will be downloaded
+from there if the original *master site* is unreachable.
diff --git a/_events/athens2015.html b/_events/athens2015.html
new file mode 100644
index 0000000..5dc241a
--- /dev/null
+++ b/_events/athens2015.html
@@ -0,0 +1,33 @@
+---
+layout: page
+title: Athens 2015
+permalink: /events/athens2015/
+event_date: 2015-12-01
+event_date_string: December 1-3rd 2015
+event_location: Athens, Greece
+event_summary: A three days workshop with invited participants from more than 15 different free software projects!
+---
+
+<div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns text">
+ <p>{{ page.event_summary }}</p>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
+ <h2>Location</h2>
+ </div>
+ <div class="eight columns text">
+ <p>{{ page.event_location }}</p>
+ <p><em>More details should be announced soon.</em></p>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
+ <h2>Sponsors</h2>
+ </div>
+ <div class="eight columns text">
+ <p><em>To be announced.</em></p>
+ </div>
+</div>
diff --git a/_includes/docs_contents.html b/_includes/docs_contents.html
new file mode 100644
index 0000000..4a73807
--- /dev/null
+++ b/_includes/docs_contents.html
@@ -0,0 +1,8 @@
+<div class="hide-on-mobiles">
+ <aside>
+ {% for section in site.data.docs %}
+ <h4>{{ section.title }}</h4>
+ {% include docs_ul.html items=section.docs %}
+ {% endfor %}
+ </aside>
+</div>
diff --git a/_includes/docs_contents_mobile.html b/_includes/docs_contents_mobile.html
new file mode 100644
index 0000000..d233a15
--- /dev/null
+++ b/_includes/docs_contents_mobile.html
@@ -0,0 +1,10 @@
+<div class="show-on-mobiles">
+ <select onchange="if (this.value) window.location.href=this.value">
+ <option value="">Navigate the docs…</option>
+ {% for section in site.data.docs %}
+ <optgroup label="{{ section.title }}">
+ {% include docs_option.html items=section.docs %}
+ </optgroup>
+ {% endfor %}
+ </select>
+</div>
diff --git a/_includes/docs_option.html b/_includes/docs_option.html
new file mode 100644
index 0000000..b2bf969
--- /dev/null
+++ b/_includes/docs_option.html
@@ -0,0 +1,11 @@
+{% assign items = include.items %}
+
+{% for item in items %}
+ {% assign item_url = item | prepend:"/docs/" | append:"/" %}
+
+ {% for p in site.docs %}
+ {% if p.url == item_url %}
+ <option value="{{ p.url | prepend: site.baseurl }}">{{ p.title }}</option>
+ {% endif %}
+ {% endfor %}
+{% endfor %}
diff --git a/_includes/docs_ul.html b/_includes/docs_ul.html
new file mode 100644
index 0000000..74d9ff2
--- /dev/null
+++ b/_includes/docs_ul.html
@@ -0,0 +1,21 @@
+{% assign items = include.items %}
+
+<ul>
+{% for item in items %}
+ {% assign item_url = item | prepend:"/docs/" | append:"/" %}
+
+ {% if item_url == page.url %}
+ {% assign c = "current" %}
+ {% else %}
+ {% assign c = "" %}
+ {% endif %}
+
+ {% for p in site.docs %}
+ {% if p.url == item_url %}
+ <li class="{{ c }}"><a href="{{ p.url | prepend: site.baseurl }}">{{ p.title }}</a></li>
+ {% break %}
+ {% endif %}
+ {% endfor %}
+
+{% endfor %}
+</ul>
diff --git a/_includes/footer.html b/_includes/footer.html
new file mode 100644
index 0000000..7f9f6a5
--- /dev/null
+++ b/_includes/footer.html
@@ -0,0 +1,50 @@
+<footer class="site-footer">
+ <div class="row">
+ <div class="four columns">
+ <h2 class="footer-heading">reproducible<span class="punctuation">-</span>builds<span class="punctuation">.org</span></h2>
+ <p>{{ site.description }}</p>
+ </div>
+ <div class="four columns">
+ <p>
+ <a href="https://twitter.com/ReproBuilds">
+ <span class="icon twitter">
+ <svg version="1.1" class="twitter-icon-svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+ viewBox="0 0 16 16" enable-background="new 0 0 16 16" xml:space="preserve">
+ <path fill="#C2C2C2" d="M15.969,3.058c-0.586,0.26-1.217,0.436-1.878,0.515c0.675-0.405,1.194-1.045,1.438-1.809
+ c-0.632,0.375-1.332,0.647-2.076,0.793c-0.596-0.636-1.446-1.033-2.387-1.033c-1.806,0-3.27,1.464-3.27,3.27
+ c0,0.256,0.029,0.506,0.085,0.745C5.163,5.404,2.753,4.102,1.14,2.124C0.859,2.607,0.698,3.168,0.698,3.767
+ c0,1.134,0.577,2.135,1.455,2.722C1.616,6.472,1.112,6.325,0.671,6.08c0,0.014,0,0.027,0,0.041c0,1.584,1.127,2.906,2.623,3.206
+ C3.02,9.402,2.731,9.442,2.433,9.442c-0.211,0-0.416-0.021-0.615-0.059c0.416,1.299,1.624,2.245,3.055,2.271
+ c-1.119,0.877-2.529,1.4-4.061,1.4c-0.264,0-0.524-0.015-0.78-0.046c1.447,0.928,3.166,1.469,5.013,1.469
+ c6.015,0,9.304-4.983,9.304-9.304c0-0.142-0.003-0.283-0.009-0.423C14.976,4.29,15.531,3.714,15.969,3.058z"/>
+ </svg>
+ </span>
+ <span class="username">ReproBuilds</span>
+ </a>
+ </p>
+ <p>
+ <code>$ git clone https://reproducible-builds.org/website.git</code>
+ </p>
+ <p>
+ Content licensed under <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a>.
+ </p>
+ <p>
+ Logos and trademarks belongs to their respective owners.
+ </p>
+ </div>
+ <div class="four columns">
+ <p>
+ <a href="{{ "/who/" | prepend: site.baseurl }}">Projects</a> working on reproducible builds:
+ </p>
+ <ul>
+ <li>
+ {% for project in site.data.projects %}
+ <a href="{{ project.url }}">{{ project.name }}</a>{% unless forloop.last %},{% endunless %}{% endfor %}.
+ </li>
+ <li>
+ Get in <a href="mailto:contact at reproducible-builds.org">touch</a> if you want to tell us about yours!
+ </li>
+ </ul>
+ </div>
+ </div>
+</footer>
diff --git a/_includes/head.html b/_includes/head.html
new file mode 100644
index 0000000..56c952e
--- /dev/null
+++ b/_includes/head.html
@@ -0,0 +1,15 @@
+<head>
+ <meta charset="utf-8">
+ <title>{% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %}</title>
+ <meta name="description" content="{{ site.description }}">
+ <link rel="canonical" href="{{ page.url | replace:'index.html','' | prepend: site.baseurl | prepend: site.url }}">
+ <link rel="vcs-git" href="https://reproducible-builds.org/website.git" title="Git repository" />
+
+ <meta name="viewport" content="width=device-width, initial-scale=1">
+
+ <!-- Custom CSS -->
+ <link rel="stylesheet" href="{{ "/css/normalize.css" | prepend: site.baseurl }}">
+ <link rel="stylesheet" href="{{ "/css/skeleton.css" | prepend: site.baseurl }}">
+ <link rel="stylesheet" href="{{ "/css/main.css" | prepend: site.baseurl }}">
+
+</head>
diff --git a/_includes/header.html b/_includes/header.html
new file mode 100644
index 0000000..3dd4cfc
--- /dev/null
+++ b/_includes/header.html
@@ -0,0 +1,27 @@
+<header class="site-header">
+ <div class="container">
+ <div class="row">
+ <a class="site-title" href="{{ site.baseurl }}/">reproducible<span class="punctuation">-</span>builds<span class="punctuation">.org</span></a>
+
+ <nav class="site-nav">
+ <a href="#" class="menu-icon">
+ <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+ viewBox="0 0 18 15" enable-background="new 0 0 18 15" xml:space="preserve">
+ <path fill="#5fb0f3" d="M18,1.484c0,0.82-0.665,1.484-1.484,1.484H1.484C0.665,2.969,0,2.304,0,1.484l0,0C0,0.665,0.665,0,1.484,0
+ h15.031C17.335,0,18,0.665,18,1.484L18,1.484z"/>
+ <path fill="#5fb0f3" d="M18,7.516C18,8.335,17.335,9,16.516,9H1.484C0.665,9,0,8.335,0,7.516l0,0c0-0.82,0.665-1.484,1.484-1.484
+ h15.031C17.335,6.031,18,6.696,18,7.516L18,7.516z"/>
+ <path fill="#5fb0f3" d="M18,13.516C18,14.335,17.335,15,16.516,15H1.484C0.665,15,0,14.335,0,13.516l0,0
+ c0-0.82,0.665-1.484,1.484-1.484h15.031C17.335,12.031,18,12.696,18,13.516L18,13.516z"/>
+ </svg>
+ </a>
+ <div class="trigger">
+ {% for page in site.pages %}
+ {% if page.title %}<a class="page-link" href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>{% endif %}
+ {% endfor %}
+ </div>
+ </nav>
+
+ </div>
+ </div>
+</header>
diff --git a/_includes/section_nav.html b/_includes/section_nav.html
new file mode 100644
index 0000000..f3b227a
--- /dev/null
+++ b/_includes/section_nav.html
@@ -0,0 +1,39 @@
+{% comment %}
+Map grabs the doc sections, giving us an array of arrays. Join, flattens all
+the items to a comma delimited string. Split turns it into an array again.
+{% endcomment %}
+{% assign docs = site.data.docs | map: 'docs' | join: ',' | split: ',' %}
+
+{% comment %}
+Because this is built for every page, lets find where we are in the ordered
+document list by comparing url strings. Then if there's something previous or
+next, lets build a link to it.
+{% endcomment %}
+
+{% for document in docs %}
+ {% assign document_url = document | prepend:"/docs/" | append:"/" %}
+ {% if document_url == page.url %}
+ <div class="section-nav">
+ <div>
+ {% if forloop.first %}
+ <span class="button prev disabled">Back</span>
+ {% else %}
+ {% assign previous = forloop.index0 | minus: 1 %}
+ {% assign previous_page = docs[previous] | prepend:"/docs/" | append:"/" %}
+ <a href="{{ previous_page | prepend:site.baseurl }}" class="button prev">Back</a>
+ {% endif %}
+ </div>
+ <div>
+ {% if forloop.last %}
+ <span class="button next disabled">Next</span>
+ {% else %}
+ {% assign next = forloop.index0 | plus: 1 %}
+ {% assign next_page = docs[next] | prepend:"/docs/" | append:"/" %}
+ <a href="{{ next_page | prepend:site.baseurl }}" class="button button-primary next">Next</a>
+ {% endif %}
+ </div>
+ </div>
+ <div class="clear"></div>
+ {% break %}
+ {% endif %}
+{% endfor %}
diff --git a/_layouts/default.html b/_layouts/default.html
new file mode 100644
index 0000000..262616d
--- /dev/null
+++ b/_layouts/default.html
@@ -0,0 +1,14 @@
+<!DOCTYPE html>
+<html>
+ {% include head.html %}
+
+ <body>
+ {% include header.html %}
+
+ <div class="container">
+ {{ content }}
+
+ {% include footer.html %}
+ </div>
+ </body>
+</html>
diff --git a/_layouts/docs.html b/_layouts/docs.html
new file mode 100644
index 0000000..0eacdc6
--- /dev/null
+++ b/_layouts/docs.html
@@ -0,0 +1,20 @@
+---
+layout: default
+---
+<div class="post">
+ <div class="row">
+ <div class="four columns">
+ {% include docs_contents.html %}
+ {% include docs_contents_mobile.html %}
+ </div>
+ <div class="eight columns">
+ <header class="post-header">
+ <h1>{{ page.title }}</h1>
+ </header>
+ <article class="post-content text">
+ {{ content }}
+ </article>
+ {% include section_nav.html %}
+ </div>
+ </div>
+</div>
diff --git a/_layouts/home.html b/_layouts/home.html
new file mode 100644
index 0000000..f956e46
--- /dev/null
+++ b/_layouts/home.html
@@ -0,0 +1,16 @@
+<html>
+ {% include head.html %}
+ <body>
+ <div class="home">
+ <header class="site-header">
+ <h1>reproducible<span class="punctuation">-</span>builds<span class="punctuation">.org</span></h1>
+ <p class="tagline">Provide a verifiable path from source code to binary.</p>
+ </header>
+ <div class="container">
+ <article>
+ {{ content }}
+ </article>
+
+ {% include footer.html %}
+ </div>
+</div>
diff --git a/_layouts/page.html b/_layouts/page.html
new file mode 100644
index 0000000..a8e9d21
--- /dev/null
+++ b/_layouts/page.html
@@ -0,0 +1,17 @@
+---
+layout: default
+---
+<div class="post">
+ <header class="post-header">
+ <div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns">
+ <h1>{{ page.title }}</h1>
+ </div>
+ </div>
+ </header>
+
+ <article class="post-content">
+ {{ content }}
+ </article>
+</div>
diff --git a/_layouts/post.html b/_layouts/post.html
new file mode 100644
index 0000000..d7b65ca
--- /dev/null
+++ b/_layouts/post.html
@@ -0,0 +1,25 @@
+---
+layout: default
+---
+<div class="post">
+
+ <header class="post-header">
+ <div class="row">
+ <div class="four columns">
+ <p class="meta">{{ page.date | date: "%b %-d, %Y" }}{% if page.author %} • {{ page.author }}{% endif %}{% if page.meta %} • {{ page.meta }}{% endif %}</p>
+ </div>
+ <div class="eight columns">
+ <h1>{{ page.title }}</h1>
+ </div>
+ </div>
+ </header>
+
+ <article class="post-content">
+ <div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns text">
+ {{ content }}
+ </div>
+ </article>
+
+</div>
diff --git a/_posts/2015-10-16-new-homepage.markdown b/_posts/2015-10-16-new-homepage.markdown
new file mode 100644
index 0000000..e5508bc
--- /dev/null
+++ b/_posts/2015-10-16-new-homepage.markdown
@@ -0,0 +1,24 @@
+---
+layout: post
+title: "A new homepage"
+date: 2015-10-16 14:06:41
+categories: org
+---
+
+While long considered nearly impossible for real software,
+the idea of *reproducible builds* has been revived a couple years ago by
+developpers from Bitcoin and The Tor Project. Since then, [several major free
+software projects]({{ "/who/" | prepend: site.baseurl }}) are now actively
+working on supporting reproducible builds.
+
+It was time to give more visibility to the various initiatives and get a common
+ground to share general information, specifications, and tutorials. So here's a
+new homepage!
+
+**Everyone is welcome to contribute!** To get a copy of the website, just type:
+
+ git clone https://reproducible-builds.org/website.git
+
+Most of the currently available documentation has been written with the
+experience and the perspective of the work done in the Debian project. We are
+sure missing important research and solutions. Please share your insights!
diff --git a/css/Raleway/Raleway-Black.ttf b/css/Raleway/Raleway-Black.ttf
new file mode 100644
index 0000000..91c8fbb
Binary files /dev/null and b/css/Raleway/Raleway-Black.ttf differ
diff --git a/css/Raleway/Raleway-BlackItalic.ttf b/css/Raleway/Raleway-BlackItalic.ttf
new file mode 100644
index 0000000..53b4021
Binary files /dev/null and b/css/Raleway/Raleway-BlackItalic.ttf differ
diff --git a/css/Raleway/Raleway-Bold.ttf b/css/Raleway/Raleway-Bold.ttf
new file mode 100644
index 0000000..7aa37f0
Binary files /dev/null and b/css/Raleway/Raleway-Bold.ttf differ
diff --git a/css/Raleway/Raleway-BoldItalic.ttf b/css/Raleway/Raleway-BoldItalic.ttf
new file mode 100644
index 0000000..1d1c6dd
Binary files /dev/null and b/css/Raleway/Raleway-BoldItalic.ttf differ
diff --git a/css/Raleway/Raleway-ExtraBold.ttf b/css/Raleway/Raleway-ExtraBold.ttf
new file mode 100644
index 0000000..33cb389
Binary files /dev/null and b/css/Raleway/Raleway-ExtraBold.ttf differ
diff --git a/css/Raleway/Raleway-ExtraBoldItalic.ttf b/css/Raleway/Raleway-ExtraBoldItalic.ttf
new file mode 100644
index 0000000..04626d6
Binary files /dev/null and b/css/Raleway/Raleway-ExtraBoldItalic.ttf differ
diff --git a/css/Raleway/Raleway-ExtraLight.ttf b/css/Raleway/Raleway-ExtraLight.ttf
new file mode 100644
index 0000000..a839f5e
Binary files /dev/null and b/css/Raleway/Raleway-ExtraLight.ttf differ
diff --git a/css/Raleway/Raleway-ExtraLightItalic.ttf b/css/Raleway/Raleway-ExtraLightItalic.ttf
new file mode 100644
index 0000000..4d25891
Binary files /dev/null and b/css/Raleway/Raleway-ExtraLightItalic.ttf differ
diff --git a/css/Raleway/Raleway-Italic.ttf b/css/Raleway/Raleway-Italic.ttf
new file mode 100644
index 0000000..e46ac30
Binary files /dev/null and b/css/Raleway/Raleway-Italic.ttf differ
diff --git a/css/Raleway/Raleway-Light.ttf b/css/Raleway/Raleway-Light.ttf
new file mode 100644
index 0000000..a947da3
Binary files /dev/null and b/css/Raleway/Raleway-Light.ttf differ
diff --git a/css/Raleway/Raleway-LightItalic.ttf b/css/Raleway/Raleway-LightItalic.ttf
new file mode 100644
index 0000000..a064a4e
Binary files /dev/null and b/css/Raleway/Raleway-LightItalic.ttf differ
diff --git a/css/Raleway/Raleway-Medium.ttf b/css/Raleway/Raleway-Medium.ttf
new file mode 100644
index 0000000..99df2d6
Binary files /dev/null and b/css/Raleway/Raleway-Medium.ttf differ
diff --git a/css/Raleway/Raleway-MediumItalic.ttf b/css/Raleway/Raleway-MediumItalic.ttf
new file mode 100644
index 0000000..d78c697
Binary files /dev/null and b/css/Raleway/Raleway-MediumItalic.ttf differ
diff --git a/css/Raleway/Raleway-Regular.ttf b/css/Raleway/Raleway-Regular.ttf
new file mode 100644
index 0000000..c6ec2f0
Binary files /dev/null and b/css/Raleway/Raleway-Regular.ttf differ
diff --git a/css/Raleway/Raleway-SemiBold.ttf b/css/Raleway/Raleway-SemiBold.ttf
new file mode 100644
index 0000000..d61efa3
Binary files /dev/null and b/css/Raleway/Raleway-SemiBold.ttf differ
diff --git a/css/Raleway/Raleway-SemiBoldItalic.ttf b/css/Raleway/Raleway-SemiBoldItalic.ttf
new file mode 100644
index 0000000..a169e67
Binary files /dev/null and b/css/Raleway/Raleway-SemiBoldItalic.ttf differ
diff --git a/css/Raleway/Raleway-Thin.ttf b/css/Raleway/Raleway-Thin.ttf
new file mode 100644
index 0000000..dcc9e4f
Binary files /dev/null and b/css/Raleway/Raleway-Thin.ttf differ
diff --git a/css/Raleway/Raleway-ThinItalic.ttf b/css/Raleway/Raleway-ThinItalic.ttf
new file mode 100644
index 0000000..c318827
Binary files /dev/null and b/css/Raleway/Raleway-ThinItalic.ttf differ
diff --git a/css/Raleway/SIL Open Font License.txt b/css/Raleway/SIL Open Font License.txt
new file mode 100644
index 0000000..45268bf
--- /dev/null
+++ b/css/Raleway/SIL Open Font License.txt
@@ -0,0 +1,43 @@
+Copyright (c) 2010 - 2012, Matt McInerney (matt at pixelspread.com), Pablo Impallari(impallari at gmail.com), Rodrigo Fuenzalida (hello at rfuenzalida.com) with Reserved Font Name "Raleway"
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.
+This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL
+
+-----------------------------------------------------------
+SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
+-----------------------------------------------------------
+
+PREAMBLE
+The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others.
+
+The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document creat [...]
+
+DEFINITIONS
+"Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation.
+
+"Reserved Font Name" refers to any names specified as such after the copyright statement(s).
+
+"Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s).
+
+"Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment.
+
+"Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software.
+
+PERMISSION & CONDITIONS
+Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions:
+
+1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
+
+2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user.
+
+3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users.
+
+4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission.
+
+5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software.
+
+TERMINATION
+This license becomes null and void if any of the above conditions are not met.
+
+DISCLAIMER
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM [...]
\ No newline at end of file
diff --git a/css/main.css b/css/main.css
new file mode 100644
index 0000000..cb654be
--- /dev/null
+++ b/css/main.css
@@ -0,0 +1,451 @@
+.site-header {
+ background: #4682b4;
+ color: #fff;
+ width: 100%;
+ min-height: 56px;
+ margin-bottom: 4.0rem;
+}
+
+.home header {
+ text-align: center;
+ padding-bottom: 1.0rem;
+}
+.home header h1 {
+ font-size: 5.8rem;
+ padding-top: 4.0rem;
+ padding-bottom: 2.0rem;
+}
+.site-header .punctuation {
+ color: #5fb0f3;
+}
+.home header .tagline {
+ font-size: 2.0rem;
+}
+
+ at media (min-width: 750px) {
+ .home .title, .post-content .title {
+ text-align: right;
+ padding-left: 1rem;
+ padding-right: 1rem;
+ margin-bottom: 2rem;
+ }
+ .home .title h2, .post-content .title h2 {
+ line-height: 1;
+ margin-bottom: 0;
+ font-size: 2.8rem;
+ }
+}
+ at media (min-width: 900px) {
+ .home .title h2, .post-content .title h2 {
+ font-size: 3.0rem;
+ }
+}
+ at media (min-width: 1000px) {
+ .home .title h2, .post-content .title h2 {
+ font-size: 3.2rem;
+ }
+}
+ at media (min-width: 1100px) {
+ .home .title h2, .post-content .title h2 {
+ font-size: 3.4rem;
+ }
+}
+ at media (min-width: 1200px) {
+ .home .title h2, .post-content .title h2 {
+ font-size: 3.6rem;
+ }
+}
+
+.home .text p, .post-content .text p {
+ max-width: 60ex;
+ margin-bottom: 1rem;
+}
+
+.text p {
+ text-align: justify;
+}
+
+.home .posts { list-style-type: none; }
+
+.home .posts li { margin-bottom: 30px; }
+
+.home .posts .post-link {
+ font-size: 24px;
+ letter-spacing: -1px;
+ line-height: 1;
+}
+
+.home .posts .post-date {
+ display: block;
+ font-size: 15px;
+ color: #818181;
+}
+
+.site-title,
+.site-title:hover,
+.site-title:visited {
+ display: block;
+ color: white;
+ font-size: 26px;
+ letter-spacing: -1px;
+ float: left;
+ line-height: 56px;
+ position: relative;
+ z-index: 1;
+ text-decoration: none;
+}
+
+.site-nav {
+ float: right;
+ line-height: 56px;
+}
+
+.home nav {
+ line-height: 56px;
+ text-align: center;
+}
+
+.home .site-header {
+ margin-bottom: 0.5rem;
+}
+.home nav {
+ margin-bottom: 4rem;
+}
+
+.site-nav a, .home nav a {
+ text-decoration: none;
+}
+
+.site-nav a:hover, .home nav a:hover {
+ text-decoration: underline;
+}
+
+.site-nav .menu-icon { display: none; }
+
+.site-nav .page-link {
+ margin-left: 20px;
+ color: white;
+ letter-spacing: -.5px;
+}
+
+.home nav .page-link {
+ margin-left: 20px;
+ letter-spacing: -.5px;
+}
+
+.show-on-mobiles {
+ display: none;
+}
+
+.current a {
+ font-weight: bold;
+}
+
+ at media screen and (max-width: 749px) {
+ .show-on-mobiles {
+ display: block !important;
+ }
+ .hide-on-mobiles {
+ display: none;
+ }
+}
+
+ at media screen and (max-width: 899px) {
+ .site-nav .show-on-mobiles {
+ display: block !important;
+ }
+ .site-nav .hide-on-mobiles {
+ display: none;
+ }
+ .site-nav {
+ position: fixed;
+ z-index: 10;
+ top: 10px; right: 8px;
+ background-color: #4682b4;
+ -webkit-border-radius: 5px;
+ -moz-border-radius: 5px;
+ border-radius: 5px;
+ border: 1px solid #5fb0f3;
+ }
+
+ .site-nav .menu-icon {
+ display: block;
+ font-size: 24px;
+ color: white;
+ float: right;
+ width: 36px;
+ text-align: center;
+ line-height: 36px;
+ }
+
+ .site-nav .menu-icon svg { width: 18px; height: 16px; }
+
+ .site-nav .trigger {
+ clear: both;
+ margin-bottom: 5px;
+ display: none;
+ }
+
+ .site-nav:hover .trigger { display: block; }
+
+ .site-nav .page-link {
+ display: block;
+ text-align: right;
+ line-height: 1.25;
+ padding: 5px 10px;
+ margin: 0;
+ }
+}
+
+aside h4 {
+ font-size: 2.0rem;
+}
+
+aside li {
+ list-style: none;
+ margin-bottom: 0;
+}
+
+aside li a {
+ text-decoration: none;
+}
+
+.section-nav {
+ margin-top: 5rem;
+}
+
+.section-nav .disabled {
+ opacity: .5;
+ cursor: default;
+ border: 1px solid #bbb;
+ color: #555;
+}
+
+.section-nav > div {
+ width: 49.5%;
+ float: left;
+}
+
+.section-nav .next {
+ float: right;
+}
+
+.post-content .doc-index h4 {
+ font-size: 2.4rem;
+ margin-bottom: 1rem;
+}
+
+.post-content .doc-index ul {
+ padding-left: 0;
+}
+.post-content .doc-index li {
+ list-style: none;
+ margin-bottom: 0;
+}
+
+ at media (min-width: 750px) {
+ .post-content h2 { font-size: 3.6rem; }
+ .post-content h3 { font-size: 3.0rem; }
+ .post-content h4 { font-size: 2.4rem; }
+ .post-content h5 { font-size: 1.8rem; }
+ .post-content h6 { font-size: 1.5rem; }
+}
+
+.post-header { margin: 0px 0 30px; }
+
+.post-header h1 {
+ line-height: 1;
+ margin-bottom: 1rem;
+}
+
+.post-header .meta, .title .meta {
+ font-size: 15px;
+ color: #818181;
+ margin-top: 5px;
+}
+.post-header .meta {
+ line-height: 6.0rem;
+}
+.title .meta {
+ line-height: 5.0rem;
+}
+
+ at media (min-width: 750px) {
+ .post-header .meta {
+ text-align: right;
+ }
+}
+
+.post-content h3 a {
+ text-decoration: none;
+ color: black;
+}
+
+.post-content dl {
+ margin-top: 0;
+}
+
+.post-content ul, .post-content ol {
+ list-style-position: outside;
+ padding-left: 1.5rem;
+}
+.post-content ul ul,
+.post-content ul ol,
+.post-content ol ul,
+.post-content ol ol {
+ margin: 0 0 0 3rem;
+}
+
+.post-content li {
+ margin-bottom: 0;
+}
+
+.post-content .footnotes {
+ margin-top: 4rem;
+ font-size: small;
+}
+
+.post-content .wrong code {
+ border-color: red;
+ background-color: #f1c1c1;
+}
+
+.post-content .correct code {
+ border-color: green;
+ background-color: #c1f1c1;
+}
+
+.site-footer {
+ border-top: 1px solid #e8e8e8;
+ padding: 3.0rem 0;
+}
+
+.site-footer .row .columns {
+ margin-bottom: 3rem;
+}
+
+.site-footer ul { list-style: none; }
+
+.footer-heading {
+ font-size: 18px;
+ font-weight: 300;
+ letter-spacing: -.5px;
+ margin-bottom: 15px;
+}
+
+.site-footer li,
+.site-footer p {
+ font-size: 15px;
+ letter-spacing: -.3px;
+ color: #828282;
+ margin-bottom: 0;
+}
+
+.twitter-icon-svg {
+ display: inline-block;
+ width: 16px;
+ height: 16px;
+ position: relative;
+ top: 3px;
+}
+
+ at font-face {
+ font-family: 'Raleway';
+ font-style: normal;
+ font-weight: 300;
+ src: local('Raleway Light'), local('Raleway-Light'), url(Raleway/Raleway-Light.ttf) format('truetype');
+}
+ at font-face {
+ font-family: 'Raleway';
+ font-style: italic;
+ font-weight: 300;
+ src: local('Raleway Light Italic'), local('Raleway-LightItalic'), url(Raleway/Raleway-LightItalic.ttf) format('truetype');
+}
+ at font-face {
+ font-family: 'Raleway';
+ font-style: normal;
+ font-weight: 400;
+ src: local('Raleway'), url(Raleway/Raleway-Regular.ttf) format('truetype');
+}
+ at font-face {
+ font-family: 'Raleway';
+ font-style: italic;
+ font-weight: 400;
+ src: local('Raleway Italic'), local('Raleway-Italic'), url(Raleway/Raleway-Italic.ttf) format('truetype');
+}
+ at font-face {
+ font-family: 'Raleway';
+ font-style: normal;
+ font-weight: 600;
+ src: local('Raleway SemiBold Italic'), local('Raleway-SemiBold'), url(Raleway/Raleway-SemiBold.ttf) format('truetype');
+}
+ at font-face {
+ font-family: 'Raleway';
+ font-style: italic;
+ font-weight: 600;
+ src: local('Raleway SemiBold Italic'), local('Raleway-SemiBoldItalic'), url(Raleway/Raleway-SemiBoldItalic.ttf) format('truetype');
+}
+
+/* Syntax highlighting styles */
+/* ----------------------------------------------------------*/
+
+.highlight { background: #ffffff; }
+.highlight .c { color: #999988; font-style: italic } /* Comment */
+.highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
+.highlight .k { font-weight: bold } /* Keyword */
+.highlight .o { font-weight: bold } /* Operator */
+.highlight .cm { color: #999988; font-style: italic } /* Comment.Multiline */
+.highlight .cp { color: #999999; font-weight: bold } /* Comment.Preproc */
+.highlight .c1 { color: #999988; font-style: italic } /* Comment.Single */
+.highlight .cs { color: #999999; font-weight: bold; font-style: italic } /* Comment.Special */
+.highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
+.highlight .gd .x { color: #000000; background-color: #ffaaaa } /* Generic.Deleted.Specific */
+.highlight .ge { font-style: italic } /* Generic.Emph */
+.highlight .gr { color: #aa0000 } /* Generic.Error */
+.highlight .gh { color: #999999 } /* Generic.Heading */
+.highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
+.highlight .gi .x { color: #000000; background-color: #aaffaa } /* Generic.Inserted.Specific */
+.highlight .go { color: #888888 } /* Generic.Output */
+.highlight .gp { color: #555555 } /* Generic.Prompt */
+.highlight .gs { font-weight: bold } /* Generic.Strong */
+.highlight .gu { color: #aaaaaa } /* Generic.Subheading */
+.highlight .gt { color: #aa0000 } /* Generic.Traceback */
+.highlight .kc { font-weight: bold } /* Keyword.Constant */
+.highlight .kd { font-weight: bold } /* Keyword.Declaration */
+.highlight .kp { font-weight: bold } /* Keyword.Pseudo */
+.highlight .kr { font-weight: bold } /* Keyword.Reserved */
+.highlight .kt { color: #445588; font-weight: bold } /* Keyword.Type */
+.highlight .m { color: #009999 } /* Literal.Number */
+.highlight .s { color: #d14 } /* Literal.String */
+.highlight .na { color: #008080 } /* Name.Attribute */
+.highlight .nb { color: #0086B3 } /* Name.Builtin */
+.highlight .nc { color: #445588; font-weight: bold } /* Name.Class */
+.highlight .no { color: #008080 } /* Name.Constant */
+.highlight .ni { color: #800080 } /* Name.Entity */
+.highlight .ne { color: #990000; font-weight: bold } /* Name.Exception */
+.highlight .nf { color: #990000; font-weight: bold } /* Name.Function */
+.highlight .nn { color: #555555 } /* Name.Namespace */
+.highlight .nt { color: #000080 } /* Name.Tag */
+.highlight .nv { color: #008080 } /* Name.Variable */
+.highlight .ow { font-weight: bold } /* Operator.Word */
+.highlight .w { color: #bbbbbb } /* Text.Whitespace */
+.highlight .mf { color: #009999 } /* Literal.Number.Float */
+.highlight .mh { color: #009999 } /* Literal.Number.Hex */
+.highlight .mi { color: #009999 } /* Literal.Number.Integer */
+.highlight .mo { color: #009999 } /* Literal.Number.Oct */
+.highlight .sb { color: #d14 } /* Literal.String.Backtick */
+.highlight .sc { color: #d14 } /* Literal.String.Char */
+.highlight .sd { color: #d14 } /* Literal.String.Doc */
+.highlight .s2 { color: #d14 } /* Literal.String.Double */
+.highlight .se { color: #d14 } /* Literal.String.Escape */
+.highlight .sh { color: #d14 } /* Literal.String.Heredoc */
+.highlight .si { color: #d14 } /* Literal.String.Interpol */
+.highlight .sx { color: #d14 } /* Literal.String.Other */
+.highlight .sr { color: #009926 } /* Literal.String.Regex */
+.highlight .s1 { color: #d14 } /* Literal.String.Single */
+.highlight .ss { color: #990073 } /* Literal.String.Symbol */
+.highlight .bp { color: #999999 } /* Name.Builtin.Pseudo */
+.highlight .vc { color: #008080 } /* Name.Variable.Class */
+.highlight .vg { color: #008080 } /* Name.Variable.Global */
+.highlight .vi { color: #008080 } /* Name.Variable.Instance */
+.highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
diff --git a/css/normalize.css b/css/normalize.css
new file mode 100644
index 0000000..81c6f31
--- /dev/null
+++ b/css/normalize.css
@@ -0,0 +1,427 @@
+/*! normalize.css v3.0.2 | MIT License | git.io/normalize */
+
+/**
+ * 1. Set default font family to sans-serif.
+ * 2. Prevent iOS text size adjust after orientation change, without disabling
+ * user zoom.
+ */
+
+html {
+ font-family: sans-serif; /* 1 */
+ -ms-text-size-adjust: 100%; /* 2 */
+ -webkit-text-size-adjust: 100%; /* 2 */
+}
+
+/**
+ * Remove default margin.
+ */
+
+body {
+ margin: 0;
+}
+
+/* HTML5 display definitions
+ ========================================================================== */
+
+/**
+ * Correct `block` display not defined for any HTML5 element in IE 8/9.
+ * Correct `block` display not defined for `details` or `summary` in IE 10/11
+ * and Firefox.
+ * Correct `block` display not defined for `main` in IE 11.
+ */
+
+article,
+aside,
+details,
+figcaption,
+figure,
+footer,
+header,
+hgroup,
+main,
+menu,
+nav,
+section,
+summary {
+ display: block;
+}
+
+/**
+ * 1. Correct `inline-block` display not defined in IE 8/9.
+ * 2. Normalize vertical alignment of `progress` in Chrome, Firefox, and Opera.
+ */
+
+audio,
+canvas,
+progress,
+video {
+ display: inline-block; /* 1 */
+ vertical-align: baseline; /* 2 */
+}
+
+/**
+ * Prevent modern browsers from displaying `audio` without controls.
+ * Remove excess height in iOS 5 devices.
+ */
+
+audio:not([controls]) {
+ display: none;
+ height: 0;
+}
+
+/**
+ * Address `[hidden]` styling not present in IE 8/9/10.
+ * Hide the `template` element in IE 8/9/11, Safari, and Firefox < 22.
+ */
+
+[hidden],
+template {
+ display: none;
+}
+
+/* Links
+ ========================================================================== */
+
+/**
+ * Remove the gray background color from active links in IE 10.
+ */
+
+a {
+ background-color: transparent;
+}
+
+/**
+ * Improve readability when focused and also mouse hovered in all browsers.
+ */
+
+a:active,
+a:hover {
+ outline: 0;
+}
+
+/* Text-level semantics
+ ========================================================================== */
+
+/**
+ * Address styling not present in IE 8/9/10/11, Safari, and Chrome.
+ */
+
+abbr[title] {
+ border-bottom: 1px dotted;
+}
+
+/**
+ * Address style set to `bolder` in Firefox 4+, Safari, and Chrome.
+ */
+
+b,
+strong {
+ font-weight: bold;
+}
+
+/**
+ * Address styling not present in Safari and Chrome.
+ */
+
+dfn {
+ font-style: italic;
+}
+
+/**
+ * Address variable `h1` font-size and margin within `section` and `article`
+ * contexts in Firefox 4+, Safari, and Chrome.
+ */
+
+h1 {
+ font-size: 2em;
+ margin: 0.67em 0;
+}
+
+/**
+ * Address styling not present in IE 8/9.
+ */
+
+mark {
+ background: #ff0;
+ color: #000;
+}
+
+/**
+ * Address inconsistent and variable font size in all browsers.
+ */
+
+small {
+ font-size: 80%;
+}
+
+/**
+ * Prevent `sub` and `sup` affecting `line-height` in all browsers.
+ */
+
+sub,
+sup {
+ font-size: 75%;
+ line-height: 0;
+ position: relative;
+ vertical-align: baseline;
+}
+
+sup {
+ top: -0.5em;
+}
+
+sub {
+ bottom: -0.25em;
+}
+
+/* Embedded content
+ ========================================================================== */
+
+/**
+ * Remove border when inside `a` element in IE 8/9/10.
+ */
+
+img {
+ border: 0;
+}
+
+/**
+ * Correct overflow not hidden in IE 9/10/11.
+ */
+
+svg:not(:root) {
+ overflow: hidden;
+}
+
+/* Grouping content
+ ========================================================================== */
+
+/**
+ * Address margin not present in IE 8/9 and Safari.
+ */
+
+figure {
+ margin: 1em 40px;
+}
+
+/**
+ * Address differences between Firefox and other browsers.
+ */
+
+hr {
+ -moz-box-sizing: content-box;
+ box-sizing: content-box;
+ height: 0;
+}
+
+/**
+ * Contain overflow in all browsers.
+ */
+
+pre {
+ overflow: auto;
+}
+
+/**
+ * Address odd `em`-unit font size rendering in all browsers.
+ */
+
+code,
+kbd,
+pre,
+samp {
+ font-family: monospace, monospace;
+ font-size: 1em;
+}
+
+/* Forms
+ ========================================================================== */
+
+/**
+ * Known limitation: by default, Chrome and Safari on OS X allow very limited
+ * styling of `select`, unless a `border` property is set.
+ */
+
+/**
+ * 1. Correct color not being inherited.
+ * Known issue: affects color of disabled elements.
+ * 2. Correct font properties not being inherited.
+ * 3. Address margins set differently in Firefox 4+, Safari, and Chrome.
+ */
+
+button,
+input,
+optgroup,
+select,
+textarea {
+ color: inherit; /* 1 */
+ font: inherit; /* 2 */
+ margin: 0; /* 3 */
+}
+
+/**
+ * Address `overflow` set to `hidden` in IE 8/9/10/11.
+ */
+
+button {
+ overflow: visible;
+}
+
+/**
+ * Address inconsistent `text-transform` inheritance for `button` and `select`.
+ * All other form control elements do not inherit `text-transform` values.
+ * Correct `button` style inheritance in Firefox, IE 8/9/10/11, and Opera.
+ * Correct `select` style inheritance in Firefox.
+ */
+
+button,
+select {
+ text-transform: none;
+}
+
+/**
+ * 1. Avoid the WebKit bug in Android 4.0.* where (2) destroys native `audio`
+ * and `video` controls.
+ * 2. Correct inability to style clickable `input` types in iOS.
+ * 3. Improve usability and consistency of cursor style between image-type
+ * `input` and others.
+ */
+
+button,
+html input[type="button"], /* 1 */
+input[type="reset"],
+input[type="submit"] {
+ -webkit-appearance: button; /* 2 */
+ cursor: pointer; /* 3 */
+}
+
+/**
+ * Re-set default cursor for disabled elements.
+ */
+
+button[disabled],
+html input[disabled] {
+ cursor: default;
+}
+
+/**
+ * Remove inner padding and border in Firefox 4+.
+ */
+
+button::-moz-focus-inner,
+input::-moz-focus-inner {
+ border: 0;
+ padding: 0;
+}
+
+/**
+ * Address Firefox 4+ setting `line-height` on `input` using `!important` in
+ * the UA stylesheet.
+ */
+
+input {
+ line-height: normal;
+}
+
+/**
+ * It's recommended that you don't attempt to style these elements.
+ * Firefox's implementation doesn't respect box-sizing, padding, or width.
+ *
+ * 1. Address box sizing set to `content-box` in IE 8/9/10.
+ * 2. Remove excess padding in IE 8/9/10.
+ */
+
+input[type="checkbox"],
+input[type="radio"] {
+ box-sizing: border-box; /* 1 */
+ padding: 0; /* 2 */
+}
+
+/**
+ * Fix the cursor style for Chrome's increment/decrement buttons. For certain
+ * `font-size` values of the `input`, it causes the cursor style of the
+ * decrement button to change from `default` to `text`.
+ */
+
+input[type="number"]::-webkit-inner-spin-button,
+input[type="number"]::-webkit-outer-spin-button {
+ height: auto;
+}
+
+/**
+ * 1. Address `appearance` set to `searchfield` in Safari and Chrome.
+ * 2. Address `box-sizing` set to `border-box` in Safari and Chrome
+ * (include `-moz` to future-proof).
+ */
+
+input[type="search"] {
+ -webkit-appearance: textfield; /* 1 */
+ -moz-box-sizing: content-box;
+ -webkit-box-sizing: content-box; /* 2 */
+ box-sizing: content-box;
+}
+
+/**
+ * Remove inner padding and search cancel button in Safari and Chrome on OS X.
+ * Safari (but not Chrome) clips the cancel button when the search input has
+ * padding (and `textfield` appearance).
+ */
+
+input[type="search"]::-webkit-search-cancel-button,
+input[type="search"]::-webkit-search-decoration {
+ -webkit-appearance: none;
+}
+
+/**
+ * Define consistent border, margin, and padding.
+ */
+
+fieldset {
+ border: 1px solid #c0c0c0;
+ margin: 0 2px;
+ padding: 0.35em 0.625em 0.75em;
+}
+
+/**
+ * 1. Correct `color` not being inherited in IE 8/9/10/11.
+ * 2. Remove padding so people aren't caught out if they zero out fieldsets.
+ */
+
+legend {
+ border: 0; /* 1 */
+ padding: 0; /* 2 */
+}
+
+/**
+ * Remove default vertical scrollbar in IE 8/9/10/11.
+ */
+
+textarea {
+ overflow: auto;
+}
+
+/**
+ * Don't inherit the `font-weight` (applied by a rule above).
+ * NOTE: the default cannot safely be changed in Chrome and Safari on OS X.
+ */
+
+optgroup {
+ font-weight: bold;
+}
+
+/* Tables
+ ========================================================================== */
+
+/**
+ * Remove most spacing between table cells.
+ */
+
+table {
+ border-collapse: collapse;
+ border-spacing: 0;
+}
+
+td,
+th {
+ padding: 0;
+}
\ No newline at end of file
diff --git a/css/skeleton.css b/css/skeleton.css
new file mode 100644
index 0000000..0b27fa1
--- /dev/null
+++ b/css/skeleton.css
@@ -0,0 +1,415 @@
+/*
+* Skeleton V2.0.4
+* Copyright 2014, Dave Gamache
+* www.getskeleton.com
+* Free to use under the MIT license.
+* http://www.opensource.org/licenses/mit-license.php
+* 12/29/2014
+*/
+
+
+/* Table of contents
+––––––––––––––––––––––––––––––––––––––––––––––––––
+- Grid
+- Base Styles
+- Typography
+- Links
+- Buttons
+- Forms
+- Lists
+- Code
+- Tables
+- Spacing
+- Utilities
+- Clearing
+- Media Queries
+*/
+
+
+/* Grid
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+.container {
+ position: relative;
+ width: 100%;
+ max-width: 960px;
+ margin: 0 auto;
+ padding: 0 20px;
+ box-sizing: border-box; }
+.column,
+.columns {
+ width: 100%;
+ float: left;
+ box-sizing: border-box; }
+
+/* For devices larger than 400px */
+ at media (min-width: 400px) {
+ .container {
+ width: 85%;
+ padding: 0; }
+}
+
+/* For devices larger than 750px */
+ at media (min-width: 750px) {
+ .container {
+ width: 80%; }
+ .column,
+ .columns {
+ margin-left: 4%; }
+ .column:first-child,
+ .columns:first-child {
+ margin-left: 0; }
+
+ .one.column,
+ .one.columns { width: 4.66666666667%; }
+ .two.columns { width: 13.3333333333%; }
+ .three.columns { width: 22%; }
+ .four.columns { width: 30.6666666667%; }
+ .five.columns { width: 39.3333333333%; }
+ .six.columns { width: 48%; }
+ .seven.columns { width: 56.6666666667%; }
+ .eight.columns { width: 65.3333333333%; }
+ .nine.columns { width: 74.0%; }
+ .ten.columns { width: 82.6666666667%; }
+ .eleven.columns { width: 91.3333333333%; }
+ .twelve.columns { width: 100%; margin-left: 0; }
+
+ .one-third.column { width: 30.6666666667%; }
+ .two-thirds.column { width: 65.3333333333%; }
+
+ .one-half.column { width: 48%; }
+
+ /* Offsets */
+ .offset-by-one.column,
+ .offset-by-one.columns { margin-left: 8.66666666667%; }
+ .offset-by-two.column,
+ .offset-by-two.columns { margin-left: 17.3333333333%; }
+ .offset-by-three.column,
+ .offset-by-three.columns { margin-left: 26%; }
+ .offset-by-four.column,
+ .offset-by-four.columns { margin-left: 34.6666666667%; }
+ .offset-by-five.column,
+ .offset-by-five.columns { margin-left: 43.3333333333%; }
+ .offset-by-six.column,
+ .offset-by-six.columns { margin-left: 52%; }
+ .offset-by-seven.column,
+ .offset-by-seven.columns { margin-left: 60.6666666667%; }
+ .offset-by-eight.column,
+ .offset-by-eight.columns { margin-left: 69.3333333333%; }
+ .offset-by-nine.column,
+ .offset-by-nine.columns { margin-left: 78.0%; }
+ .offset-by-ten.column,
+ .offset-by-ten.columns { margin-left: 86.6666666667%; }
+ .offset-by-eleven.column,
+ .offset-by-eleven.columns { margin-left: 95.3333333333%; }
+
+ .offset-by-one-third.column,
+ .offset-by-one-third.columns { margin-left: 34.6666666667%; }
+ .offset-by-two-thirds.column,
+ .offset-by-two-thirds.columns { margin-left: 69.3333333333%; }
+
+ .offset-by-one-half.column,
+ .offset-by-one-half.columns { margin-left: 52%; }
+
+}
+
+
+/* Base Styles
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+/* NOTE
+html is set to 62.5% so that all the REM measurements throughout Skeleton
+are based on 10px sizing. So basically 1.5rem = 15px :) */
+html {
+ font-size: 62.5%; }
+body {
+ font-size: 1.5em; /* currently ems cause chrome bug misinterpreting rems on body element */
+ line-height: 1.6;
+ font-weight: 400;
+ font-family: "Raleway", "HelveticaNeue", "Helvetica Neue", Helvetica, Arial, sans-serif;
+ color: #222; }
+
+
+/* Typography
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+h1, h2, h3, h4, h5, h6 {
+ margin-top: 0;
+ margin-bottom: 2rem;
+ font-weight: 300; }
+h1 { font-size: 4.0rem; line-height: 1.2; letter-spacing: -.1rem;}
+h2 { font-size: 3.6rem; line-height: 1.25; letter-spacing: -.1rem; }
+h3 { font-size: 3.0rem; line-height: 1.3; letter-spacing: -.1rem; }
+h4 { font-size: 2.4rem; line-height: 1.35; letter-spacing: -.08rem; }
+h5 { font-size: 1.8rem; line-height: 1.5; letter-spacing: -.05rem; }
+h6 { font-size: 1.5rem; line-height: 1.6; letter-spacing: 0; }
+
+/* Larger than tablet */
+ at media (min-width: 750px) {
+ h1 { font-size: 5.0rem; }
+ h2 { font-size: 4.2rem; }
+ h3 { font-size: 3.6rem; }
+ h4 { font-size: 3.0rem; }
+ h5 { font-size: 2.4rem; }
+ h6 { font-size: 1.5rem; }
+}
+
+p {
+ margin-top: 0; }
+
+
+/* Links
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+a {
+ color: #1EAEDB; }
+a:hover {
+ color: #0FA0CE; }
+
+
+/* Buttons
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+.button,
+button,
+input[type="submit"],
+input[type="reset"],
+input[type="button"] {
+ display: inline-block;
+ height: 38px;
+ padding: 0 30px;
+ color: #555;
+ text-align: center;
+ font-size: 11px;
+ font-weight: 600;
+ line-height: 38px;
+ letter-spacing: .1rem;
+ text-transform: uppercase;
+ text-decoration: none;
+ white-space: nowrap;
+ background-color: transparent;
+ border-radius: 4px;
+ border: 1px solid #bbb;
+ cursor: pointer;
+ box-sizing: border-box; }
+.button:hover,
+button:hover,
+input[type="submit"]:hover,
+input[type="reset"]:hover,
+input[type="button"]:hover,
+.button:focus,
+button:focus,
+input[type="submit"]:focus,
+input[type="reset"]:focus,
+input[type="button"]:focus {
+ color: #333;
+ border-color: #888;
+ outline: 0; }
+.button.button-primary,
+button.button-primary,
+input[type="submit"].button-primary,
+input[type="reset"].button-primary,
+input[type="button"].button-primary {
+ color: #FFF;
+ background-color: #33C3F0;
+ border-color: #33C3F0; }
+.button.button-primary:hover,
+button.button-primary:hover,
+input[type="submit"].button-primary:hover,
+input[type="reset"].button-primary:hover,
+input[type="button"].button-primary:hover,
+.button.button-primary:focus,
+button.button-primary:focus,
+input[type="submit"].button-primary:focus,
+input[type="reset"].button-primary:focus,
+input[type="button"].button-primary:focus {
+ color: #FFF;
+ background-color: #1EAEDB;
+ border-color: #1EAEDB; }
+
+
+/* Forms
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+input[type="email"],
+input[type="number"],
+input[type="search"],
+input[type="text"],
+input[type="tel"],
+input[type="url"],
+input[type="password"],
+textarea,
+select {
+ height: 38px;
+ padding: 6px 10px; /* The 6px vertically centers text on FF, ignored by Webkit */
+ background-color: #fff;
+ border: 1px solid #D1D1D1;
+ border-radius: 4px;
+ box-shadow: none;
+ box-sizing: border-box; }
+/* Removes awkward default styles on some inputs for iOS */
+input[type="email"],
+input[type="number"],
+input[type="search"],
+input[type="text"],
+input[type="tel"],
+input[type="url"],
+input[type="password"],
+textarea {
+ -webkit-appearance: none;
+ -moz-appearance: none;
+ appearance: none; }
+textarea {
+ min-height: 65px;
+ padding-top: 6px;
+ padding-bottom: 6px; }
+input[type="email"]:focus,
+input[type="number"]:focus,
+input[type="search"]:focus,
+input[type="text"]:focus,
+input[type="tel"]:focus,
+input[type="url"]:focus,
+input[type="password"]:focus,
+textarea:focus,
+select:focus {
+ border: 1px solid #33C3F0;
+ outline: 0; }
+label,
+legend {
+ display: block;
+ margin-bottom: .5rem;
+ font-weight: 600; }
+fieldset {
+ padding: 0;
+ border-width: 0; }
+input[type="checkbox"],
+input[type="radio"] {
+ display: inline; }
+label > .label-body {
+ display: inline-block;
+ margin-left: .5rem;
+ font-weight: normal; }
+
+
+/* Lists
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+ul {
+ list-style: circle inside; }
+ol {
+ list-style: decimal inside; }
+ol, ul {
+ padding-left: 0;
+ margin-top: 0; }
+ul ul,
+ul ol,
+ol ol,
+ol ul {
+ margin: 1.5rem 0 1.5rem 3rem;
+ font-size: 90%; }
+li {
+ margin-bottom: 1rem; }
+
+
+/* Code
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+code {
+ padding: .2rem .5rem;
+ margin: 0 .2rem;
+ font-size: 90%;
+ white-space: nowrap;
+ background: #F1F1F1;
+ border: 1px solid #E1E1E1;
+ border-radius: 4px; }
+pre > code {
+ display: block;
+ padding: 1rem 1.5rem;
+ white-space: pre; }
+
+
+/* Tables
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+th,
+td {
+ padding: 12px 15px;
+ text-align: left;
+ border-bottom: 1px solid #E1E1E1; }
+th:first-child,
+td:first-child {
+ padding-left: 0; }
+th:last-child,
+td:last-child {
+ padding-right: 0; }
+
+
+/* Spacing
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+button,
+.button {
+ margin-bottom: 1rem; }
+input,
+textarea,
+select,
+fieldset {
+ margin-bottom: 1.5rem; }
+pre,
+blockquote,
+dl,
+figure,
+table,
+p,
+ul,
+ol,
+form {
+ margin-bottom: 2.5rem; }
+
+
+/* Utilities
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+.u-full-width {
+ width: 100%;
+ box-sizing: border-box; }
+.u-max-full-width {
+ max-width: 100%;
+ box-sizing: border-box; }
+.u-pull-right {
+ float: right; }
+.u-pull-left {
+ float: left; }
+
+
+/* Misc
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+hr {
+ margin-top: 3rem;
+ margin-bottom: 3.5rem;
+ border-width: 0;
+ border-top: 1px solid #E1E1E1; }
+
+
+/* Clearing
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+
+/* Self Clearing Goodness */
+.container:after,
+.row:after,
+.u-cf {
+ content: "";
+ display: table;
+ clear: both; }
+
+
+/* Media Queries
+–––––––––––––––––––––––––––––––––––––––––––––––––– */
+/*
+Note: The best way to structure the use of media queries is to create the queries
+near the relevant code. For example, if you wanted to change the styles for buttons
+on small devices, paste the mobile query code up in the buttons section and style it
+there.
+*/
+
+
+/* Larger than mobile */
+ at media (min-width: 400px) {}
+
+/* Larger than tablet (also point when grid becomes active) */
+ at media (min-width: 750px) {}
+
+/* Larger than desktop */
+ at media (min-width: 1000px) {}
+
+/* Larger than Desktop HD */
+ at media (min-width: 1200px) {}
diff --git a/docs.html b/docs.html
new file mode 100644
index 0000000..c95be32
--- /dev/null
+++ b/docs.html
@@ -0,0 +1,70 @@
+---
+layout: page
+title: Documentation
+permalink: /docs/
+---
+
+<div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns text">
+ <p>
+ Getting <em>reproducible builds</em> for your software might be easier than
+ you think! But it might require—generally small—changes to your build system,
+ and a strategy on how to allow other to recreate an environment where the builds
+ can be reproduced.
+ </p>
+ </div>
+</div>
+
+<div class="row" style="margin-top: 1rem;">
+ <div class="four columns title">
+ <h2>Tips & help</h2>
+ </div>
+ <div class="eight columns text doc-index">
+ {% for section in site.data.docs %}
+ <h4>{{ section.title }}</h4>
+ {% include docs_ul.html items=section.docs %}
+ {% endfor %}
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2>Talks</h2>
+ </div>
+ <div class="eight columns text">
+ <dl>
+ <dt>
+ <em>How to make your software build reproducibly</em><br />
+ by Lunar, 2015-08-13, <a href="https://events.ccc.de/camp/2015/">Chaos Communication Camp 2015</a>
+ </dt>
+ <dd>
+ ▸ <a href="https://media.ccc.de/events/camp2015-6657-how_to_make_your_software_build_reproducibly">Recordings</a>,
+ ⧠ <a href="https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15.pdf">Slides</a>,
+ ☷ <a href="https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15-outline.pdf">Full script</a>,
+ ⚙ <a href="https://anonscm.debian.org/cgit/reproducible/presentations.git/tree/2015-08-13-CCCamp15">Sources</a>
+ </ul>
+ </dd>
+ <dt>
+ <em>Reproducible Builds: Moving Beyond Single Points of Failure for Software Distribution</em><br />
+ by Mike Perry and Seth Schoen, 2014-12-27, <a href="https://events.ccc.de/congress/2014/">Chaos Communication Congress 2014</a>
+ </dt>
+ <dd>
+ ▸ <a href="https://media.ccc.de/events/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner">Recordings</a>,
+ ⧠ <a href="https://events.ccc.de/congress/2014/Fahrplan/system/attachments/2575/original/2014CCCReproducible.pdf">Slides</a>
+ </dd>
+ </dl>
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2>Specifications</h2>
+ </div>
+ <div class="eight columns text">
+ <dl>
+ <dt><a href="/spec/source-date-epoch/">SOURCE_DATE_EPOCH</a></dt>
+ <dd>distribution-agnostic standard to provide a pre-defined timestamp to build systems</a></dd>
+ </dl>
+ </div>
+</div>
diff --git a/events.html b/events.html
new file mode 100644
index 0000000..f6a89de
--- /dev/null
+++ b/events.html
@@ -0,0 +1,30 @@
+---
+layout: page
+title: Events
+permalink: /events/
+---
+
+<div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns text">
+ <p>
+ Irregular events are organize to exchange ideas about “reproducible
+ builds”, get a better understanding or cooperate on improving code
+ or specifications.
+ </p>
+ </div>
+</div>
+
+{% assign sorted_events = site.events | sort: 'event_date' | reverse %}
+{% for page in sorted_events %}
+<div class="row">
+ <div class="four columns title">
+ <h2>{{ page.title }}</h2>
+ </div>
+ <div class="eight columns text">
+ <p><em>{{ page.event_date_string }}</em>, {{ page.event_location }}</p>
+ <p>{{ page.event_summary }}</p>
+ <p><a href="{{ page.permalink | prepend: site.baseurl }}">Read more…</a></p>
+ </div>
+</div>
+{% endfor %}
diff --git a/feed.xml b/feed.xml
new file mode 100644
index 0000000..4d7f8a4
--- /dev/null
+++ b/feed.xml
@@ -0,0 +1,30 @@
+---
+layout: none
+---
+<?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>{{ site.title | xml_escape }}</title>
+ <description>{{ site.description | xml_escape }}</description>
+ <link>{{ site.url }}{{ site.baseurl }}/</link>
+ <atom:link href="{{ "/feed.xml" | prepend: site.baseurl | prepend: site.url }}" rel="self" type="application/rss+xml" />
+ <pubDate>{{ site.time | date_to_rfc822 }}</pubDate>
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ <generator>Jekyll v{{ jekyll.version }}</generator>
+ {% for post in site.posts limit:10 %}
+ <item>
+ <title>{{ post.title | xml_escape }}</title>
+ <description>{{ post.content | xml_escape }}</description>
+ <pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
+ <link>{{ post.url | prepend: site.baseurl | prepend: site.url }}</link>
+ <guid isPermaLink="true">{{ post.url | prepend: site.baseurl | prepend: site.url }}</guid>
+ {% for tag in post.tags %}
+ <category>{{ tag | xml_escape }}</category>
+ {% endfor %}
+ {% for cat in post.categories %}
+ <category>{{ cat | xml_escape }}</category>
+ {% endfor %}
+ </item>
+ {% endfor %}
+ </channel>
+</rss>
diff --git a/images/basic-principle.png b/images/basic-principle.png
new file mode 100644
index 0000000..51b17e5
Binary files /dev/null and b/images/basic-principle.png differ
diff --git a/images/docs/uninitialized_memory.png b/images/docs/uninitialized_memory.png
new file mode 100644
index 0000000..d25f96d
Binary files /dev/null and b/images/docs/uninitialized_memory.png differ
diff --git a/images/logos/archlinux.png b/images/logos/archlinux.png
new file mode 100644
index 0000000..0e0c2c3
Binary files /dev/null and b/images/logos/archlinux.png differ
diff --git a/images/logos/bitcoin.png b/images/logos/bitcoin.png
new file mode 100644
index 0000000..0a5c739
Binary files /dev/null and b/images/logos/bitcoin.png differ
diff --git a/images/logos/cii.png b/images/logos/cii.png
new file mode 100644
index 0000000..c61f835
Binary files /dev/null and b/images/logos/cii.png differ
diff --git a/images/logos/coreboot.png b/images/logos/coreboot.png
new file mode 100644
index 0000000..7d7b186
Binary files /dev/null and b/images/logos/coreboot.png differ
diff --git a/images/logos/debian.png b/images/logos/debian.png
new file mode 100644
index 0000000..42142a9
Binary files /dev/null and b/images/logos/debian.png differ
diff --git a/images/logos/freebsd.png b/images/logos/freebsd.png
new file mode 100644
index 0000000..deb2768
Binary files /dev/null and b/images/logos/freebsd.png differ
diff --git a/images/logos/netbsd.png b/images/logos/netbsd.png
new file mode 100644
index 0000000..35fc1b4
Binary files /dev/null and b/images/logos/netbsd.png differ
diff --git a/images/logos/openwrt.png b/images/logos/openwrt.png
new file mode 100644
index 0000000..2d457c3
Binary files /dev/null and b/images/logos/openwrt.png differ
diff --git a/images/logos/profitbricks.png b/images/logos/profitbricks.png
new file mode 100644
index 0000000..442519c
Binary files /dev/null and b/images/logos/profitbricks.png differ
diff --git a/images/logos/tor.png b/images/logos/tor.png
new file mode 100644
index 0000000..c216d62
Binary files /dev/null and b/images/logos/tor.png differ
diff --git a/index.html b/index.html
new file mode 100644
index 0000000..a9c010e
--- /dev/null
+++ b/index.html
@@ -0,0 +1,111 @@
+---
+layout: home
+---
+
+<nav>
+ <div class="hide-on-mobiles">
+ {% for page in site.pages %}
+ {% if page.title %}<a class="page-link" href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>{% endif %}
+ {% endfor %}
+ </div>
+ <div class="show-on-mobiles">
+ <select onchange="if (this.value) window.location.href=this.value">
+ <option value="">reproducible-builds.org</option>
+ {% for page in site.pages %}
+ {% if page.title %}<option value="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</option>{% endif %}
+ {% endfor %}
+ </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 which
+ create a <strong>verifiable path from</strong> human readable
+ <strong>source code to</strong> the <strong>binary</strong> code used by
+ computers.
+ </p>
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2 id="why">Why does it matter?</h1>
+ </div>
+ <div class="eight columns text">
+ <p>
+ Most aspect of software verification is 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 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>grow confidence</strong> than a distributed binary code is indeed
+ coming from a given source code.
+ </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. If the source code had been under
+ public scrutiny, it would have been hard to add such a misfeature… or?
+ Without <em>reproducible builds</em>, it is hard to attest than the
+ binary code running in the car was actually made using the source code
+ that has been verified.
+ </p>
+ <p>
+ <a href="/who/"><strong>Several free software projects</strong></a>
+ already or will soon provide reproducible builds.
+ </p>
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2 id="how">How?</h1>
+ </div>
+ <div class="eight columns text">
+ <p>
+ There are two main aspects to <em>reproducible builds</em>:
+ </p>
+ <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
+ recorded and outputs has to always 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>.
+ <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
+ match the original build</strong>.
+ </p>
+ <p>
+ Learn more on <a href="/docs/"><strong>how to make your software build
+ reproducibly…</strong></a>
+ </p>
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2 id="news">News</h1>
+ </div>
+ <div class="eight columns">
+ <ul class="posts">
+ {% for post in site.posts %}
+ <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>
+ </li>
+ {% endfor %}
+ </ul>
+ <p class="rss-subscribe"><a href="{{ "/feed.xml" | prepend: site.baseurl }}">Subscribe via RSS</a>.</p>
+ </div>
+</div>
diff --git a/news.html b/news.html
new file mode 100644
index 0000000..b1577b2
--- /dev/null
+++ b/news.html
@@ -0,0 +1,20 @@
+---
+layout: page
+title: News
+permalink: /news/
+---
+
+{% for post in site.posts %}
+<div class="row">
+ <div class="four columns title">
+ <p class="meta">
+ {{ post.date | date: "%b %-d, %Y" }}
+ </p>
+ </div>
+ <div class="eight columns text">
+ <h2>{{ post.title }}</h2>
+ {{ post.excerpt }}
+ <p><a class="post-link" href="{{ post.url | prepend: site.baseurl }}">Read more…</a></p>
+ </div>
+</div>
+{% endfor %}
diff --git a/tools.html b/tools.html
new file mode 100644
index 0000000..2b67cfd
--- /dev/null
+++ b/tools.html
@@ -0,0 +1,62 @@
+---
+layout: page
+title: Tools
+permalink: /tools/
+---
+<div class="row">
+ <div class="four columns"> </div>
+ <div class="eight columns text">
+ <p>
+ Several tools are now available to make your life easier when working on
+ <em>reproducible builds</em>:
+ </p>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
+ <h2>diffoscope</h2>
+ </div>
+ <div class="eight columns text">
+ <p>
+ <a href="http://diffoscope.org/">diffoscope</a> will try to <strong>get
+ to the bottom of what makes files or directories different</strong>. It
+ will recursively unpack archives of many kinds and transform various
+ binary formats into more human readable form to compare them. It can
+ compare two tarballs, ISO images, or PDF just as easily.
+ </p>
+ <p>
+ See an <a href="http://diffoscope.org/examples/igerman98_20131206-5.txt">example text output</a>.
+ </p>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
+ <h2>disorderfs</h2>
+ </div>
+ <div class="eight columns text">
+ <p>
+ Problems with <a href="/docs/stable-inputs/">unstable order of inputs</a>
+ or other variations introduced by filesystems can sometimes be hard to track down.
+ <a href="https://packages.debian.org/sid/disorderfs">disorderfs</a> is
+ <strong>an overlay FUSE filesystem that introduces non-determinism into
+ filesystem metadata</strong>. For example, it can randomize the order in
+ which directory entries are read.
+ </p>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
+ <h2>strip-nondeterminism</h2>
+ </div>
+ <div class="eight columns text">
+ <p>
+ Some tools used in build systems might introduce non-determinism in ways
+ difficult to fix at the source <strong>requiring
+ post-processing</strong>. <a
+ href="https://packages.debian.org/sid/strip-nondeterminism">strip-nondeterminism</a>
+ knows how to <strong>normalize various file formats</strong> such as gzipped files, ZIP
+ archives, and Jar files. It is written in Perl with extensibility in
+ mind.
+ </p>
+ </div>
+</div>
diff --git a/who.html b/who.html
new file mode 100644
index 0000000..4cb832b
--- /dev/null
+++ b/who.html
@@ -0,0 +1,62 @@
+---
+layout: page
+title: Who is involved?
+permalink: /who/
+---
+
+<div class="row">
+ <div class="four columns title"> </div>
+ <div class="eight columns text">
+ <p>
+ Various free software projects are working on providing reproducible builds
+ to their users:
+ </p>
+ </div>
+</div>
+
+{% for project in site.data.projects %}
+<div class="row">
+ <div class="four columns title">
+ <a href="{{ project.url }}"><img src="{{ project.logo | prepend: "/images/logos/" | prepend: site.baseurl }}" /></a>
+ </div>
+ <div class="eight columns text">
+ <h3><a href="{{ project.url }}">{{ project.name }}</a></h3>
+ <ul>
+ {% for resource in project.resources %}
+ <li><a href="{{ resource.url }}">{{ resource.name }}</a></li>
+ {% endfor %}
+ </ul>
+ </div>
+</div>
+{% endfor %}
+
+<div class="row">
+ <div class="four columns title">
+ <h2>reproducible-builds.org</h2>
+ </div>
+ <div class="eight columns">
+ <p>
+ Contributors:
+ Chris Lamb,
+ Lunar,
+ h01ger,
+ Vagrant Cascadian,
+ Ximin Luo.
+ </p>
+ <p>
+ <a href="mailto:contact at reproducible-builds.org">Contact us!</a>
+ </p>
+ </div>
+</div>
+
+<div class="row">
+ <div class="four columns title">
+ <h2>Sponsors</h2>
+ </div>
+ <div class="eight columns">
+ <div style="margin-bottom: 1rem;">
+ <a href="https://www.coreinfrastructure.org/"><img style="vertical-align: top;" src="{{ "/images/logos/cii.png" | prepend: site.baseurl }}" alt="Core Infrastructure Initiative" /></a>
+ <a href="https://www.profitbricks.co.uk/"><img style="vertical-align: top;" src="{{ "/images/logos/profitbricks.png" | prepend: site.baseurl }}" alt="ProfitBricks" /></a>
+ </div>
+ </div>
+</div>
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git
More information about the Reproducible-commits
mailing list