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

Package Managers need global hooks

captnemo.in

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Package Managers need global hooks

#51

Post by bluGill »

zihotki wrote: post #46

The solution is called curated package feed. Using private one instead of default public package source, you get a trusted source. All updates should be done by first pulling the new packages to the private feed and only after passing the reviews - update. A little bit of bureaucracy in form of best security practices helps with supply chain attacks.

Most people are not qualified to determine what should go into their private package feed. Learning accounting is hard enough without learning packages - and accountants shouldn't have to learn this details, division of labor is a good thing (I picked accountants at random, the vast majority of humans have an important job that isn't packages and shouldn't have to know this)

Re: Package Managers need global hooks

#52

Post by fc417fc802 »

eqvinox wrote: post #35
captn3m0 wrote: post #20

Earlier quoted context omitted.

`PreInstall` mainly. But `PreFetch/PreBuild` also for source-repositories, such as AUR helpers. homebrew doesn't support hooks as a system package manager: https://github.com/ecosyste-ms/package-manager-hooks as an example. I think the packaging ecosystem is varied enough that this should be left for the package managers to decide. Yarn allows dependency resolution and WebFetch overrides in its hooks for eg.

> `PreInstall` mainly. But `PreFetch/PreBuild` also for source-repositories, such as AUR helpers. I don't think this is detailed enough - what exactly should the hooks be able to do? Affect dependency resolution? Choice of versions? Are they per run or per package? Is something already downloaded so it can be inspected?

They should be able to do literally anything and everything. Treat it more like a packet in the linux networking stack, your filter chain gets run at some well defined point during the process and can query or change approximately anything.

Re: Package Managers need global hooks

#54

Post by drdexebtjl »

self_awareness wrote: post #13
drdexebtjl wrote: post #11

Earlier quoted context omitted.

Not all package managers require root. But yeah, maybe through an exploit with a narrow reach. Once in, the malware can veto security updates and escalate to full control.

With root, malware can reach out to UEFI anyway, and can do whatever it likes.

Writing text to a specific root-owned config file != being root. If you have the former, you need something like this to escalate.

I’d prefer if my package manager had no ability to run arbitrary payloads at all.

Re: Package Managers need global hooks

#55

Post by amiga386 »

fc417fc802 wrote: post #50
amiga386 wrote: post #41

Earlier quoted context omitted.

I haven't ever seen "a campaign" get through Debian's release process, besides xz-utils. The only major blemish in Debian's record was in 2006 when one of its developers patched OpenSSL to avoid using uninitialised memory as a source of randomness, in order to placate a static analyser. Nobody in Debian noticed that this effectively made OpenSSL key generation entirely predictable (it only generated one of 32768 uniq…

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thing to do) IIUC instead the core part of the function that mixes new randomness in was patched out. Like the tire was flat so you went ahead and just chopped off the entire axle with an angle grinder because who needs 4 wheels anyway.

Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022...

Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say)

And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

These links contain specific people's names, but the important thing is not to blame those people specifically, because this failure came from the whole Debian community and its values. A community that eagerly went looking for, e.g. valgrind correctness. A community that thought it knew better than upstream, and didn't check their changes with them. A community that values neat patches that close bugs, without thinking of the wider ramifications.

The community has learnt a lot of lessons since 2008, and is now much more aware of how packager meddling could cause security flaws.

(You could also single out the OpenSSL developers for their faults too, but this particular error was on Debian)

Re: Package Managers need global hooks

#56

Post by advisedwang »

JKolios wrote: post #28

1. There are 5 competing standards. 2. This is clearly unacceptable, so we've created the one standard to unite them all™. 3. There are 6 competing standards.

The author is proposing a new feature on existing package managers, not replacing package managers with a new one.

Re: Package Managers need global hooks

#57

Post by JKolios »

advisedwang wrote: post #56
JKolios wrote: post #28

1. There are 5 competing standards. 2. This is clearly unacceptable, so we've created the one standard to unite them all™. 3. There are 6 competing standards.

The author is proposing a new feature on existing package managers, not replacing package managers with a new one.

It was a tongue-in-cheek comment, not really a perfect analogy to the situation. Still, the author expects teams with different priorities and design philosophies to follow a new standard, that can easily end up in more fragmentation.

Re: Package Managers need global hooks

#58

Post by WorldMaker »

advisedwang wrote: post #56
JKolios wrote: post #28

1. There are 5 competing standards. 2. This is clearly unacceptable, so we've created the one standard to unite them all™. 3. There are 6 competing standards.

The author is proposing a new feature on existing package managers, not replacing package managers with a new one.

The author is proposing replacing a suite of security tools that integrate with package managers in a variety of ways (directly inside the package manager, through package manager hooks when available, as firewalls/repo hosts/network proxies) with a single security tool that "universally" works for every package manager that supports a new standard ("global hooks").

Some security experts are still going to prefer the firewalls or network proxies given the choice. Some security experts are still going to prefer package manager-specific security tools rather than a single "universal" one.

Re: Package Managers need global hooks

#59

Post by captn3m0 »

WorldMaker wrote: post #58
advisedwang wrote: post #56

Earlier quoted context omitted.

The author is proposing a new feature on existing package managers, not replacing package managers with a new one.

The author is proposing replacing a suite of security tools that integrate with package managers in a variety of ways (directly inside the package manager, through package manager hooks when available, as firewalls/repo hosts/network proxies) with a single security tool that "universally" works for every package manager that supports a new standard ("global hooks"). Some security experts are still going to prefer the…

Hooks are not a new standard. Package managers have always supported hooks. It is just a call to get us to parity.

Re: Package Managers need global hooks

#60

Post by WorldMaker »

captn3m0 wrote: post #59
WorldMaker wrote: post #58

Earlier quoted context omitted.

The author is proposing replacing a suite of security tools that integrate with package managers in a variety of ways (directly inside the package manager, through package manager hooks when available, as firewalls/repo hosts/network proxies) with a single security tool that "universally" works for every package manager that supports a new standard ("global hooks"). Some security experts are still going to prefer the…

Hooks are not a new standard. Package managers have always supported hooks. It is just a call to get us to parity.

Package managers have individually supported hooks, configured in different ways, and with different metadata available unique to the package manager in each hook. Any attempt to standardize hooks "globally" would be a new standard. It might borrow elements from existing implementations of this package manager or that package manager, but it doesn't sound like you build a "universal" hook without some deeper standard on which events get hooked, what metadata is presented and how, etc. It stands to reason as you start to standardize that sort of stuff the final standard won't resemble any specific package manager's existing hooks.
Post reply on HN