Hacker News Reader

Comment by devkit1 | Hacker News Reader

If I understand the issue correctly, it appears that this change primarily impacts casks on macOS. In fact it looks like it may only impact casks. Casks are used to install binary packaged software, often in the form of a dmg or pkg file on macOS. Most people I know are not installing too many casks, and most of the ones I've seen install signed binaries anyway. The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too, but I fully expect to learn very quickly if there are a bunch of taps in use by people that distribute unsigned binary installers of software for macOS. :-)

View on HN

> Most people I know are not installing too many casks

Casks are the only things Homebrew does that some other package manager available on macOS doesn't reliably do better. Nix, Pkgsrc, MacPorts, and (and now Spack) all have better fundamental designs; sane, multi-user-friendly permissions; and enough isolation from the base system that they break neither each other nor manually-installed software.

I use Homebrew exclusively tucked away in isolated prefixes, only to install casks, and without ever putting any binaries it installs along the way on my PATH. I don't remember which programs it is, exactly, but I do use a few that are unsigned.

It also doesn't seem to me that the signing process is as vital in determining actual risk as the curation and moderation processes involved in maintaining "third-party" software distributions like Homebrew or Debian or whatever.

`--no-quarantine` in particular is one of the conveniences that makes Homebrew casks useful. If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.

> Most people I know are not installing too many casks

I did a wipe and install of Tahoe like 2–3 weeks ago and used a Brewfile [1] I've had for years to install ~30 casks via Homebrew, including from the App Store, not to mention 50-60 formulas.

As of today, I have 44 casks.

[1]: https://docs.brew.sh/Brew-Bundle-and-Brewfile

I do something similar. I bootstrap all my new installs with brew cask https://github.com/fastily/autobots/tree/master/macOS/setup

I bootstrap it using Brewfile (plaintext file read by Homebrew), which supports Casks too.

Same here.

Probably easy enough to write a script that will iterate that list and run the proper xattr command to remove each from quarantine.

I haven't used Homebrew in a long time, but if I ever did it would be in the way that you describe (so far I've always found reasonable alternatives for the software I want). What I'm wondering is if this is entirely to support unsigned casks, why does Homebrew not simply resign the software itself at install time with an adhoc signature as though it had just built it?

Yeah, my nix-darwin config is pretty nice and perfectly hermetic and reproducible, save for a now-growing list of casks in my brew.nix that looks like this:

> 1password # breaks in nix, must go in /Applications folder

> softwareB # not available in nixpkgs

> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that

> softwareD # ostensibly available in nixpkgs, but the package is completely broken (more general case of 1password)

Why not wrap the binaries yourself in flake.nix you say? Well, sure, would love to, if it wasn't such a pain in the ass to do so for each one and keep them up to date.

> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile

What actually happened is that non free software may not be legal to distribute from nixpkgs caches, so you're on your own with building those. That's not really a purist approach.

Only because the purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule. Why doesn’t the same limitation exist for homebrew, for instance? It isn’t some idiosyncracy of the way they are building things, it was a conscious and deliberate policy decision.

And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel

> purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule

No. Both lib.licenses.unfree and lib.licenses.unfreeRedistributable are accepted into Nixpkgs, but the former marker indicates that the developer has declared it illegal to distribute builds so the official binary cache (sorry, “substituter”) does not.

What Homebrew likely does is fetch the upstream binaries from the upstream download server. Nixpkgs does have a policy against that when buildable source code is available, but that’s mostly because the way Nix achieves isolation (both from the host system and between packages) is by placing almost all shared libraries and data files in hash-decorated places that are emphatically different from what an upstream binary expects. On Linux, it’s possible, if very distasteful, to cram that peg into this hole using mount namespaces and bind mounts (see buildFHSEnv et al.); not sure about Darwin, but the general response to asking Nixpkgs maintainers to keep this sort of fragile mess working is, indeed, pretty much exactly “ain’t nobody got time for that”.

Why can't you distribute it from the developer's website?

You can. For example: https://github.com/NixOS/nixpkgs/blob/fde16189feaa6eaa81bcf9...

