Ungoogled-chromium: Use GitHub actions to build and publish binaries

[specter78]

Is your feature request related to a problem? Please describe.
Presently, binaries suffer from issues of authenticity.

Describe the solution you'd like
Use GitHub actions to build and publish binaries within the repo itself.

Describe alternatives you've considered
NA

Additional context
NA

[kescherCode]

The build takes a while, so I wonder if GitHub Actions would even be feasible for this.

[specter78]

Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete. This limit does not apply to self-hosted runners.

Workflow run time - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled. This limit also applies to self-hosted runners.

I think this is more than enough. For different OS, different workflow can be used.

[gavinbeatty]

I would just like to say that the questionable provenance of the binaries is the issue preventing me from using ungoogled-chromium as a privacy-oriented browser based on chromium.

[wchen342]

This has been tried in Arch repo and it took 10+ hours with Actions (I wrote the workflow files btw). Currently we are working on sending the build to OBS.

[PF4Public]

questionable provenance of the binaries is the issue preventing me from using ungoogled-chromium

Have you tried building from source yourself?

[gavinbeatty]

@PF4Public Sorry I sounded so demanding. I’m just saying I would like to use a chromium based browser from time to time, but for now, I go without.

I’m not invested enough in the outcome to build for myself, and I believe there are others like me — not quite invested enough to build from source, and not comfortable using the existing binaries.

[PF4Public]

@gavinbeatty I do understand your concerns, but this issue is really a deep one.
First of all, why would someone believe someone's binaries?
Imagine, we overcame the first issue by trusting Eloston building binaries for us. How could he / how could we prove, he did build them? Should github actions sign them with Eloston's GPG-key? Given that github actions are then capable of this, could/would github sign and distribute us some false ungoogled-chromium binaries?
The other issue is that as far as I'm aware, chromium builds are not perfectly reproducible. But if they were, Eloston could build binaries and sign them, the signature would be valid for any other reproducibly built binary (same arch, same gn flags etc etc) for anyone to verify the correspondence between source code and binary.

[braewoods]

For that matter how is this an improvement over OBS? How is GitHub more inherently trustworthy? AFAIK GitHub is even more limited than OBS. How many different environments can you use for building?

[PF4Public]

@braewoods Just a side note. Isn't OBS a paid service? I wonder if I could use it for Gentoo in case it is a free service…

[jstkdng]

obs is free and it also supports gentoo afaik

[braewoods]

@PF4Public What's the value in it? Gentoo is source based. Their users are used to building everything themselves except for the foundation on first install. They don't need or expect us to provide binary packages. I'm not even sure that works with how Gentoo is designed. We should be able to get away with just providing some method of distributing updated build scripts.

[specter78]

@wchen342 Please share your workflow file. Since a single job has a limit of 6 hours, I wonder how you did it for 10+ hours.

[wchen342]

@specter78 You can find it here. The workflow is not working correctly for the current Arch repo because PKGBUILD file changed since and I haven't adapted to the new one, but you can see the idea. It is pretty simple: you pack everything in the middle and open a new task, re-download the files and continue.

[jstkdng]

Each job is run with 7gb of ram and a dual core cpu. Maybe we could use distcc to make multiple workers to communicate with each other, effectively making a compile farm.

[wchen342]

I doubt you can get them communicating with each other considering they are running in VMs maybe on different clusters which may have different subnets.

[jstkdng]

then we should try to connect each other with a vpn, we could then easily ping them with a 10.200.200.x subnet. Dunno if that is possible.

[wchen342]

That sounds very hard since it needs to have a top-down structure with a center "controlling" server with a bunch of clients, and you need to make sure they are all up at the same time..

[jstkdng]

that may be hard, but not impossible. Will try to do a proof of concept, then we can build on it. We would still need to use docker on each worker. Good to know arch supports distcc oob.

[jstkdng]

well, have been doing some testing and managed to connect to a php server running from inside a github worker.
Saddly, like @wchen342 said, a vpn server is required for this. I wanted to somehow configure a github worker as a vpn server but I can't since all ports are closed to WAN from the aws/azure part.
Will try to configure something on the archlinux repo and see how it all goes.

[specter78]

@PF4Public @braewoods I totally understand your concerns about trusting github with binaries. But I think, providing github action code which can be run by end user is still better. This allows them to build themselves, instead of relying on a third-party binary.

The user can also run the workflow code on his own system, thus bypassing github altogether.

This _might_ also remove the need to maintain separate repositories for build instructions for different platforms.

[PF4Public]

providing github action code which can be run by end user is still better. This allows them to build themselves

May I ask you to clarify the quoted text? I am aware of none github actions, that could be run by a end-user.

[specter78]

May I ask you to clarify the quoted text? I am aware of none github actions, that could be run by a end-user.

If a repo has actions and it is forked, these actions can run in the forked repo, after being allowed explicitly (GitHub restriction) by the user who forked it. But this requires that the actions are placed in .workflow directory, so they'll also run in the parent repo, unless disabled.

Another option is to place workflow code in separate directory, and have end user shift it to .workflow directory to run it.

[PF4Public]

these actions can run in the forked repo

Thanks, this explains it.

[anshul78]

I am trying this for macOS, but facing issues. Any advice?

ungoogled-software/ungoogled-chromium-macos#49

This is the workflow file.

[PF4Public]

I am trying this for macOS, but facing issues.

And your issues are…?

[anshul78]

And your issues are…?

Out of random, even before 6 hour mark, I'm getting following error.

[32270/40100] CXX obj/content/renderer/renderer/pepper_video_decoder_host.o
##[error]The operation was canceled.

[wchen342]

There should be another error coming with The operation was canceled. and that will be the cause. Check the overview page of the particular workflow run.

[Eloston]

@specter78

If a repo has actions and it is forked, these actions can run in the forked repo, after being allowed explicitly (GitHub restriction) by the user who forked it. But this requires that the actions are placed in .workflow directory, so they'll also run in the parent repo, unless disabled.

I'm failing to understand the value of this. Why is Actions in Person A's repo more trustworthy than Actions run under Person B's repo, from Person A's perspective?

[specter78]

@Eloston you do not provide binaries but provide the code (instructions) to generate binaries.

Github action would be an alternative for users who do not want to build on their own system.

If you’re taking about trustworthiness, then a person still trusts your build instructions. GitHub action is the same build instructions, translated to run on GitHub itself.

Running on own account may provide an additional sense of safety that the uploaded binaries has run on exact same code and not been modified.

[Eloston]

@specter78 I'm failing to see how that addresses my question. If we use Actions on all platform repos in ungoogled-software to build binaries, how is this less trustworthy than running Actions on your own fork, from your perspective?

[specter78]

how is this less trustworthy than running Actions on your own fork, from your perspective?

It’s not.

My comment was in response to some earlier comments regarding trusting github with building the binary, so my suggestion was those who want to can use actions to do so, others can build on their own system.

Ungoogled chromium would provide build instructions for both. It (may or) may not run actions itself but provide workflow files, which can then be run in forked repo.

[Eloston]

Okay, so we agree that Actions on any repo is equally trustworthy.

Ungoogled chromium would provide build instructions for both. It (may or) may not run actions itself but provide workflow files, which can then be run in forked repo.

If we can provide workflow files to build binaries on GitHub Actions, we might as well run them on our platform repos. There's no benefit to running them in a forked repo, because the resulting binaries would be equally trustworthy.

Also, this issue is platform-specific. If there is a specific platform that you wish to use Actions to build, please create an issue for it.