[Reproducible-commits] [source-date-epoch-spec] 05/05: Misc updates; no real value in splitting these out
Chris Lamb
lamby at moszumanska.debian.org
Tue Aug 25 19:02:07 UTC 2015
This is an automated email from the git hooks/post-receive script.
lamby pushed a commit to branch master
in repository source-date-epoch-spec.
commit ec408055ba6c8ad97b6df02f856d39d0d90850c1
Author: Chris Lamb <lamby at debian.org>
Date: Tue Aug 25 21:01:29 2015 +0200
Misc updates; no real value in splitting these out
---
source-date-epoch-spec.xml | 143 +++++++++++++++++++++++++++++++--------------
1 file changed, 100 insertions(+), 43 deletions(-)
diff --git a/source-date-epoch-spec.xml b/source-date-epoch-spec.xml
index 9c7ea1b..ddfbb23 100644
--- a/source-date-epoch-spec.xml
+++ b/source-date-epoch-spec.xml
@@ -32,48 +32,87 @@
<sect1>
<title>Reproducible builds</title>
<para>
- A "reproducible build" is the property of a software package
- whereby two builds of the source produce byte-for-byte
- identical binaries.
+ Whilst anyone can inspect the source code of free software for
+ malicious flaws, for reasons of convenience most distributions
+ provide binary packages to their end users.
+ </para>
+ <para>
+ The idea of "reproducible" or "deterministic" 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.
</para>
<sect2>
<title>Why they matter</title>
<para>
- Projects like Coreboot, Tor and Bitcoin have a strong interest
- in allowing their users to verify that the binaries they
- distribute correspond to the published source code and have
- achieved some success in this area. For Linux distributions,
- doing the same for their repositories is a much bigger job as
- thousands of packages need to be built in a reproducible way.
- </para>
- <para>
- There are other, technical, reasons for adopting
- reproducible builds:
+ Highly privacy-conscious projects such as Tor and
+ Bitcoin have a clear interest in allowing their users
+ to verify that available binaries correspond to ther
+ published source code. Core infrastructure tools such
+ as Coreboot have similar reasons for wishing to empower
+ users in this way.
</para>
- </sect2>
- <sect2>
- <title>Technical issues</title>
<para>
- A reproducible build requires:
+ By providing a "proof" that a given binary has indeed
+ been generated from a given source, a project that has
+ a reproducible build process moves beyond a single
+ point of failure in its distribution process.
</para>
- </sect2>
- <sect2>
- <title>Goal</title>
<para>
- Generally, a better solution is to embed the date of
- the last modification to the source code. This proposal
- attempts to define some standards for tools to operate,
- based on this principle.
+ However, there are other, technical, reasons for adopting
+ reproducible builds:
</para>
+ <itemizedlist>
+ <listitem><para>
+ Encourages the removal of unreliable and/or
+ non-deterministic software behaviour.
+ </para></listitem>
+ <listitem><para>
+ Detects tainted or corrupted build-environments.
+ </para></listitem>
+ <listitem><para>
+ Removes many configuration-specific issues (eg. locale
+ or timezone-related changes to behaviour) eliminating
+ hard to debug problem that can be specific to a user's
+ particular environment.
+ </para></listitem>
+ <listitem><para>
+ Provides a convenient means to test changes to packages.
+ </para></listitem>
+ <listitem><para>
+ Implicitly provides an audit trail from a binary back
+ to the source.
+ </para></listitem>
+ <listitem><para>
+ Validation of cross-architecture built packages.
+ </para></listitem>
+ </itemizedlist>
</sect2>
</sect1>
<sect1>
+ <title>Current problems with timestamps</title>
+ <para>
+ Whilst there are many varied technical issues with, many software packages are unreprodubible simply because they embed the current build-time
+ </para>
+ <para>
+ FIXME: why timestamps become meaningless and/or misleading if
+ the software is reproducible.
+ </para>
+ <para>
+ Generally, a better solution is to embed the date of
+ the last modification to the source code. This proposal
+ attempts to define some standards for tools to operate,
+ based on this principle.
+ </para>
+</sect1>
+
+<sect1>
<title>Proposal</title>
<para>
We propose the following build-time environment variable to be
- consumed by build systems in place of using the "current" time
- and date
+ consumed by build systems and for it to be used in place of the
+ "current" time and date.
</para>
<para>
It is intended to be a universal standard and not specific to
@@ -82,25 +121,23 @@
<sect2>
<title>SOURCE_DATE_EPOCH</title>
<para>
- A UNIX timestamp which is defined as the number of
- seconds (excluding leap seconds) since 01 Jan 1970
- 00:00 UTC. This is independent of timezones, i.e. there
- is no way to specify this "in another timezone".
+ A UNIX timestamp, defined as the number of seconds
+ (excluding leap seconds) since 01 Jan 1970 00:00 UTC.
</para>
<para>
The value is an integer with no fractional component,
- similar to that output by "date +%s".
+ similar to that output by "date +%s". The value is
+ independent of timezones.
</para>
<para>
- Upstream build processes are encouraged to read this
- variable for any embedded timestamps.
+ The actual value should be set to the time of the last
+ modification time of the source. For example, in
+ Debian, this is automatically set to the same time as
+ the latest entry in debian/changelog.
</para>
<para>
- The actual values should be set to the time of the last
- modification time of the source. In Debian, this is
- automatically set to the same time as the latest entry
- in debian/changelog, i.e. the same as the output of
- dpkg-parsechangelog --show-field=Date.
+ Upstream build processes are encouraged to read and use
+ this variable in place of any embedded timestamps.
</para>
</sect2>
@@ -137,11 +174,31 @@
</sect1>
<sect1>
- <title>Examples</title>
- <para>
- A number of examples are available at: <ulink
- url="https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples">https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples</ulink>.
- </para>
+ <title>Implementation issues</title>
+ <itemizedlist>
+ <listitem><para>
+ Care should be taken to avoid timezone and locale-specific
+ formatting of SOURCE_DATE_EPOCH during build-time. If it is
+ deemed essential that an end-user can read this timestamp in
+ their own locale and timezone, this formatting must be delayed
+ until run-time.
+ </para></listitem>
+ <listitem><para>
+ Code should avoid requiring the presence of the variable so
+ that it can still be built outside of a context where this
+ variable is available. Depending on the context, falling back
+ to the "current" time may be acceptable behaviour if the
+ variable is missing.
+ </para></listitem>
+ </itemizedlist>
+
+ <sect2>
+ <title>Examples</title>
+ <para>
+ A number of examples are available at: <ulink
+ url="https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples">https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples</ulink>.
+ </para>
+ </sect2>
</sect1>
<sect1>
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/source-date-epoch-spec.git
More information about the Reproducible-commits
mailing list