Document comprehensive explanation of "official binaries"

[Eloston]

We need a comprehensive document to explain to users why "official binaries" doesn't make sense for this project. Motivation includes #1534 #1532 #743 (if there are any more related issues/discussions, please feel free to reference them here)

Rough topic coverage (not indicative of final ordering or structure):

1. What is an "official binary"? What is trustworthy from the user's perspective?
2. The ungoogled-chromium community: What trust looks like and how it differs from self-trust.
3. Increasing trustworthiness: What is the status-quo, and what can we improve? Discuss the following mechanisms:

• Reproducible binaries
• Third-party CI/CD services (especially the challenges with the scale of Chromium; this might need its own document in the future)
• Binary signing
• Anything else?

As usual, I'm open to ideas, including rough drafts (if any of you are interested in the writing challenge). I plan to write this up even in the absence of any feedback.

[PF4Public]

I plan to write this up even in the absence of any feedback.

Please do! This will solve this kind of questions (and probably confusion) once and for all.

My 50 cents follow:

What is trustworthy from the user's perspective?

Each user may define trustworthiness in his own way. Some may accept binaries from another (prominent?) users, some may accept them from everyone except Google. But given the nature of this project, it is expected that trust should be given a special consideration.

Challenges of providing an "official binary"

Those, that you've quoted.

• Third-party CI/CD services are inherently third-party with corresponding trust issues

Ideally one should consider the path of an "official binary" starting from application of scripts from this repo onto Chromium sources up until it is on a harddrive of a user, who may (should?) have the ability to verify the binary was not modified anywhere in-between. BTW as a first step here you may consider hashing the chromium-%(_chromium_version)s.tar.xz and keeping those hashes in chromium_version.txt for anyone willing to check, documenting this process for end-user. This is what Gentoo does actually: www-client/ungoogled-chromium/Manifest. True, there are hashes from Google servers, but we're talking about trust here, right?

What is an "official binary"?

One does not exist given the reasoning above. Everyone is advised to build him/her-self. There are however some contributed binaries, which are provided in a good faith, but should be used discretionary (link to binaries).

[wchen342]

An argument I saw often in the past is that, the binaries we currently provide (even when it comes to the ones in OBS, which technically is not true) are built by unknown users on the internet that cannot be verified and cannot be proven trustworthy. The fundamental problem here, if I interoperate this correctly, is that the project lacks an public presence that can represent the project socially, and probably legally. An simple example will be Servo which is previous supported by Mozilla and now Linux Foundation, which are organizations people can trust, so they know they are likely be downloading something legit when downloading binaries from their official website. But we do not have that kind of figure. Of course, because of the natural of the project as it is completely done by volunteers, this kind of public figure is hard to establish, thus it will be very hard to provide anything "official" because of the lack of an "official" presence in the first place.

[harry963]

Hello, I was the person who wrote #1532 so I thought I would give my insight.

1. What is an "official binary"? I think an official binary would be a first party binary built by the ungoogled-chromium team.

2 & 3 I think trust would be a first party, reproducible binary. Most people compiling the browser aren't reading every line of code to see if you stuck any malware in it. They simply trust the ungoogled-chromium team. Most people do not, however, trust these contributor binaries. I may be mistaken (as wchen mentioned otherwise) but I'm pretty sure they're just coming from random people. I also remember reading that the reason Arch pulled all the ungoogled-chromium-bin packages from the AUR was because the binaries weren't endorsed/first party builds. Reproducible binaries also help build more trust that the source code hasn't been tampered with at the compile time. You also mentioned binary signing which I believe would also be a welcome addition.

Before I end this, I wanted to share some ideas on how this first party binary could work:

• I mentioned a portable build in my issue as this would be much less work for the team as maintaining one Linux binary is better than having to maintain one for each distro. Pale moon have an official portable build where the users can download it, extract it and just run it without needing to install it.
• Including it in Guix or Nix would be nice as it would make it easy to install and update with just a single command and since they're both distro agnostic it would mean that the team once again wouldn't have to focus on different desktop Linux builds.
• App image - not sure what the pros and cons of this would be. I would strongly prefer if it wasn't distributed as a flatpak or snap, as both have their own problems.

