Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reproducible build support #251

Open
mwleeds opened this issue Nov 30, 2017 · 8 comments
Open

Reproducible build support #251

mwleeds opened this issue Nov 30, 2017 · 8 comments

Comments

@mwleeds
Copy link
Collaborator

mwleeds commented Nov 30, 2017

Currently in order to trust a flatpak built by a 3rd party you have to trust that entity (e.g. flathub). But if flatpak builds were reproducible, anyone could verify that a certain (resolved) manifest pointing to source code results in the same binary. See reproducible-builds.org for more info.

@maci0
Copy link

maci0 commented Dec 1, 2017

+1

@alexlarsson
Copy link
Member

I'm not sure why this is a flatpak issue though? I mean, yes, reproducible builds are good, but that is up to whoever writes/packages the app, and not on flatpak itself.

@mwleeds
Copy link
Collaborator Author

mwleeds commented Jan 4, 2018

I would think flatpak could help by providing a way for the user to verify that the built flatpak is identical to what others have built, but I'd have to look into it more to know if that's possible or what that would look like.

@TingPing
Copy link
Member

TingPing commented Jan 4, 2018

It would be relatively easy for at export time to do the same sanity checks that the Debian and OpenSUSE tools do to check for non-reproducable output like dates or build paths being found in binaries. (gcc has a warning for including dates, could enable that by default too)

@swick
Copy link

swick commented May 15, 2018

What might be a good idea is an option in flatpak-builder which builds the same manifest two times but with a different environment. flatpak already fixes some sources of non-reproducible builds but there still are other sources (time, locale, file ordering, username, things in /proc like cpuinfo, env vars). The output could be a file with those variations and the two builds to run diffoscope over.

edit: also something in flatpak-builder to compare your build with the build of an app that's already installed

@matthiasclasen
Copy link
Contributor

seems more like a flatpak builder issue

@matthiasclasen matthiasclasen transferred this issue from flatpak/flatpak Jan 8, 2019
@alexlarsson
Copy link
Member

Having rebuild-and-run-diffscope would be a very nice tool to have for this.

@mulles
Copy link

mulles commented Apr 11, 2020

Just want to point out that Purism the Company behind PureOS and the Librem5 Phone, are interested or may even investigate reproducible builds for flatpaks:

With the addition of reproducible builds, which we have every intention of bringing into PureOS, that process will get stronger so that you can build an upstream PureOS (or Debian) package from upstream source on your machine and it is byte-for-byte identical.

Source: https://forums.puri.sm/t/why-promoting-flatpak-for-pureos-store/4942/40

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants