Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew 4.0.0

brew.sh

Post reply on HN
Print view View original

81–90 of 403 posts

Re: Homebrew 4.0.0

#81

Post by ianai »

anshargal wrote: post #50

While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data. I think this will also hurt the Mac platform. I wish Apple would invest some effort into building an App Store for cli programs. While it may be complicated for the community(require signing,…

Or just hire a few FTEs to properly support and maintain the CLI. Pull in new FreeBSD base at releases if they really want to axe their overhead. It's always just read as absolutely lazy how slowly the CLI progresses. Hire a few more and they could absolutely offer a package repo. This company dwarfs Red Hat prior acquisition.

A company like Apple could kick whatever money to an OSS project and write it off as charity for taxes, I think for that matter.

Re: Homebrew 4.0.0

#82

Post by Squarex »

tasuki wrote: post #77
lrvick wrote: post #44

Reminder that nothing in Homebrew has any signing or attempt at supply chain integrity. Now that they are moving away from clients using git, so even git commit signing is off the table now. When you install brew you are giving hundreds of people (or anyone who has access to their Github accounts) full remote code execution on your machine. Never ever use brew on a machine you use to access production.

I've been using Linux for the past 18 years or so, but damn do the M1 macs look interesting. How does one manage packages on a mac?

you could use nix

Re: Homebrew 4.0.0

#83

Post by cassianoleal »

ianai wrote: post #75
pimterry wrote: post #13

Earlier quoted context omitted.

As in the post: they're intending to drop the GA part entirely within 90 days, and it sounds like the new metrics are entirely anonymous, and so not covered by GDPR etc. IANAL but as far as I can tell that should avoid all legal concerns once GA is gone.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

Assuming their claims of anonymity are true, they won't be tracking users at all.

I imagine they can get much richer metrics through this as opposed to only tracking downloads on the server side.

I'm not saying I like it. In fact, I plan to keep it disabled. I'm just saying it's a bit naïve to think client-side analytics are the same as server-side download tracking.

Re: Homebrew 4.0.0

#84

Post by wg0 »

Thank you. I tend to rely for even open source GUI apps because the experience of installing/removing packages have been smooth (at least for me) so even on Ubuntu, I find myself using brew instead of apt/snap for personal use.

Side question - what can we do about improving security? Of the possibility that packages are not poisoned? Some sort of central CA/GPG or similar requiring to sign the packages or there would always be some holes and it is a hard problem to solve?

Re: Homebrew 4.0.0

#85

Post by callahad »

throw0101c wrote: post #23

On macOS, has anyone moved from/to MacPorts to/from Homebrew? Why did you move? What are the pros and cons of each system?

Moved from Homebrew and Nix to MacPorts for a while around the M1 transition. Came away quite liking MacPorts; it was simple, and it worked.

Moved back to Nix when it was ready for Apple Silicon, mainly for better isolation / reproducability, ephemeral environments, and parity with my other systems. But if I need something that's not in nixpkgs, I'll look at MacPorts first.

Re: Homebrew 4.0.0

#86

Post by brookst »

ianai wrote: post #75
pimterry wrote: post #13

Earlier quoted context omitted.

As in the post: they're intending to drop the GA part entirely within 90 days, and it sounds like the new metrics are entirely anonymous, and so not covered by GDPR etc. IANAL but as far as I can tell that should avoid all legal concerns once GA is gone.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

Maybe they want to include the most common packages in their unit tests, or understand usage patterns so they can prioritize development?

It’s very hard to write and maintain good software without knowing how it’s used. No package manager needs to know how you specifically use it, but aggregate data and the ability to identify scenarios it does not handle well are both very important for SW lifecycle.

Re: Homebrew 4.0.0

#88

Post by pimterry »

ianai wrote: post #75
pimterry wrote: post #13

Earlier quoted context omitted.

As in the post: they're intending to drop the GA part entirely within 90 days, and it sounds like the new metrics are entirely anonymous, and so not covered by GDPR etc. IANAL but as far as I can tell that should avoid all legal concerns once GA is gone.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

> Why does a package manager need to track their users at all?

According to https://docs.brew.sh/Analytics they use it to measure how often formulas fail to install, to get overall metrics on which OS versions are used, and to correlate those (i.e. to tell on which OS versions specific packages fail to install correctly).

> A maintainer has no need to know who's installing what

Aside from the IP, they don't know who's installing what, and in the new model announced in this post they now don't store IPs or any other user token at all, so it should be purely anonymous aggregate metrics.

Re: Homebrew 4.0.0

#89

Post by ianai »

cassianoleal wrote: post #83
ianai wrote: post #75

Earlier quoted context omitted.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

Assuming their claims of anonymity are true, they won't be tracking users at all. I imagine they can get much richer metrics through this as opposed to only tracking downloads on the server side. I'm not saying I like it. In fact, I plan to keep it disabled. I'm just saying it's a bit naïve to think client-side analytics are the same as server-side download tracking.

Richer how, exactly? I fundamentally don't 'get' what richness they actually need.

If anything they need money, of course, and to know their software works for their users. Prior to release have a test system install the full base, test those packages work, and you know anything less will work too.

Re: Homebrew 4.0.0

#90

Post by ianai »

pimterry wrote: post #88
ianai wrote: post #75

Earlier quoted context omitted.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

> Why does a package manager need to track their users at all? According to https://docs.brew.sh/Analytics they use it to measure how often formulas fail to install, to get overall metrics on which OS versions are used, and to correlate those (i.e. to tell on which OS versions specific packages fail to install correctly). > A maintainer has no need to know who's installing what Aside from the IP, they don't know who'…

All stuff that should be in a trouble ticket from a whiney user. Which we know this type of user would be.

Edit-Also, this is for Mac OS. Chose a few standard OSes to support and test them. If a system update will fix the issue then it shouldn't be fixed at the package manager level.

Post reply on HN