During repro build discussions the other day, I think I got a bit better
understanding of "build environment". Feel free to share these notes in
any other forum where it's relevant.
My high-level context is considerations for installing a "transparent
binary". Then I or my install agent will rely on source claims and build
claims:
SC: A source claim says "A source package with name, version, hash
(maybe other metadata) is an officially released package". The claim
is made by a source authority, e.g., debian release team deciding
what goes into a release, or any software maintainer deciding what
are the official releases of their package. (Note there's no claim
about package quality, only intention of "officially" releasing it).
BC: A build claim says "Building this source package (identified by hash)
produced these binaries (identified by hash).".
Both types of claims need to be transparently logged, to get a consensus
on what's being released, and what corresponding binaries are.
By getting a source claim and several build claims from independent
builders, I can get some confidence that a binary corresponds to the
official source package, and decide to install it.
Now, I'd like a build claim to be falsifiable: Given a build claim, I
should be able to get the corresponding source package, build it, and
see if I get the same binaries as output. A source package typically
includes information on build dependencies, but not sufficient to pin
everything the build depends on. I see some different kinds of
dependencies:
1. Traditional build deps, like, "needs a c11-capable compiler, and the
Foo library of at least version 1.7." These specify what's necessery
to get a successful build.
2. Build environment, by which I mean details where variations are
expected to produce different but acceptable build outputs. E.g.,
version of the compiler and other code-generation tools used, and
precise version of the libraries linked to. It's not clear to me
which of these things should be identified by a cryptographic hash,
and which could use some other kind of ids.
3. Auxilliary environment (for lack of better term): Circumstances that
are not expected to affect the resulting build outputs. E.g., kernel
version should not matter, even though it's *possible* that a buggy
or malicious kernel could make the build outputs different.
I'm also thinking that the build environment specifies things that the
builder will configure separately for each of its builds, while the
auxillary environment is fixed, only modified at general
hardware/software updates of the builder.
My thinking is that (1) should be part of the source package (and
indirectly, in the SC), (2) should be part of the build claim (BC). It
makes sense that some information of type (3) for each build is
recorded, for trouble shooting when builders get different results for
the same source package and build environment, but I don't think about
it as part of the build claim.
Responsibility is different for the build environment and the auxilliary
environment: The party operating a builder can take responsibility for
the auxilliary environment: E.g., depending on the BC:s signed by a
particular builder implies some level of trust that the builder doesn't
run a malicious kernel, and I think that's reasonable.
Question then: Who's responsible for the build environment? Since we
want builds to be reproducible, the build environment is *not* under the
control of the party operating the builder: For the builder to be
useful, it has to use the same build environment (for each particular
source package) as has somehow been decided by others. Therefore, the
builder is not in a position to claim that the build environment is
appropriate.
A build environment specifying a malicious version of a compiler or
library is obviously a threat to the user about to install the resulting
binaries. So we need someone to take responsibility for that, in a
transparent manner. Which brings us to build environment claim:
BEC: A build environment claim says "The build environment BE is
appropriate for building source package X". (One could maybe
consider more general claims, "It's appropriate to to base the
build environment, for a large set of source packages, on latest
versions of debian stable as of time T", but that will be somewhat
difficult to verify by the user, so let's stick to a per source
package build environment claim for now).
In case we have a structure with a primary builder and rebuilders, e.g.,
primary builder being a debian buildd machine, it seems easiest to make
the primary builder the build environment authority. It needs to
communicate its choice of build environment to the rebuilders (to enable
reproducibility). It also needs to communicate a signed and
transparently logged build environment claim to the end user.
It may be possible to treat the BC from a primary builder specially: If
a build claim is signed not by any builder but by the primary builder,
then it implicitly implies the claim that the build enviroment is
appropriate. But since no other builder can make that claim, I think
it's clearer to keep it out of the BC.
A final note on build environment vs auxilliary environment: Whenever
possible, it's desirable move information from the build environment
(and hence, from the BC) to the auxilliary environment. This needs a
case-by-case analysis. E.g., when building gcc, the build dependencies
must say that it needs a C++ compiler. But which one shouldn't matter,
since it affects only the stage1 binaries, while the final stage3
binaries are independent of which compiler was used during stage1. So
the initial compiler for stage1 belongs with the auxilliary environment,
and it improves confidence in the resulting gcc binaries if the builders
use different compilers during stage1 of the build.
Regards,
/Niels
