GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-07-23) - page 1 of 10
 
___________________________________________________________________
Status update from the Reproducible Builds project
101 points by lamby
https://lists.debian.org/debian-devel-announce/2017/07/msg00004....
___________________________________________________________________
 
gtt - 1 hours ago
How do they achieve reproducibility with python and some other
languages which include timestamps and such?
 
  anonacct37 - 1 hours ago
  https://reproducible-builds.org/docs/timestamps/
 
  JoshTriplett - 1 hours ago
  Sometimes by eliminating the timestamps (don't put __DATE__ and
  __TIME__ in C code, for instance), but when that isn't
  possible:https://reproducible-builds.org/specs/source-date-epoch/
 
  mapreri - 1 hours ago
  Also, Debian binary packages don't ship prebuilt python bytecode,
  which is compiled at installation time.  (just to reply to the
  specific example)
 
  rnhmjoj - 1 hours ago
  On NixOS python is patched so that if the environment variable
  DETERMINISTIC_BUILD is present the interpreter set the bytecode
  timestamps to 0. I suppose they did something similar.
 
adamb - 37 minutes ago
Beyond providing security, reproducible builds also provide an
important ingredient for caching build artifacts (and thus
accelerating build times) across CI and developer machines. They
also can form the basis of a much simpler deploy and update
pipeline, where the version of source code deployed is no longer as
important. Instead a simple (recursive) binary diff can identify
which components of a system must be updated, and which have not
changed since the last deploy. This means a simpler state machine
with fewer edge cases that works more quickly and reliably than the
alternative.I'm very grateful for the work that this project has
done and continues to do. Thank you!
 
morecoffee - 32 minutes ago
Once we have reproducible builds, will it be possible to have
verifiable builds?  As in, can we cryptographically show that
source + compiler = binary?Right now we can sign source code, we
can sign binaries, but we can't shows that source produced
binaries.  I would feel much happier about installing code if I
knew it was from a particular source or author.
 
  detaro - 26 minutes ago
  What do you mean by "cryptographically show"? With reproducible
  builds, anyone that has repeated a build can verify that a
  claimed binary matches, and could sign a statement saying so. But
  I don't think there are solutions that don't include someone
  repeating the build, or a clear way of proving that you actually
  did repeat the build.
 
  zcdziura - 25 minutes ago
  Just curious: how does one do that? Hash both the binary and
  source code files, that THAT hash, then sign it? Or am I
  completely off?
 
seagreen - 1 hours ago
Amazing work. Thanks so much to everyone who's contributing. The
upstream bugs filed are especially appreciated since they make the
whole Linux ecosystem more solid, not just Debian.
 
  jbergstroem - 1 hours ago
  Not just Linux; FreeBSD and NetBSD have been along the ride for a
  while: https://reproducible-builds.org/who/
 
    seagreen - 46 minutes ago
    Whoops, good point. Didn't mean to be so Linux-centric.
 
    cperciva - 8 minutes ago
    In some cases, a very long while.  I brought up the question of
    build reproducibility at BSDCon 2003 because it was relevant to
    FreeBSD Update, and a lot of my early FreeBSD commits were
    working on this.
 
    protomyth - 1 hours ago
    with NetBSD stating "As of 2017-02-20 we have fully
    reproducible builds on amd64 and sparc64."
    https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...
 
    [deleted]
 
cperciva - 1 hours ago
Does anyone know if they've made the Packages file (repository
metadata file, listing the packages in the repository) build
reproducibly yet?I tripped over this a couple weeks ago and was
both amused and annoyed, since it seemed that packages were being
listed in the file in a random order.  I'm asking here because it
might already be fixed; we're using a slightly old version of the
package/repository tools.
 
  lamby - 1 hours ago
  Not yet. Could you file a bug report?
 
    cperciva - 38 minutes ago
    I'll ask my Debian expert to do that.  I don't know which
    package is responsible here, and that seems to be the first
    step towards filing a bug report.
 
      lamby - 6 minutes ago
      File against the "ftp.debian.org" pseudopackage. :)
 
        cperciva - 2 minutes ago
        Really?  The problem arose when we were building packages
        for pkg.tarsnap.com, so it's a tools problem rather than an
        infrastructure problem...
 
  jwilk - 1 hours ago
  Why do you care about the order of packages in Packages?What does
  "build reproducibly" even mean in this context?
 
    cperciva - 39 minutes ago
    Why do you care about the order of packages in Packages?In my
    personal case, so that when I build a repository which has some
    new packages and some old packages, when I look at the
    resulting pull request in github I can see that the packages
    which haven't changed have indeed not changed.What does "build
    reproducibly" even mean in this context?Two repositories with
    the same packages have identical Packages files.  Or for me,
    slightly more generally, when the Packages file changes, it
    changes as minimally as possible.
 
    viraptor - 57 minutes ago
    Two repositories with same content should have same metadata.
    For the same reasons we want reproducible binaries - to spot
    differences. (Also prevents useless re-download in some cases,
    I guess)
 
  [deleted]
 
phreack - 1 hours ago
In case anyone is not aware of what reproducibility is and why it's
a worthy goal, here's their statement:
https://wiki.debian.org/ReproducibleBuilds/About
 
