Add signed macOS builds of 120.0.6099.129-1.1_x86-64__1704447342

[claudiodekker]

This PR was automatically triggered by the release of code-signed build 120.0.6099.129-1.1_x86-64__1704447342 of ungoogled-chromium for macOS, which itself is based on this ungoogled-software/ungoogled-chromium-macos build.

[claudiodekker]

Oops - that initial failure was something I'd missed on my part. It's been fixed in the CI, so shouldn't occur on future releases.

Furthermore, as per the changes in the ungoogled-software/ungoogled-chromium-macos release process, each future release should now also create only one PR (with both architectures included) instead of the two that were created this time.

[networkException]

Thanks a lot for putting in the effort to get the build signed. I assume the signature is tied to you (and integrating the workflow into the ungoogled-software repository would be non trivial / a trust issue because of that)?

[Cubik65536]

Thanks a lot for putting in the effort to get the build signed. I assume the signature is tied to you (and integrating the workflow into the ungoogled-software repository would be non trivial / a trust issue because of that)?

As long as the build process is transparent (meaning we can make sure that the source is from our macOS repo and all the build scripts are open), I'm not too concerned about the security of these binaries.

As of the trust issue, it seems that the actual CI script is not a part of the PR and what's being added to these PRs (including #491 of course) are just built binaries, so we can maybe just think these as normal contributor binaries? At the bottomline, anyone downloading binaries from this repo should know that it's not provided by ungoogled-software.

[networkException]

Right, this comes from the perspective of ideally not having contributor binaries at some point

[claudiodekker]

Thanks a lot for putting in the effort to get the build signed. I assume the signature is tied to you (and integrating the workflow into the ungoogled-software repository would be non trivial / a trust issue because of that)?

Yes, that's correct. I'd love to make it part of the official repository given the low maintenance effort / automated nature of it, but due to the fact that Apple Developer ID credentials are being sent "over the wire" for the notarization process, having others have access to those secrets (read: have a method to extract them from the repo) is somewhat problematic to me.

That's why I just went ahead and set it up this way directly / without discussing it first, and why I set it up "transparently" in the way that I did.

---

As of the trust issue, it seems that the actual CI script is not a part of the PR and what's being added to these PRs (including #491 of course) are just built binaries, so we can maybe just think these as normal contributor binaries? At the bottomline, anyone downloading binaries from this repo should know that it's not provided by ungoogled-software.

Yeah, absolutely. Despite the builds being trustworthy due to their transparent and automated nature, I am in a way an "external publisher", so in your shoes that's 100% what I would also do.

[claudiodekker]

Perhaps there is still some complex way to do this in a safe-ish way though. Something like this:

1. The build Action uploads the image, but doesn't release yet
2. The build Action triggers another Github action (in a repository owned by me) and waits/rechecks until it gets a "done" signal
3. The Action in my repository signs the build, uploads the result, and marks it as done
4. The official repo eventually sees the "done" signal, downloads the signed image, and releases it.

But yeah, sounds like a lot of overhead for so little practical benefit to be honest, and it also adds a point of potential failure in the release pipeline, so probably it's fine the way it is?

[networkException]

Yes that sounds pretty involved.

Can it be proven somehow that the signature applies to the same artifact released by our pipeline? If so I'd be happy to link to your repository from the macOS readme even with corresponding instructions. Still we might remove this page in the longer term and probably only link to GitHub release pages

[claudiodekker]

Yes, that is possible by working backwards from a release. For example, let's work backwards from the changes suggested in this PR:

[ungoogled-chromium_120.0.6099.129-1.1_x86-64-macos-signed.dmg]
url = https://github.com/claudiodekker/ungoogled-chromium-macos/releases/download/120.0.6099.129-1.1_x86-64__1704447342/ungoogled-chromium_120.0.6099.129-1.1_x86-64-macos-signed.dmg
md5 = 03623a03f05b63b1dfaea0749718a2ea
sha1 = 24bca52b00d7bea18f71adbd0f43392c3f5df05e
sha256 = 39a6089b9b7d6221d36855d11a96df3de432ae813da2831c0c2f15092b2b2453

Now you could use the link in this PR's description, or look up the repo manually, and you'll be able to find the release that this .dmg URL traces back to, with the same hashes noted in the release notes: https://github.com/claudiodekker/ungoogled-chromium-macos/releases/tag/120.0.6099.129-1.1_x86-64__1704447342

Then, if you look at the Actions run that's mentioned there (https://github.com/claudiodekker/ungoogled-chromium-macos/actions/runs/7585080063/job/20660137409), you'll see the whole process, including where those hashes are calculated, indicating that this is in fact the pipeline that generated those builds:

Having established that this build process did in fact generate that specific release, you can inspect every single step to validate and see what's being done to it, includes the initial download and SHA256 verification from ungoogled-software:

Then from there, if you're still not certain you can trust that SHA256 hash and URL, I've included a direct link in my release notes back to the ungoogled-software release that's being signed, which includes that exact hash. Alternatively you could of course just look it up manually and compare that the SHA256 hash matches that way: https://github.com/ungoogled-software/ungoogled-chromium-macos/releases/tag/120.0.6099.129-1.1_x86-64__1704447342

I've even improved this further in later builds, because this specific run itself still had some issues:

• wget was reporting progress using a progress bar, making output very verbose. This has been reduced.
• This version of the action accepted an URL and a SHA256 hash, making it technically possible for any valid URL and hash combination to generate a release. This was initially done because a "check" workflow (that simply checked if there were releases) triggered this "sign" workflow with the newly-found ungoogled-software release to sign, but I soon discovered that those triggers are also reported as "manual" triggers by Github, which then made verification of the input URL quite important as well.

Now, there are ways I could've fixed this last point, such as by accepting only a SHA256 hash and a tag name, followed by building the full URL in-code, but because the ungoogled-software release pipeline was also changed to support multiple architectures in the same release (ungoogled-software/ungoogled-chromium-macos#142), I had to re-write the action anyway to support this, so I instead decided to combine the check and build actions into one flow, omitting the need to pass around a filename and trigger separate workflows altogether.

With the last release, the one from 2 days ago, this new actions workflow is already used (https://github.com/claudiodekker/ungoogled-chromium-macos/actions/runs/7688586592), and while it's structured differently, it still does the same things: The first step checks for releases, prepares the necessary details to download and sign all architecture builds within that release, and if there is a new release to sign, it then dispatches a matrix of "sign" jobs that each individually validate that build's hash, codesign that build, re-packages it and calculates the new hashes for my release notes.