Research on Reproducible Builds

David A. Wheeler dwheeler at dwheeler.com
Sat Feb 29 16:26:17 UTC 2020


> On Sun, Feb 9, 2020 at 5:14 PM Omar Navarro Leija <omarsa at seas.upenn.edu>
> wrote:
> > Our publication "Reproducible Containers" will be presented in March at
> > ASPLOS 2020. Please follow this link for the final version of the paper:
> > https://github.com/gatoWololo/PersonalWebsite/blob/master/content/dettrace.pdf

Thanks very much for posting about the paper!!
The long list of problems handled and mostly overcome were especially interesting.
I've added a link to it from my page about diverse double-compiling (DDC):
https://dwheeler.com/trusting-trust/

I have questions & comments, I'd love to hear feedback.

The current version of the code is MIT-licensed and posted here, correct?:
https://github.com/dettrace/dettrace

It seems to me that a combination of the current Reproducible Builds work,
PLUS DetTrace, could be a real win. DetTrace has significant performance overheads
for many builds, and doesn't work in some cases (esp. some Java builds).
However, it's clear that some builds may be difficult to make reproducible
through other techniques; using DetTrace to resolve many of the remaining ones.
Does that sound like a reasonable way to use DetTrace?

I'm thinking beyond distro builds, too. I would like to see a day where
language package managers will flag as "dangerous" any packages that
cannot be reproducibly built (and eventually, by default, package managers
wouldn't load them or perhaps they wouldn't be accepted).
It seems to me that this could also be used to run minification & generate
language-level packages - correct?

The paper's description of date handling sounds odd, where "dates" are really
counts of system calls. If the "starting date" is arbitrary (like Jan 1, 1970) that
would look odd. But if the "starting date" were forcibly set to a human-reasonable
value (like the date-time of the last commit, or of the latest source file), then
it might be easier to accept the results. Has that been considered?
(Maybe I missed it?)

I'm looking forward to the day where typical installations have 100% reproducible
software. But getting there requires that it be easy to achieve.
This looks like it might help us get there. Thanks!

--- David A. Wheeler


More information about the rb-general mailing list