
“Packages should be reproducible” added to Debian Policy - lamby
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431
======
dankohn1
I helped provide financial backing for the Reproducible Builds project at the
Linux Foundation's Core Infrastructure Initiative [0]. Holger, Lunar and the
whole team deserve a huge amount of credit for beginning this when it seemed
pie-in-the-sky and growing it to now become the standard for a lot of our
infrastructure.

[0] [https://www.coreinfrastructure.org/projects/reproducible-
bui...](https://www.coreinfrastructure.org/projects/reproducible-builds)

~~~
lamby
Thank you, Dan ;)

------
gizmo686
>Any packages that absolutely cannot be built in a reproducible way[1] ... [1]
Such as random noise added to kernel and firmware data structures during local
builds, to be used as a last defense to avoid the _herd using same keys_
effects, etc.

Shouldn't this example of randomness still be pushed to the installation
stage, instead of in the distribution. If Debian's binary package contains a
"random" key, then we have a pretty large herd already using it.

~~~
progval
You don't always have randomness available at boot

~~~
jacquesm
Sure but if it is hard baked into the distro it is no longer random any more
than '4' is random.

------
astrodust
Is there any way to create some kind of proof-of-work system where people who
want to back the project can volunteer computer time to verify builds
automatically and serve as a foil to any potential attackers?

Some kind of blockchain-like trust verification system isn't the craziest idea
I've ever pitched.

~~~
AgentME
Proof-of-work systems have to be slow to compute but quick to verify. This
problem is equally slow to compute and verify, because you also have to
compile a package to check someone else's assertion that the source compiles
to a given binary.

~~~
astrodust
They necessarily have to be slow to compute, but they don't neccessarily have
to be quick to verify. The higher the verification cost is, the less likely
people are to pay it, but that doesn't mean it might not be "cost effective"
under some circumstances.

Like if 500 people can independently confirm a build produces a binary with
result X then they could all share in the reward, whatever that is.
Nanokarmas?

Other systems are designed to be more asymmetric in order to facilitate scale.
Crypto coins would never work at all if to verify a possible hash you had to
spend days mining to reproduce the work. Spending five minutes compiling a
program to achieve consensus isn't a problem.

The problem is in verifying that someone actually did the work and didn't
steal someone else's solution. Maybe encrypting the result you get and sending
it off in escrow to a centralized verification location would work, and once a
sufficient number of solutions are collected the solutions are unsealed and
the results shared so everyone can see what happened and raise any objections.

~~~
AgentME
Verifying a proof-of-work has to at least be quicker than computing the proof-
of-work. Verifying and computing can't be literally the same operation. That's
not a proof-of-work.

>Like if 500 people can independently confirm a build produces a binary with
result X then they could all share in the reward, whatever that is.

In a cryptocurrency blockchain, every single node verifies every block
received from another node in order to check whether it should be included in
the node's local copy of the blockchain. If computing and verifying are the
same operation, it's not "500 people independently verify a source produces a
given binary and the rest of the network rewards them", but "the entire
network verifies that a source produces a given binary and they all equally
pat each other on the back". Unless you only reward the first to verify a
build, but then no node would bother spending time verifying blocks made by
other people and building off that chain rather than mining its own blocks if
they both take as long as each other.

>The problem is in verifying that someone actually did the work and didn't
steal someone else's solution.

Bitcoin uses the hash of the rest of the block (which includes the address for
the reward of the miner who is doing the proof-of-work) as an input into the
proof-of-work such that the result of the proof-of-work is only valid for that
input. It's not apparent to me whether where there could be room to add an
input like that into checking whether a source compiles to a binary. (I
thought through whether you could make a Lamport-signature-like scheme
involving picking specific intermediate values generated during the
compilation that correspond to parts from a pre-committed series of hash
pairs, but then I realized it wouldn't work because anyone who does the build
once would get all of the intermediate values and be able to create as many of
these signatures as they wanted for little effort.)

>Maybe encrypting the result you get and sending it off in escrow to a
centralized verification location would work, and once a sufficient number of
solutions are collected the solutions are unsealed and the results shared so
everyone can see what happened and raise any objections.

Sounds like what you're looking for is some kind of web-of-trust reputation
system with a trusted authority rather than a cryptocurrency blockchain. (If
you have a trusted authority, then nearly all of the design of a bitcoin-like
cryptocurrency is ridiculous dead weight. You can shed nearly everything, you
don't need a broadcast-everything blockchain, and you could choose to have
really cool things like blind signatures for anonymous transactions.) (Though
_if_ you have a trusted authority who can afford to be running build
processes, it'd be a lot simpler to just have them do all the build-verifying
for you, and you could do away with anything discussed in this post and just
have them publish a PGP/HTTPS-encrypted webpage with their results.)

------
thinkMOAR
Does this include CPU optimizations build options? Or specific cpu
instructions still count as 'reproducible'?

------
k__
maybe they should switch to Nix... wait!

~~~
kanzure
Migrating Debian to nix might be possible, if that was desirable. You could
have a compatibility layer for a while, and once everything is using the
compatibility layer (in about 200 decades?), you deprecate the old package
management details.

~~~
k__
I think Nix is the superior package manager, but you can already usw it with
Debian for years now and not many people do it, so the problem seems to lie
somewhere else...

~~~
vertex-four
Nix doesn't integrate with Debian well - you can also use yum on Debian and
nobody does that either. If you're using Debian, it's because you want to
manage a Debian system with Debian packages.

~~~
madez
I use Debian and I do not like to manage the Debian system with Debian
packages. I use Debian because it is the community-backed distro.

~~~
int_19h
_A_ community-backed distro, surely? There's also Arch, and others.

