search

ungoogled-software / ungoogled-chromium

Google Chromium, sans integration with Google
BSD 3-Clause "New" or "Revised" License
20.46k stars 829 forks source link

Reproducibility challenges? #743

Closed tlaurion closed 2 years ago

tlaurion commented 5 years ago

What are they?

Sent from my Galaxy S3 using FastHub-Libre

Eloston commented 5 years ago

I'm not well informed on the reproducibility of Chromium. From what I have seen, it should be close to or already be capable of building reproducibly, We'll also need to evaluate the packaging processes we have to see if they're deterministic, which would make it easier to compare builds.

mbakke commented 5 years ago

The Guix package builds reproducibly at least. Tested with guix build --no-grafts --check ungoogled-chromium on a machine different from the one that originally built it.

InnovativeInventor commented 4 years ago

@Eloston here is the page where they coordinate work: https://www.chromium.org/developers/testing/isolated-testing/deterministic-builds

Here is the issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=314403

It looks like linux and android build reproducibility is done and other platforms are on their way. I'm going to try to see if I can reproduce their "reproducable" build (lol should be straightfoward) and see if we can use it to solve the trust issue with ungoogled-chromium builds.

InnovativeInventor commented 4 years ago

Update: https://raw.githubusercontent.com/Eloston/ungoogled-chromium/master/pruning.list may prove to be a challenge. @Eloston it looks like on linux at least, some people have managed to create reproducible builds (yay!). Maybe a way to coordinate this would be good? Perhaps the "untrusted" binaries could have PGP/keybae attestations from everybody who was able to reproduce successfully?

InnovativeInventor commented 4 years ago

Yet another update: I've dockerized the build process on debian (so we can pin exact hashes of the version of debian we're building on).

I'll be submitting a pull request once the build finishes (since an end-to-end dockerfile would be useful anyways to have).

lipici commented 4 years ago

good luck guys

Eloston commented 4 years ago

@InnovativeInventor Thanks for the links. Great to hear that Google's made great progress on this.

it looks like on linux at least, some people have managed to create reproducible builds (yay!). Maybe a way to coordinate this would be good? Perhaps the "untrusted" binaries could have PGP/keybae attestations from everybody who was able to reproduce successfully?

That could work, but I think that attestations are marginally useful here because trust is hard to establish (we are all pretty anonymous). Maybe it's more useful if several third-party build servers build the binary and verify the binaries. However, it's still not going to be as valuable as reports that fail reproducibility.

InnovativeInventor commented 4 years ago

@Eloston I was thinking more along the lines of a voice vote: (https://en.wikipedia.org/wiki/Voice_vote).

The idea being, once we get reproducible binaries, we give a place for people to attest/challenge in an open manner. Obviously anybody can build it themselves and check the binaries, but this allows users to feel comfortable that if ungoogled-chromium was compromised, you, me, and a bunch of other people would have to be colluding and somehow nobody outside of the colluding party bothered to run the reproducing script.

Using third-party build servers also helps as well (as another way to attest to the authenticity of a binary).

Combining the above options makes it easier to have trust in the build/release process.

Eloston commented 4 years ago

I understand your perspective, but how do you plan to implement such a system?