If something gets built it likely means the sources available in some way, just not opensource. There may be many reasons they're preferred over a binary.

> nixpkgs maintainers are hardline purists

On the contrary, Nixpkgs is generally made by the most pragmatic people and takes a flexible approach to a lot of issues. For instance, very few package managers have packages for proprietary software like 1Password in their official repositories. Nixpkgs also doesn't insist on building everything from source when it's hard to do so. As a result, Nixpkgs contains many packages for NPM or Maven projects. Other package managers insist on packaging all its dependencies from source, which is why they're struggling to package software written in modern programming languages.

As for 1Password, it works fine on NixOS. When installing proprietary GUI apps like 1Password on macOS, I just use Casks. I suspect many people do the same, which might lead to the 1Password package not working as well on macOS because fewer people bother with it.

The Nixpkgs community is internally diverse, but broadly values both "purity" and pragmatism. You can see debates and compromises play out in PRs all the time, or read traces of such careful weighing in the source code of Nixpkgs itself.

For the record, the Nix community's largest public cache doesn't cache binaries of proprietary software because doing so would be illegal— the public doesn't generally have the rights to redistribute proprietary software.

The phenomenon of having to compile free software from source via Nix typically happens when free software depends on proprietary software (which is common on macOS). Maybe this could be ameliorated on a technical level, but I think it's mostly historical accident and ease of implementation that got us to the current situation, where the whole dependency tree has to have a free license for something to make it into the binary cache.

The 1Password cask will almost certainly continue to work. 1Password distributes a signed installer.

Yes the cask is fine. The problem with 1pass installed via nix is that it doesn’t put it in applications folder because that defeats the hermeticity of the solution. However the 1Password devs designed the binary on Mac to only boot out of applications folder, presumably for security reasons. Most other apps you can get around this by setting up trampoline links to the nix store versions, but if the app straight up refuses to boot anywhere else besides applications folder, you can’t use the typical nix installation path

