Reproducible builds

allddd

I've been using GOS for a while now and in my opinion it's the best (perhaps the only) option if you want an OS that is secure, private and usable all at the same time. However, I don't understand why neither the community nor the developers seems to care much about reproducible builds.

Sure, having secure code in a repository is nice, but if you can't check that the thing running on your phone matches what's in the repository, you could be running malware for all you know. I've only been able to find a single project doing something that should, in my opinion, be part of the GOS project: https://github.com/lucasbeiler/reproducible-builds-grapheneos

I'm not sure if you can even call something secure if it's based on trust alone. Everybody makes mistakes and even if not intentional, something could potentially get injected during the build process and be on everyone's phone a few days later. We need a system where anyone can build the software if they want, ideally while multiple independent entities verify each release for those who don't have the knowledge or resources to do it themselves.

privacyisconsent

allddd

Some instructions are provided at https://grapheneos.org/build#reproducible-builds. Would it not just be a case of rustling up some community effort to verify the aspects described in the documentation?

de0u

allddd https://github.com/lucasbeiler/reproducible-builds-grapheneos

Looks pretty impressive!

allddd I don't understand why neither the community nor the developers seems to care much about reproducible builds.

As pointed out by privacyisconsent, the GrapheneOS developers cared enough to publish some directions. And as you pointed out, a member of the community cared enough to set up a CI build pipeline that reports deltas.

allddd We need a system where anyone can build the software if they want, ideally while multiple independent entities verify each release for those who don't have the knowledge or resources to do it themselves.

Lots of people already do build the system, so it seems as if we're good on that part. The GrapheneOS project sort of structurally can't set up independent builders (or they wouldn't be independent). So perhaps this post is a request for independent entities to leverage the CI work that has been done? I suspect it costs something, so perhaps this post is an offer to donate funds to an independent build entity?

allddd Instructions on how to set up the environment, along with the scripts that build the releases, could simply be shared with the community, rather than us having to "reverse engineer" something that already exists.

I haven't been tracking this. Have issues been filed requesting details beyond the information already provided by the project? For example, have issues been filed in the repository for the web site, which, again, already has some information about repeatable builds?

allddd

privacyisconsent
These instructions give you a general idea of how to do it, but much more than that is required to automate testing of releases. Just compare the instructions to the scripts in the project I linked above and see how much is missing.

I’m not exactly sure how the releases are built, but I assume they use some containerized/virtualized environment. Instructions on how to set up the environment, along with the scripts that build the releases, could simply be shared with the community, rather than us having to "reverse engineer" something that already exists.

allddd

de0u

the GrapheneOS developers cared enough to publish some directions.

As I said above, I don't think it's really enough for a security-focused project. Look at the instructions provided by the Signal developers, for example. They provide the container used for building, which anyone can use to create an identical .apk. I know you can't really compare a whole OS with a single app, but hopefully you understand what I mean.

The GrapheneOS project sort of structurally can't set up independent builders.

Of course. However, they can provide instructions on how to configure the build infrastructure and the scripts used for building, which would enable me to run it myself without having to "develop" something that already exists.

Have issues been filed requesting details beyond the information already provided by the project?

Not that I know of, which is why I'm surprised by the lack of interest in such an important topic.

de0u

de0u The GrapheneOS developers cared enough to publish some directions.

allddd As I said above, I don't think it's really enough for a security-focused project.

Lots of things are dissatisfying for lots of people. Then the question is what actions might potentially improve any given situation.

de0u Have issues been filed requesting details beyond the information already provided by the project? For example, have issues been filed in the repository for the web site, which, again, already has some information about repeatable builds?

allddd Not that I know of, which is why I'm surprised by the lack of interest in such an important topic.

I don't speak for the GrapheneOS developers, but clearly there are many things calling for their time. Maybe it would be better for the senior developers to spend 10 hours improving the directions for builds, or maybe it would be better for those 10 senior developer hours to be spent negotiating with an OEM to provide a new hardware platform which would be a Pixel alternative. I don't know.

But I do suspect is that if somebody wants to see improvements in the repeatable-build situation then it seems more likely to happen if somebody files an issue in the repository for the web site, asking for specific information. It would probably be best if such an issue filing came from somebody who has already done some work on repeatable GrapheneOS builds.

If Party A ships a great OS and also spends time writing directions on how to build it, and Party B spends a fair amount of time setting up a CI build pipeline, and Party C complains that neither Party A nor Party B nor "the community" "seems to care much" about reproducible builds, that certainly qualifies as an opinion, but it's not clearly an action plan.

Perhaps Party C could offer to donate money to Party B to fund continuing efforts by Party C -- sometimes even a small donation can be big encouragement. Perhaps Party C could encourage Party B to file issues requesting specific information. Those might be more effective than Party C speculating about what "the community" "cares about".

P.S. https://discuss.grapheneos.org/d/18927

GrapheneOS

allddd

As I said above, I don't think it's really enough for a security-focused project. Look at the instructions provided by the Signal developers, for example. They provide the container used for building, which anyone can use to create an identical .apk. I know you can't really compare a whole OS with a single app, but hopefully you understand what I mean.

GrapheneOS builds are reproducible across operating systems. We shouldn't need to provide anything else beyond what we do. We use the standard AOSP toolchain.

Of course. However, they can provide instructions on how to configure the build infrastructure and the scripts used for building, which would enable me to run it myself without having to "develop" something that already exists.

We provide information on what's required.

Not that I know of, which is why I'm surprised by the lack of interest in such an important topic.

Why do you think there's lack of interest in it?