Ungoogled-chromium: Sign macOS app bundle

[lukf]

Signing macOS releases with an Apple Developer ID would provide a significant security win; releases could be installed without fear of tampering and both macOS's own security systems as well as apps like Little Snitch could provide better sandboxing.

It would be preferable for Eloston to use their own signing identity, but if they can't afford Apple developer membership, I would be willing to provide mine.

[Eloston]

I don't personally provide support for macOS binaries. This will need to be coordinated with those who build binaries. But right now, there is no person designated for that.

[Moscarda]

Sure, code-signing with an Apple Developer ID would be preferable, but one can compile on/for macOS with other certificates. Personally I find the official Apple developer program to be a scam, targeted toward those who want to see their apps in the official App Store, which is the antithesis of open-source. Perhaps @Eloston could provide another kind of certificate that isn't strictly for Darwin builds but compatible? @lukf, I would ask that your code-signature be permitted in a merge, but could that prove problematic in the future should your membership lapse? I am new to Git, and
hazy on the workings and repercussions of forks/branches merging again downstream.

[Eloston]

If using the signing system integrated with applications is too difficult, then we could just fallback to signing the dmg with gpg and uploading the signature file.

[lukf]

For better or worse, Apple Developer ID signing is the only established way macOS and other apps can assure integrity of Chromium. Without it, 1Password, Little Snitch, XFENCE, and Apple's firewall all have to fall back to their unsafe mode, thus opening up the device to exploitation of Chromium's privileges by malware.

In any case, I've since switched to Brave, which is a better fit for my needs and probably most average people. In my opinion, the Eloston fork could just as well use some other means of integrity check, since the process of installing and updating the app and its extensions makes it a bad choice for everyone but the most savvy person. Thus, I've come to see that you probably do have a different threat model and usability requirement than I do.

[Eloston]

the process of installing and updating the app and its extensions makes it a bad choice for everyone but the most savvy person. Thus, I've come to see that you probably do have a different threat model and usability requirement than I do.

I originally created this project for the more savvy person, but it has since gained traction by those who aren't as much. Unfortunately, this project doesn't have the manpower like other browsers to keep up (it's pretty much a one-man show), so it's hard for me to determine if this project will ever grow much larger. The set of people who are capable and willing to work on a project like this seems to be quite small.

EDIT: So far the majority of contributions have been binaries. The few others that have worked on the code have came and went.

[Moscarda]

In my opinion, the Eloston fork could just as well use some other means of integrity check, since the process of installing and updating the app and its extensions makes it a bad choice for everyone but the most savvy person. Thus, I've come to see that you probably do have a different threat model and usability requirement than I do.

Thanks for the input. You are probably speaking to the developer but I mostly agree. Looking forward, I'd hope our collective 'threat models' for anonymity and privacy concerns as both developers and consumers of data and technology should strive to be both strict and standardised. The usability of current browser offerings is, to a large degree, determined by extensibility. So for now I find myself switching between the TOR browser bundle for some applications and chromium builds for ease-of-use, but as someone who probably isn't 'the most savvy' the latter choice is a least-worst option scenario.

[Moscarda]

The Iridium browser you list in the readme and credits, offers a few suggestions here. The GitHub page for the macOS package includes build instructions with multiple options for code-signing identities. I'm fairly sure they would work in Ungoogled with a little savvy scripting edits.

[magicgoose]

This is not a big deal if it is installed via brew cask install caskroom/cask/eloston-chromium because it can check hashes and signatures automatically, and it doesn't have to be Apple-issued (and b.t.w. the Apple way of signing is a flaky business because AFAIK it still allows signing only a subset of files inside an .app and thus it's possible to replace unsigned parts; but with normal signing methods, the entire archive is signed)
Perhaps it'd be more gain to just make sure (if not already so) that the formula in homebrew-cask is up-to-date at all times.

[Eloston]

@magicgoose Signing the .dmg can be used to verify the authenticity of the .dmg on GitHub (or at least that the signer has seen that particular .dmg). The cask just pulls from the binary uploaded to GitHub without doing any authenticity check (since there's no way to do it right now).

[magicgoose]

The cask just pulls from the binary uploaded to GitHub without doing any authenticity check (since there's no way to do it right now).

It depends on the formula. Right now it checks sha256 sum that means the formula maintainer has seen that file and it didn't change from there.
There's a possibility to add a GPG key and then it will also check if it's signed with that key.

[Eloston]

@magicgoose

It depends on the formula. Right now it checks sha256 sum that means the formula maintainer has seen that file and it didn't change from there.

I should've been more verbose. Right now, it does an integrity check but not an authenticity check. The threat model I'm going off of assumes the GitHub account can be compromised.

[irlcatgirl]

My opinion here is that if your system is already compromised a signature check isn't going to do much to protect you.

[magicgoose]

@nsuchy but which systems are not compromised? If we count Intel's ME and AMD's PSP as backdoors (which they very likely are), then a lot of systems (used by us, mere mortals), are compromised.
But security is not "black&white", there is such a concept as "Defense in Depth". And even if the system is compromised to some extent (for example, somebody like CIA having full control), it doesn't always mean that one must give up and not protect it from other possible attackers.

[Eloston]

Let's not get off-topic here. This is about signing to verify authenticity of the original binary; the security of the client's machine is independent.

[carlorosati]

Can you use ad-hoc signing?

[irlcatgirl]

Currently we're building our own binaries. After building, sign with your own Apple ID, problem solved :)

[carlorosati]

If the problem is solved, why is this issue still open?

[Eloston]

Right now, we have no way to ensure binaries on GitHub have not been modified from the builder's original binary. Signing allows us to ensure that the uploaded binaries are what the builder originally created.

(This goes for all binaries on ungoogled-chromium actually, not just macOS app bundles.)