IIRC there are some macOS APIs that you can only access if your app runs out of /Applications. There are some features of an app called "Secretive" (an SSH agent that stores keys in the Secure Enclave) that only work if you have the app installed under /Applications (whereas I'd normally install it under ~/Applications).

1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.

Yep. It goes back to “some things nix does are straight up exclusive to the way macOS needs things to be”, as long as that dichotomy exists nix-Darwin will always have hacky idiosyncrasies like this. It’s not an easily solved problem, and it’s not necessarily Nix’s or Apple’s problem to fix. It’s just two antithetical design philosophies. I would love to see Apple support that kind of sandboxing Nix offers here for these apps though

Brew-Nix might be able to cover some of those gaps, but probably not all of them. But almost certainly SoftwareC, at least!

https://github.com/BatteredBunny/brew-nix

What he is doing in there is kinda cool but the trampoline app solution is quite similar and unfortunately does not fix this problem. Fundamentally the problem is that when you install stuff with nix it gets a folder that is unique to that nix generation. That is by design nix, because you want to be able to go back and forth between generations etc. Apple does not think of things the same way. Applications is a single folder that you can’t subdivide with iterations and it’s “speshul”. These core philosophies are antithetical to each other. This is fine for Most applications who don’t need to be in Applications. You let Nix install into its own little /nix/ generation folder and then create a “trampoline” in applications which is basically like a symlink. Then your app shows up in spotlight etc. where this falls apart is applications like 1Password that MUST boot from the speshul Applications folder

However, you are right, it definitely makes some other pieces of this cleaner. In particular, if you just use homebrew directly with nix, you aren't deterministic or reproducible. You have an impure setup because if you remove a cask from the list, it doesn't actually delete it from homebrew, and you can't go back and forth with generations because homebrew is stuffing things in /applications. The project you linked forces brew stuff to behave like Nix applications and go in /nix instead, which allows it to be able to walk between generations. So it solves most of the issues with brew and nix but not all of them.

> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that

Which package is that? Is it proprietary but source available? Any free software which is built from source is built by hydra and available from the binary cache to downstream users.

Terraform is a notable example yeah. Takes like 7 minutes to compile it when you would get it in seconds by pulling the binary

When Hashicorp did their rug pull, I just switched my team to OpenTofu as soon as it had a stable release. No regrets; it's been great. (I did evaluate both projects at that time, of course. But it ended up being a clear decision.)

> If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.

Really? That's a whole lot of UI actions/clicks (and a variable number per .app) versus ... I think two always-the-same UI actions at most. Not like, a huge hassle either way, but I have trouble seeing how Homebrew's not still the winner here even without quarantine bypassing.

Spack is a really unfortunate name for a project given that it's a slur derived from 'spastic' in the UK.

Can you just "pronounce" it (even in your head) S-pack, as in "source package"?

> The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too

FWIW I don't think brew has been compiling on installation even open source things by default for a while now[1]:

> Homebrew provides pre-built binary packages for many formulae. These are referred to as bottles and are available at https://github.com/Homebrew/homebrew-core/packages.

The link shows close to 300 pages of precompiled packages available, and that section ends with the sentence "We aim to bottle everything".

I don't think this necessarily changes anything you've stated with regards to the flag being removed as described in the Github issue linked by OP, but I think it's still worth noting because this is markedly different than how homebrew distributed things in the past, so others might not be aware of this change either.

[1]: I assume the heading title for this docs section predates this change, but the docs section I'm referencing is https://docs.brew.sh/FAQ#why-do-you-compile-everything

> FWIW I don't think brew has been compiling on installation even open source things by default for a while now

For built in formulas, no. For custom ones very much more so. I know I have a bunch I’ll never have bottles for and would thus always be compiled if used.

That's fair, but I was specifically responding to the part of OP's comment that said that compiling and installing comments was what they expected "most people" used homebrew for. I would expect the vast majority of homebrew users to be installing the built-in formulas for pretty much everything.

I do recognize that there's a bit of ambiguity around when the "compiling" happens, since even the binaries being distributed are still being compiled from homebrew's formulas. The main point I was trying to make was that there was a transition from the "compile everything on the user's local machine when installing" model that homebrew started with to "use the pre-built binaries that homebrew has compiled in advance for installing when possible if the user hasn't specifically expressed they want to compile it themselves". To be clear, I think this is a good thing, and it's a pretty huge quality of life improvement, but I've noticed a few times over the years that this change seems to have not been as widely noticed as I'd expect given how visible it seemed to me even as someone who only uses MacOS on my work machines and not my personal ones. I still sometimes get frustrated with homebrew feeling a bit slow compared to my preferred Linux package manager, but overall it's become far faster and less error-prone over the past decade, and I think it's worth calling out efforts they've taken (like pre-compiling and distributing binaries) that have made a noticeable impact.

In some ways, I think I think understanding the previous efforts they've taken might even help explain why they've chosen not to put in the effort to work around the quarantine issues (e.g. by using local signing like some other comments on this story have mentioned); they're a volunteer project that, unlike most standard package manages for Linux distros, are not in a position where they can easily influence the development of the OS features that might be useful for them. It makes sense to me that the most valuable use of their efforts would be on things that aren't swimming against the current of where MacOS is going. Getting to the point where they could have seamless binary installations at all can't have been an easy task, and the infrastructure needed for it takes additional effort beyond the local compilation model (which still exists). If cutting down on the scope in one dimension makes it easier for them to continue providing the overall feature set they have, this seems like a worthwhile tradeoff to me.

Also if you have an older version of macOS. It will try to take the compiled route for packages but also prints a stern warning that your setup is unsupported.

You can tell this in how fast things "pour". There's no way things are compiling from source that fast.

Sigh, I'm so over homebrew's hipster rubyist brewery analogy

Homebrew Project Leader here.

Yes, this only affects casks, not formulae, whether formulae are built from source or use Homebrew's bottles (binary packages) or bottles from taps.

As an open-source developer, is there a way to have my apps pass Gatekeeper without paying the $100/year Apple ransom and notarizing them? I think it’s the crux of the problem.

As I’m writing these lines, Homebrew has 7656 casks in the official cask tap[1]. I’m not sure exactly how many of those are unsigned but if we assume 4000 then signing them all would be an additional $400,000/year extorted by Apple from the open-source community.

Defining HOMEBREW_CASK_OPTS=--no-quarantine in my shell configuration was a good way to avoid this issue without having to manually run dozens of xattr -d every time I run brew upgrade.

Now my only option left is to pull the trigger and make my system globally less secure: sudo spctl --master-disable

Unfortunately, disabling Gatekeeper doesn’t just allow unsigned apps to run: it also completely disable all verifications for signed apps: notarization checks, revocation checks, trust evaluation checks.

[1] curl https://formulae.brew.sh/api/cask.json | jq 'length'

You can make your own tap (which is just a GitHub repo) and manually clear the quarantine flag in a postflight step. E.g., see https://github.com/alacritty/alacritty/issues/8749

Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.

I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…

I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.

Two popular apps mentioned in the earlier discussion in Homebrew repo are Librewolf and Freetube.

https://github.com/orgs/Homebrew/discussions/6334

I actually tried to install Librewolf today and it wouldn’t go because of gatekeeper. Ended up on Waterfox instead.

Would’ve preferred Librewolf because that’s what I run on my other desktop running Linux but what can you do…

You can still use Librewolf, if you manually remove the quarantine attribute after every update and reboot. It’s very annoying, but at least it’s possible for now

xattr -dr com.apple.quarantine /Applications/LibreWolf.app

Oh wow, thanks for that, makes things even easier than “Find app and ctrl click”.

...or automatically remove the quarantine attribute: https://news.ycombinator.com/item?id=45913209

Not exactly, I have automated stuff which uses python and does rar and unrar and it's installed through brew, it is not a cask, but every time I do brew update, my code will fail to run because it was updated.

This is like buying a machine and not having the ability to do whatever you want with it.

Oh who are we kidding, that's what is happening anyways.

This is a silly distinction. You can always include pre-built object files in your "source code" formula, then the build step is just linking it into an executable locally. That would bypass the quarantine attribute and effectively retain the ability to distribute pre-built binaries without gatekeeper getting involved.

Seems like only a matter of time before someone at Apple realizes this and takes the necessary measures to protect you from yourself.

The linking step isn't even required. You can download any existing binary and codesign it yourself with your local developer certificate. You can even overwrite the existing signature.

I assume brew could even automate this, but are choosing not to for whatever reason.

If Homebrew auto-signed third-party code, that puts them on the line for the security of that code. The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine. The trust comes from the formal relationship between Apple and the software developer, which includes a traceable financial transaction. If signed software proves to be malicious, attribution is trivial.

If the homebrew team signed everything, they would immediately become a target for bad actors. The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.

Yeah, makes sense Homebrew doesn't sign everything with their own certs. I was suggesting that Homebrew could run codesign locally with the user's local certificate as part of the install process.

> The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.

Every software distributor has this problem, code-signed or not. This is either already happening to Homebrew (and not using code signing) or there's some other reason that it isn't happening.

> The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine.

Tim Cook is laughing all the way to the bank on that one

casks are mostly for GUI or other apps that need special installation like setting up background services. I've seen it used for IT laptop provisioning to automate the installation of things like Chrome, Slack, Visual Studio, from the command line.

Casks save so much time compared to the normal way of installing Mac apps regardless of any background services.

I have a good number of casks. I think, anyway, since I use homebrew to install a bunch of proprietary software.

> Most people I know are not installing too many casks, and most of the ones I've seen install signed binaries anyway.

I install any GUI program I can via Homebrew, there’s at least 30 casks installed currently. Don’t know how many were signed though.

Typical hn comment where major feature of a software is broken because of “reasons”. But it is fine because “I and most people don't use it”.

Hey if you are not using casks you are missing out. It's by far best way to install gui apps on a mac.

Once this doesn't work its serious problem for brew because there are package managers like nix that are arguably better for developers. Something like this could start slow death of brew just like macports did before.

Reply on news.ycombinator.com