[2cb]

What is your specific beef with Homebrew? You insult it but don't provide any reason it's so much more inferior compared to apt.

There are some ways Homebrew is actually more secure than apt. For example in order to do anything with apt you must give it superuser rights. The same is not true of Homebrew, which installs binaries in userspace and explicitly tells you to never use sudo.

A Homebrew installer is a simple Ruby script you can easily audit for yourself.

The packages are SHA256 signed to ensure code integrity.

You can point it at a specific repo you trust and tell it to get a package from there.

All downloads are done through a TLS connection, which is not the case for apt.

And of course the whole thing is open source.

I fail to see where the hate is coming from.

> Notarizing is not strict by any definition of the term, unless you consider "scans your software for malicious content, checks for code-signing issues" to be strict?

I mean, having to register as a developer, get a certificate to sign your apps, and still have to send off your software to Apple each time you update it before you can distribute it on your own website is pretty "strict" compared to every other OS.

It doesn't seem to do much to prevent malware in the wild either.

[easton]

Last I checked homebrew doesn't ask for root every time because it changes the permissions on /opt/homebrew (or /usr/local/bin if you are on Intel) to allow you to install software as non-root. This is still extremely insecure, as you can now install/remove/upgrade software on the system without root's permission, which is annoying if more than one user uses the device. Not to mention other applications that you run can now also write to these directories and blow stuff up without your permission, whereas if the permissions were set as default you'd get a password prompt at least.

I still use brew (because it has more apps than macports), but why in the world they made this decision rather than using, say ~/Applications (the macOS recommended practice for software that only one user needs) or ~/homebrew is beyond me (granted, apt doesn't do this either, but I'm 99% sure that you can do it with yum and it is how scoop works on windows).

[soraminazuki]

> This is still extremely insecure, as you can now install/remove/upgrade software on the system without root's permission, which is annoying if more than one user uses the device.

Can you name a single attack that requiring root for Homebrew can protect against?

> but why in the world they made this decision rather than using, say ~/Applications (the macOS recommended practice for software that only one user needs) or ~/homebrew is beyond me

Because it's not possible to distribute binary packages without using a predetermined prefix path. You can easily find devs bullied into explaining the same thing if you look into forums or issue trackers of any binary system package manager.

> granted, apt doesn't do this either, but I'm 99% sure that you can do it with yum

No you can't. Yum, like any other binary package manager, doesn't let users choose their own installation path. There are exceptions though, and RPM packages can be marked as relocatable by the packagers, but that's a rare case.

> and it is how scoop works on windows

Windows is an outlier here, because Windows programs are mostly relocatable by necessity. Scoop packages can't rely on shared paths unlike Unix packages. This is why you end up with so many copies of bash.exe on Windows.

[yjftsjthsd-h]

I don't have a stake in this fight, but some of those don't really seem like advantages over apt -

> The packages are SHA256 signed to ensure code integrity.

And apt uses GPG signatures.

> You can point it at a specific repo you trust and tell it to get a package from there.

Exactly like apt?

> All downloads are done through a TLS connection, which is not the case for apt.

Since apt enforces GPG signatures by default, this could be a privacy issue but shouldn't be a security issue.

Unless you meant only for the sudo/non-sudo to be your point on being better than apt and the rest was just defending homebrew?

[forgotmypw17]

Adding TLS into the picture introduces many extra failure modes. Examples: clock out of sync, wrong version of SSL, certificate signing problem. All of these things would cause your install to become non-upgradeable by a non-expert.

[stephenr]

Homebrew is not a sentient being, so I don't think it's really possible to insult it.

Installing global software without superuser rights is a security failure, not a feature. You can argue about this, but you're wrong. Decades of good Unix security says Homebrew is doing it wrong.

Also your understanding of this problem is wrong: Homebrew does not install tools in "user space". I know the default path used to be "/usr/local" but that is not "user space". It's still global to the machine.

Apt is perfectly capable of downloading packages from a HTTPS server, or any of the other protocols supported by apt transports - because its actually a problem that had some thought put into it, rather than just "hey lets clone this git repo that keeps growing over time to everyones machine".

My real issue with Homebrew is about how half-assed the approach is, and how the core developers essentially react like children when questioned/challenged about their solutions.

Initially Homebrew was source only: there was no binary distribution, everything was build locally, all the time. Because security is just a pesky annoyance, it does this all as the user - rather than the more sensible approach of building as a regular user, and then installing as root. But like I say, pesky security.

Several years ago Homebrew added the concept of binary distribution. The problem is, they either drank a bottle of tequila each before implementing it, or they have literally never use another package manager before.

Without binary distribution in the picture, the logic for handling dependencies mostly worked OK. If you had a Homebrew package that depends on what Apt would call a "virtual package" - i.e. something that is provided by multiple other packages, and you build from source, it will check if one of those dependencies is installed, and if not, build and install one - probably just the first one, I'd imagine.

When Homebrew added the ability to install prebuilt binary packages.... they never changed the dependency management (or if they did, they didn't change it to support the virtual package pattern, which is not exactly rare in real package management systems).

So if you have package A, which depends on Foo, and Foo is provided by both B and C, when you do a source install, it'll check if anything providing Foo is installed already. No? Ok, build and install something that provides Foo, so we'll use B. Now carry on and build and install A with a dependency on B.

In the same scenario, but you want to do a binary install... Homebrew has already done all that "Ok, what provides Foo.. Ok, build and install B, now proceed and build A with a dependency on B"... So you do a binary install of A, having previously installed C, and all of a sudden, it'll tell you it has to uninstall C. Because the binary package doesn't have a dependency on Foo. It has a dependency on B.

The suggested solution is to install from source... Well was.. I don't know what they say now, because I know when a tool is not worth wasting my time on, and I promptly stopped using Brew when this came up.

This is what the Homebrew website says, right now, about building from source:

> Building from source takes a long time, is prone to fail, and is not supported.

The dependency scenario gets even more fucked, if you want or need to provide a dependency from a different repository (called a tap, because apparently nobody told these people that alcoholism is a thing, and over-worked analogies make you sound like an idiot)... You can't. You just, can't. There is deliberately no way to satisfy dependencies from third party repositories, overriding the "core" repo.

The project decided at some point that they need to know who installs what, and when, and what colour underwear they had on at the time..

For reference, Debian does also have a 'package tracking' concept too, the `popularity-contest` package. What Debian does, is ask the user if they'd like to provide package statistics, and then goes to quite long lengths to give the user multiple options to ensure that the data sent is anonymous, and stores that data on project-controlled server(s)....

What did Homebrew do? Oh. Right. They send data to Google Analytics, and it's opt-in by default.

Homebrew is a tire fire inside a dumpster fire, and any time the fire department turns up and says "hey it doesn't have to be this way" the project says "no no, we like it this way".

> I mean, having to register as a developer, get a certificate to sign your apps, and still have to send off your software to Apple each time you update it before you can distribute it on your own website is pretty "strict" compared to every other OS.

It's suddenly very clear to me why you think Homebrew is high quality software if you think signing your apps is some onerous task.

> It doesn't seem to do much to prevent malware in the wild either.

Can you point to some evidence of specifically malicious software that has passed the Notarisation process?