[wchen342]

Most people do not, however, trust these contributor binaries. I may be mistaken (as wchen mentioned otherwise) but I'm pretty sure they're just coming from random people.

There are two kinds of binaries (and this adds to the confusion, yes), the ones from ungoogled-chromium-binaries which are contributed by random people, and the binaries builds under each platform's repo (for example, for Fedora/Debian it is on OBS). I think a large part of the confusions comes from the fact that these two kinds of different binaries are not distinguished clearly in Readme.

It is also not really clear what the ungoogled-chromium team shall be too. There is @Eloston who created the project, and there are several people that has been here for long like @PF4Public and @braewoods, but people comes and goes and it is the nature of a loosely organized open source project. There is no board or something like that so it is hard to say who shall be responsible. I think the split of different platform repos make this even more complicated because you have different people maintaining different platforms.

Personally I prefer the Guix solution for a universal linux build. The process seems to be easily automatable and there exists a package already, which means there will be less work to adapt it.

[harry963]

I was not aware there were non contributor binaries. I have only used the AUR (must compile) and Homebrew in a virtual machine. I assumed Homebrew is using a third party/contributor binary?

Maybe Eloston should build/provide the binary, since he founded the project, and I think it's safe to say everyone who uses ungoogled-chromium trusts him. Those who do not trust Eloston would probably either not being using ungoogled-chromium or would be inspecting each line of code. If Eloston provided a first party reproducible binary, then I would say it would be trustworthy.

I also like Guix and I think it would be start. I am not too familiar with packing applications for Linux, so I am unsure if distros could package this Guix build into their main repos which I think would help the project grow.

[PF4Public]

If Eloston provided a first party reproducible binary, then I would say it would be trustworthy.

AFAIK it is impossible to compile chromium in a fully reproducible way.

And I'd like to stress it once more, like @wchen342 has already mentioned, there is no such thing as "ungoogled-chromium team", which heavily impacts the notion of "official binaries".

[kramred]

I was not aware there were non contributor binaries. I have only used the AUR (must compile) and Homebrew in a virtual machine. I assumed Homebrew is using a third party/contributor binary?

Homebrew has been using the binaries from my repo for some time now (they are also more up to date than the ones on https://ungoogled-software.github.io/ungoogled-chromium-binaries/ as I mostly forget to submit them and someone else keeps updating the Homebrew cask)

The binaries are built using GitHub Actions, which was a reasonable (and cost effective) compromise that people could trust the binary without having to build it themselves.

I think people using macOS and/or Windows are less aware of the implications of using any binary that is not the result of a reproducible build or anything that could be considered an "open (source) build system". Also the operating systems and many applications are not open source and only available as binaries to the majority.

In general I'd say that binaries built from an accessible open source repo on an "open (source) build system" as e.g. GitHub Actions are as trustworthy as the build system in use; i.e. someone would have to compromise/manipulate the system in a way that the binaries include code not present in the source files. That's also why reproducible builds would be advantageous, as they would allow easier detection of compromised build systems.

I'd suggest to trust/use binaries in this order (decreasing difficulty to compromise the binary):

0. Reproducible builds (if that's ever going to work for chromium)
1. Built from open source repo on a build system that one controls (ideally with physical access, otherwise remotely)
2. Built from open source repo on an "open (source) build system" as e.g. GitHub Actions, OBS, etc.
3. Built on a closed/private build system a. (Supposedly) from open source repo b. From a party that is deemed trustworthy (rather a social aspect)
4. Any binary

[harry963]

Also one question where do the OBS builds come from? From my understanding it is from the openSUSE build service which runs like the GitHub actions, correct?

[networkException]

From my understanding it is from the openSUSE build service which runs like the GitHub actions, correct?

Similar, yes. Generally speaking OBS takes a definition file as configuration, with that compiles a binary from a source repository and hosts the output for download.

AFAIK it is impossible to compile chromium in a fully reproducible way.

The arch package is reproducible when compiled with the same SOURCE_DATE_EPOCH. I'm guessing to some extend this applies to all linux binaries as documented here