Live data from Hacker News

Linuxbrew – A fork of Homebrew for Linux

brew.sh

51–60 of 68 posts

Re: Linuxbrew – A fork of Homebrew for Linux

#51

Earlier quoted context omitted.

if something is stopping your OS from booting, it is part of the OS, and thus must be installed as part of the OS, and not as a user land tool.

Sure, but having a separate package manager (or, at least, a distinct package management "realm") for pure userland things that cannot break the OS install so that you know when you install from it you will not break the install, even with dependencies that may get pulled in, is good for piece of mind. It might be better to have a single package manager which supported bother user and OS packages, and clearly disting…

As I mentioned in a different comment, I don't think there's anything about yum/rpm that precludes doing this. Provided someone took the time to create a repository of relocatable rpm's, you could create a "yumbrew" script that does something like

yum-downloader --deps --destdir=~/.myrpms foo-1.3.3.7; rpm -U --prefix=~/.yumbrew/ --dbpath=~/.yumbrewdb ~/.myrpms/*

or whatever version of that would actually work. This has the added advantage that you don't have to compile the packages (although if you wanted to, you could make the script do that too..)

Re: Linuxbrew – A fork of Homebrew for Linux

#52

Why exactly is this needed? Conflicting with the system's package manager is obviously the most problematic issue with porting homebrew to linux, and I can imagine there's many more caveats that would render such a thing pretty useless.

1) it puts software into /usr/local, in userland, which is safer from both an OS stability and security perspective, since 99% of installable software doesn't deserve to run as root anyway. And then it modifies the PATH so that the OS first looks there, making it supersede any OS-installed packages. 2) it uses git 3) it has a really nice Ruby DSL (probably lost on you) 4) as I've mentioned elsewhere here, I've OFTEN…

Point 1 I keep seeing repeated, but it's entirely false. Installing packages as the user does not increase security in the least. If anything, it weakens the traditional unix security model because now the running user owns the binaries, running processes can modify them.

"run as root" is nothing to do with this. Who installs the package and who runs it are entirely disconnected. If I install a package as root, and run it with my user, it's running as my user, not root.

All it actually illustrates is that the package manager is not trusted. You don't give homebrew root so that it can't damage the OS by accident. The end result is a binaries that are at risk from errant processes, but it seems this is preferable to trusting homebrew.

Re: Linuxbrew – A fork of Homebrew for Linux

#53

This is totally silly. Homebrew isn't a very good package manager. When I used it at a previous job (the only time I've used OS X), it was quite unreliable. It would try to build most things from source (which sometimes failed), but then download pre-built binaries for others. IIRC, installing the MySQL package just downloaded a binary from Oracle, it wasn't even a binary pre-built and verified with Homebrew! I have…

"it wasn't even a binary pre-built and verified with Homebrew" Most (all?) "formulas" include cryptographic hash checks for any downloaded files: https://github.com/Homebrew/homebrew/blob/master/Library/For...

This package recipe actually builds from source, which is great! I swear that at one point the mysql package downloaded a pre-built binary from a third party site. Even with a cryptographic hash, I don't trust it, because it could have been built with a tainted compiler.

This brings me to an issue that I have not only with homebrew, but with most other package managers: reproducibility. Can I have any confidence that the binaries built on your machine and my machine are the same?

Re: Linuxbrew – A fork of Homebrew for Linux

#54

This is totally silly. Homebrew isn't a very good package manager. When I used it at a previous job (the only time I've used OS X), it was quite unreliable. It would try to build most things from source (which sometimes failed), but then download pre-built binaries for others. IIRC, installing the MySQL package just downloaded a binary from Oracle, it wasn't even a binary pre-built and verified with Homebrew! I have…

Here's what Homebrew runs for the MySQL installation. Can you point out the part of this that's giving you security concerns? https://github.com/Homebrew/homebrew/blob/master/Library/For...

The current state of this package looks pretty good! As long as no Homebrew package downloads a pre-built binary from a third-party, I'm content, and I redact that particular criticism.

Re: Linuxbrew – A fork of Homebrew for Linux

#55

Earlier quoted context omitted.

"it wasn't even a binary pre-built and verified with Homebrew" Most (all?) "formulas" include cryptographic hash checks for any downloaded files: https://github.com/Homebrew/homebrew/blob/master/Library/For...

This package recipe actually builds from source, which is great! I swear that at one point the mysql package downloaded a pre-built binary from a third party site. Even with a cryptographic hash, I don't trust it, because it could have been built with a tainted compiler. This brings me to an issue that I have not only with homebrew, but with most other package managers: reproducibility. Can I have any confidence that…

It actually includes methods for both prebuilt binaries ("bottles" in homebrew terminology) and source. It will use a bottle if one exists for your OS version, but you can force installation from source with "--build-from-source".

The problem of bitwise-identical / deterministic builds is difficult when using most legacy tooling, in particular tools that insert timestamps or other non-determinism. Bitcoin and Tor use Gitian https://gitian.org/ and Google just open sourced their tool, Bazel http://bazel.io/

Re: Linuxbrew – A fork of Homebrew for Linux

#56

Homebrew is not only a weak package manager, it is a dangerous package manager. No one makes it clear anywhere in the docs or on the site that it should never be used on a server or world-facing service...and people are using it for that. Because it is installed in userland (its most advertised feature), it runs everything as the same user (probably an admin level user with sudo privileges). This throws away 40 years…

>it is a dangerous package manager

To go along with this theme, I must ask: Does homebrew do any isolation when building from source? Chroots, separate process namespaces, etc.

>All so you can install it without sudo.

This is actually a really great feature. I work on a package manager called Guix, which also allows for unprivileged package management. It's one of my favorite features. You and I could have user accounts on the same machine and use different versions of the same application without conflict.

Of course, I don't know what the security story is for Homebrew, but it doesn't look to be better than average. We take security very seriously with Guix, to the point that we are seeking things like bit-for-bit reproducible builds.

Re: Linuxbrew – A fork of Homebrew for Linux

#57

Earlier quoted context omitted.

There are much better package managers for that. Try Nix or GNU Guix.

Can I get one of these to manage packages installed to /home in Ubuntu?

Do you mean install packages to your user's homedir or to use the package manager on a system where you do not have root access?

Re: Linuxbrew – A fork of Homebrew for Linux

#58
post #52

Earlier quoted context omitted.

1) it puts software into /usr/local, in userland, which is safer from both an OS stability and security perspective, since 99% of installable software doesn't deserve to run as root anyway. And then it modifies the PATH so that the OS first looks there, making it supersede any OS-installed packages. 2) it uses git 3) it has a really nice Ruby DSL (probably lost on you) 4) as I've mentioned elsewhere here, I've OFTEN…

Point 1 I keep seeing repeated, but it's entirely false. Installing packages as the user does not increase security in the least. If anything, it weakens the traditional unix security model because now the running user owns the binaries, running processes can modify them. "run as root" is nothing to do with this. Who installs the package and who runs it are entirely disconnected. If I install a package as root, and r…

>If anything, it weakens the traditional unix security model because now the running user owns the binaries, running processes can modify them.

This is a great issue to point out. This is why package managers like Nix and Guix (and maybe others I do not know about) use an immutable store for package builds. Unprivileged users may still install and use the software in the store, but the Unix security model prevents them or a malicious process running under their user account from corrupting what has been built.

Re: Linuxbrew – A fork of Homebrew for Linux

#59

Why exactly is this needed? Conflicting with the system's package manager is obviously the most problematic issue with porting homebrew to linux, and I can imagine there's many more caveats that would render such a thing pretty useless.

1) it puts software into /usr/local, in userland, which is safer from both an OS stability and security perspective, since 99% of installable software doesn't deserve to run as root anyway. And then it modifies the PATH so that the OS first looks there, making it supersede any OS-installed packages. 2) it uses git 3) it has a really nice Ruby DSL (probably lost on you) 4) as I've mentioned elsewhere here, I've OFTEN…

1) Putting everything in /usr/local is far less secure as that means its world writable (oh, my version of bash just overwrote yours, and I added some extra patches ;) ). If it's just in the user's home directory, it's all running as the same user, which is far FAR less secure, now you don't even need privilege escalation to access everything, it's already owned by the same user. Also good luck running anything on standard ports like that. As far as stability, anything that could realistically affect stability can't be installed or run as an unprivileged user anyways. All that being said, with yaourt and makepkg, you can do the same thing, I'm sure there's ways for other systems. Also userland doesn't mean what you think it means.

2 ) You have yet to show why that's a good thing, but https://aur.archlinux.org/packages/?O=0&K=git so what?

3) makepkg has a really nice Bash DSL (probably lost on you) (and also a load of really nice docs)

4) You have indeed mentioned that everywhere, but don't seem to realize that generally software that can hang your "Linux distros on the next boot by doing a simple "apt-get update"" can't be installed or (directly) run as a non-privileged user. Have fun with your grub install in /home, let me know how that hangs on the next boot. Also I wasn't aware that updating a package list modified anything but the package list, but hey, if you say so.

5) If you Arrogant folks (can't even say mac folks, most are reasonable) had any sense of functionality (software or otherwise) to begin with, your OS wouldn't be primarily relegated to a status symbol, so the fact that you're one of the dozens of people repeating the same "we don't need to learn more than one shiny button" doesn't surprise me in the least, because you guys wouldn't recognize better functionality if it pulled up to you in a bus like this: https://www.youtube.com/watch?v=tmYrWXhFf4c

Sorry, got a little angry there, I dont hate mac folk, just arrogant folk from any camp and I recognize the appeal of and need for good design (which brew is not)

Re: Linuxbrew – A fork of Homebrew for Linux

#60
post #19

Standardizing a package manager across platforms is nice and making homebrew for linux does this without just creating another package manager to support packages.

PackageKit was supposed to do this...

PackageKit doesn't support, and doesn't intend to support, unprivileged package management features, unfortunately.
Post reply on HN