pen2l - 1 hours ago
What does "reproducibility" mean? I understand and appreciate the
importance of reproducibility in the context of scientific
experiments, but I don't understand what it means in terms of
computer programs. I am guessing it has to do with being able to
build on different architectures without issue?
 
  richdougherty - 1 hours ago
  I think it's for security. It means that there's a deterministic
  relationship between the source of a program and its final
  compiled artifacts.If software has reproducible builds that means
  that third-parties can independently verify that artifacts have
  been built safely from sources, without any sneaky stuff snuck
  in.
 
  CJefferson - 1 hours ago
  No, the same architecture.It has taken, and continues to take, a
  suprising amount of work to make two builds of a program produce
  the same output.There are many sources of issues. For example:
  date and time stored in output, program's output effected by
  order in which files are read from a directory (and is not having
  a fixed ordering), hash tables based on the pointer and the high
  objects are stored having different ordering on different
  executions, parallel programs behaving differently on different
  runs, and others.
 
  jldugger - 1 hours ago
  It's about being able to reproduce the binary from source. You
  might think this is pretty much impossible in the Debian context,
  but things like timestamps, and underspecified dependencies can
  end up shifting a build's result over time.If we want to insist
  that open source code is secure by source code analysis, we need
  a verifiable build chain, that the code and binaries an analysis
  uses are the same as what we get later.
 
  cyphar - 1 hours ago
  It has a similar meaning to research. What it means is that you
  can reproduce (compile in most cases) from source code the same
  bit-for-bit identical binary independently. While this might
  sound like something that should be trivial to do, it turns out
  to be far from trivial (timestamps and other environment
  information leaks into binaries all the time).There's a website
  that describes this project in much more detail as well as how
  they worked around the various problems they found. https
  ://reproducible-builds.org/
 
  detaro - 1 hours ago
  It means ensuring that anyone can verify that a binary was
  created from a given set of source code, by recompiling it and
  getting the exact same file.
 
  wongarsu - 1 hours ago
  It means each time you build the same code in a known setup, you
  get bit for bit the same binary. That allows you to assure that
  the code that's shipped actually matches the source code.It
  sounds trivial, but the full paths and timestamps that get added
  at multiple points in the process are enough to screw this up,
  and those are the easy problems.
 
  cesarb - 56 minutes ago
  In the context of "reproducible builds", it means that if you
  compile the same source code with the same compiler and build
  system, the output will be completely identical, bit by bit. This
  is surprisingly hard to achieve in practice.Once they have
  reproducible builds, they can easily prove that each binary
  package was built from the corresponding source code package:
  just have a third party compile the source code again and
  generate the binary package, and it should be identical (except
  for the signature). This reduces the need to trust that the build
  machines haven't been compromised.
 
dingdingdang - 1 hours ago
So happy someone are spending time on this issue, it's like a
breath of fresh air and intelligence in the midst of all the usual
software (security/privacy/etc. take your pick) mayhem. It's worth
reading https://reproducible-builds.org/ for a brief (re-)reminder
on why this project is important.Outtake: "With reproducible
builds, multiple parties can redo this process independently and
ensure they all get exactly the same result. We can thus gain
confidence that a distributed binary code is indeed coming from a
given source code."
 
  Kenji - 59 minutes ago
  Reproducible builds are extremely useful. There are more
  benefits. For example, suppose you have a build server compiling
  software packages. If your builds are not reproducible and you
  want to debug a core dump, but you have no debug information, you
  are out of luck (well, you could dive into the assembly code, but
  it's inconvenient). If you want to keep debug information, you
  need to store them for every single build (what a waste of
  storage...) because the binary for each build is different. Not
  so with reproducible builds, you could simply check out the old
  version and compile it with debug information!
 
    bennofs - 9 minutes ago
    Well, reproducible builds doesn't necessarily mean that it
    stays reproducible when you turn on debug info.
 
    mschuster91 - 54 minutes ago
    Most huge Debian packages carry a separate -debug package so
    you can get the symbols without huge recompilation times +
    having to set up a buildchain  and associated dev libraries of
    all the packages.
 
      jakeogh - 7 minutes ago
      Similarly Gentoo has 'splitdebug': https://wiki.gentoo.org/wi
      ki/Project:Quality_Assurance/Backt...
 
pmoriarty - 1 hours ago
How does the kind of reproducibility spoken of here compare to that
offered by Guix and Nix?
 
  arianvanp - 34 minutes ago
  Guix and Nix are input-reproducible. Given the same input
  description (input being the source files and any dependencies)
  an output comes out. Builds are then looked up in a build cache
  based on the hash of al lathe combined inputs. However. The
  _output_ of Nix artifacts are not reproducible. Running the same
  input twice will yield a different result.Nix does some tricks to
  improve output reproducibility like building things in sandboxes
  with fixed time, and  using tarballs without modification dates
  but output bit-by-bit reproducible is not their goal. They also
  don't have the manpower for this.Currently, a build is built by a
  trusted builderver for which you have the public key.  And you
  look up the built by input hash  but have no way to check if the
  thing the builderver is serving is legit. It's fully based on
  trust.However, with debian putting so much effort in reproducible
  output, Nix can benefit too.  In the future, we would like to get
  rid of the 'trust-based' build servers and instead move to a
  consensus model. Say if 3 servers give the same output hash given
  an input hash, then we trust that download and avoid a compile
  from source. If you still don't trust it, you can build from
  source yourself and check if the source is trustworthy.Summary:
  Nix does not do bit-by-bit reproducibility, but we benefit
  greatly from the work that debian is doing. In the future we will
  look at setting up infrastructure for buildservers with an
  output-hash based trust model instead of an input based one.
  However this will take time.Feel Free to ask any other questions.
 
    rekado - 13 minutes ago
    > output bit-by-bit reproducible is not their goalI think you
    are wrong.The Nix people (and the Guix people, including
    myself) are also involved in the reproducible builds project.
    I've met with a couple of them in Berlin last year.  It's not
    just Debian doing this.I can't speak for Nix but for the Guix
    project bit-for-bit reproducibility is an explicitly stated
    goal.  It's very important and the reason why Guix is used in
    several HPC environments as the foundation for reproducible
    research.Disclaimer: I'm co-maintainer of GNU Guix and
    currently at a bioinfo conference where I talked about Guix and
    reproducibility.