> On 13 Sep 2016, at 19:48, Holger Levsen <hol...@layer-acht.org> wrote:
> On Tue, Sep 13, 2016 at 08:14:32AM +0200, Linus Gasser wrote:
>> we’re doing a project where we need to build old package-versions.
> care to explain more?

It’s for a paper-submission to NSDI/Usenix 
<https://www.usenix.org/conference/nsdi17> where we present a software-update 
system based on blockchain-techniques (gotta follow the fads) that tracks 
versions of packages which can be followed in a fast and secure way. There are 
two novelties with regard to other systems: the signature and verification are 
done in a decentralised, distributed fashion, and clients wanting to update 
don’t have to follow each block of the blockchain to get to the latest update.

Now for drawing some nice graphs which show the superiority of our system (it’s 
a paper, after all ;) we’d like to build our blockchain using hashes from your 
reproducible builds, because each node will have to verify that the binary is 
the same, so the most easy way to do it is to look at 
 get the binary-hash, re-build the binary and verify it’s the same.

Thinking of it, we could build each version with the corresponding 
snapshot.debian.org-entry, and re-define our binary hash using that… Thanks for 
asking, it helped a lot - we call it rubber-duck debugging ;)

Some links to our previous work that is the basis of the new paper:

>> We found the buildinfo-files on tests.reproducible-builds.org, but only for 
>> the most recent version of the packages. Is there a way to get these 
>> buildinfo-files for older package-versions, too?
> if you want to rebuild old versions, go to snapshot.debian.org :-)
> Having .buildinfo files from tests.reproducible-builds.org will not gain
> you anything, unless you want to reproduce our *QA* builds, which are
> nowhere to be seen in the wild…

For the moment we don’t care about having ‘in-the-wild’ packages. We want to 
have the timeline of a package with binary-hashes of each version, and a way to 
reproducibly rebuild each version so that the different nodes of the system can 
sign off on it…

But as I wrote above - in fact we can perhaps make our own hash based on the 
snapshots of the package-version we’re interested - which is NOT the same as 
the reproducible build hash, due to some differences in the  dependencies 
(which are great, btw).


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reproducible-builds mailing list

Reply via email to