Skip to content
This repository has been archived by the owner on Oct 6, 2021. It is now read-only.

Reproducible Builds #17

Closed
paragonie-scott opened this issue May 2, 2016 · 3 comments
Closed

Reproducible Builds #17

paragonie-scott opened this issue May 2, 2016 · 3 comments

Comments

@paragonie-scott
Copy link
Member

We need to be able to say, "Yes, this build was reproduced identically from the source code."

The only way I can think to do this reliably is to spin up a cluster of servers running Pharaoh (and equivalent) to diff the Phars for each package.

When a developer uploads a file with barge, they must include a git commit ID, which will be used in conjunction with their repository URL to ask Pharaoh to reproduce it.

My "it's 1:40 AM and I need sleep but want to get this on paper" thoughts on this:

  • Should we run the checks locally? (By installing Pharaoh.)
    • This should probably at least be an optional failsafe.
  • This requires that the project be open source for the "reproducible": true flag to get set by the channel when the user retrieves updates.
  • What do we do if the project is closed source?
    • Mark it as unreproducible when the user is selecting gadgets, motifs, etc.?
    • Fail open -- it's not open source anyway so we can't guarantee the security here.
  • What do we do if the project is open source but the reproducibility verification fails?
    • Let the user AND the supplier set their policy; most restrictive wins?
      • Require reproducibility? Y/N

If @defuse has any comments, I'd love to hear them.

@paragonie-scott
Copy link
Member Author

This is still a high priority for me, but I'm going to wait until after the second beta to address it.

@paragonie-scott
Copy link
Member Author

I've decided against automating this verification. Instead, the information should be available to the end user. The tools (barge and Pharaoh) already exist to perform this verification.

Every extension update that goes into Keyggdrasil should include the current URI of the version control software and the commit hash of that update. This way, the information is public and auditable. If someone wants to verify that the package in the archive is the same one they build from the source code, they can. If even one person does, since everyone sees the same thing, it strengthens the security of everyone.

Caveat: Only open source packages can be truly delivered securely.

Thanks @defuse for confirming we don't need this to be automated and provided for the users.

@defuse
Copy link

defuse commented May 19, 2016

Yep, exactly right.

@paragonie-scott paragonie-scott removed this from the Version 1.0.0 milestone Jun 9, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants