
Towards a fully reproducible Debian - lamby
https://lwn.net/SubscriberLink/757118/f2f894279576c348/
======
verytrivial
I would gladly set a "preproducible_only=yes" or whatever config option to
exclude non-reproducible packages from a personal system. This would create a
strong incentive to contribute patches. (I'm hoping someone can point out such
a setting already exists! It didn't last time I checked.)

~~~
rkangel
Unfortunately, such a flag would probably result in weird package
install/update errors as part of the dependency graph would be missing.

~~~
rcthompson
Can a package even be considered reproducible if its dependencies aren't?

~~~
verytrivial
I would argue not, but that's the point, right? Do we have a large enough
well-connected graph of reproducibly buildable packages, and if not, what
should be fixed _first_?

------
algorithm314
NetBSD has fully reproducible builds
[https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...](https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_builds)

~~~
foobarbazetc
The scope here is much larger as it’s every package in the Debian distro, not
just the base system.

~~~
cat199
and pkgsrc has bulk package builds.

same pkgsrc checkout + reproducable base => essentially reproducable full
package builds.

yes, some people will find some niggling way to make this not true because the
binaries may be somehow altered due to timestamps, yadda, but for all
practical purposes w/r/t the actual code and actual executables generated,
this is true, and has been true for essentially the entire existance of bsd
derivitaves using ports systems (1996).

~~~
lomnakkus
> same pkgsrc checkout + reproducable base => essentially reproducable full
> package builds.

I would be truly surpised if that were the case. Are there no packages in
pkgsrc which embed, e.g. timestamps, or even download things while
building[1]?

[1] JDK packages are a typical culprit in this type of situation because
Oracle JDK requires an "accept license" prompt.

> es, some people will find some niggling way to make this not true because
> the binaries may be somehow altered due to timestamps, yadda, but for all
> practical purposes w/r/t the actual code and actual executables generated,
> this is true, and has been true for essentially the entire existance of bsd
> derivitaves using ports systems (1996).

Oh, so you're coopting "essentially reproducable" to mean "not reproducible".
Ok then.

"Reproducible builds" is about _verification_ and isn't just about "close
enough".

------
nikivi
I thought NixOS solves the full reproducibility problem really well already.

[https://nixos.org](https://nixos.org)

~~~
Foxboron
It doesn't. NixOS doesn't do reproducible builds, it does reproducible
systems.

Reproducible builds is essentially about compiling source code to a binary and
always get the same checksum

Reproducible systems is about always getting the same system/behavior given
the same configuration. Which is what NixOS does.

~~~
nikivi
I thought that getting the same system/behavior would require reproducible
builds too. Perhaps I am wrong.

~~~
black_puppydog
If your build process always produces the exact same binaries, and you always
use the exact same environment to run these, then yes, that's reproducible.
It's not equivalent though, in that you can easily have a system that always
exhibits the same behaviour (what NixOS does) but does not use bit-by-bit
equal binaries. For example, some symbols in some library's .so file might be
in a different order, or some padding bits that are never read might be zero
or random depending on your compiler's choice.

------
geokon
So I'm glad this is being done, but the "attack surface" that's being resolved
sounds like a bit of a joke...

"Alice, a system administrator who contributes to a Linux distribution, is
building her binaries on servers that, unknown to her, have been compromised"

This is a bit of weird scenario.. so they're assuming the only build being
compromised is the one that ends up in the repo and no one can confirm that
easily. So just have two (or more) identical servers in separate locations
under different people's control so they aren't both compromised? No need to
fuzz the dates and paths and stuff. Or if you really want, you make a special
Debian version (super-stable) with fixed clocks, file paths, etc. where things
are easy to reproduce.

"Bob, a privacy-oriented developer, makes a privacy-preserving browser, but is
being blackmailed into secretly including vulnerabilities in the binaries he
provides. Carol is a free-software user whose laptop is being attacked by an
evil maid called Eve, the third developer of the title; each time Carol shares
free software with her friends, it is pre-compromised by Eve"

Do Debian contributors just upload a binary blob to the Debian servers and
that's it? I though they were saying they have build servers for every package
and the source from which it's built is available

How about even easier - a bribed/black-mailed Debian maintainer slips in a
patch to some of the tens of thousands of packages they tweak, no one notices
and it gets distributed to everyone. I'm not expert, but it seems the smarter
solution would be to have a much smaller reproducible core/base system (with
Debian patches when necessary). Something that can realistically get enough
eyeballs on it. And then everything else is built by project maintainers into
something like flatpaks/snaps with no patching.

~~~
geezerjay
> So just have two (or more) identical servers in separate locations under
> different people's control so they aren't both compromised?

Considering that you are a DNS spoof away from installing packages from a
compromised server, how does your proposal tackle the underlying problem?

~~~
dmm
> Considering that you are a DNS spoof away from installing packages from a
> compromised server,

This is false. Debian packages are signed. If the signature fails to validate
the package will not install.

~~~
xenophonf
Read 'em and weep:

[https://blog.packagecloud.io/eng/2018/02/21/attacks-
against-...](https://blog.packagecloud.io/eng/2018/02/21/attacks-against-
secure-apt-repositories/)

[https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...](https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf)

"GPG signing a Debian package does nothing because package signatures are not
verified by default on any major distribution when packages are installed with
apt-get install. See your /etc/dpkg/dpkg.cfg file for an explicit comment to
this effect."

And:

"When APT software (such as apt-get, or reprepro) or folks offering APT
repositories mention GPG signatures in their documentation they are typically
referring to GPG signatures on repository metadata, not on packages
themselves. Likewise, when you configure the SignWith option of reprepro
(documented here), you are telling reprepro to sign your repository metadata
with the specified GPG key; this does not sign any of the packages, though."

~~~
lamby
> GPG signing a Debian package does nothing because package signatures are not
> verified by default on any major distribution when packages are installed
> with apt-get install

That's sliiiiiiightly misleading. :/

~~~
xenophonf
On both Debian 9.4 and Ubuntu 16.04 (what I have handy):

    
    
      # Do not enable debsig-verify by default; since the distribution is not using
      # embedded signatures, debsig-verify would reject all packages.
      no-debsig

