Intentionally corrupting popular libraries by maintainer | Hacker News Reader

Intentionally corrupting popular libraries by maintainer

developers.slashdot.org

2 pointsjzer0cool7 comments

In an ideal decentralised world, anyone would be able to publish anything, but new versions of packages wouldn't get automatically downloaded until multiple trusted third parties had independently verified there were no regressions or security issues introduced.

Right now we have a collapsed version of that system, where the code host, package repo, and "auditing" is all done by one company, which gives them a lot of power and not much accountability. Also, to be clear, the "auditing" they do is only after the fact, i.e. they wait for other people to find a problem with a package and then only prevent it causing future harm.

Ultimately, though, you either have to read every line of code yourself, or trust some person or group of people to make security decisions on your behalf. In this case it only took one malicious person to cause trouble, and this can be mitigated by requiring more (independent) reviewers. The cost of adding more reviewers scales linearly with the number of reviewers, whereas the chance of them all independently but simultaneously being malicious decreases exponentially, so economics suggests this might be solvable if the value could be captured.

Sigstore is an interesting move towards you ideal world, likely possible today. You could watch the signers of a project and I've thought that trusted, large scale auditors will emerge.

Decentralized trust on a centralized system.

I think this is interesting story on many fronts from both an ethical front as well as systems to communicate better exactly what packages are being used.

Right now, many packages are deeply dependent on other packages. If at a wrong time, things could break, and worst, timed correctly, malicious code in at some random interval that may go uncaught.

What is the correct direction we need to head as developers and the toolings needed? This is not from perspective of just the maintainers, but this makes the point that breaches and unauthorized pushes could happen.

``` In response to the corrupted libraries, Microsoft quickly suspended his GitHub access and reverted the projects on npm.... ```

Microsoft embraces open source

Ehhh. In this case, Microsoft restored an open source project that someone tried to sabotage. There's definitely reasons to believe that they don't truly love open source, but this isn't one of them.

That code was his. Not anyone else's. There was also no assignment of copyright to Microsoft. I'd argue they overstepped their bounds. Further, he violated no tenant of an organization in what could arguably happen if say, Linus went off the deep end and scragged the Linux kernel somehow where you could say he violated the norms of the kernel group. Faker and colors does not rise to that.

People may not like that dependencies can have this happen, but this is why you read that code, and don't depend on a million things. Ethically, I can see the case for both sides, but pragmatically, I weigh in on the side of protecting the maintainer's right to post what he wants over Microsoft or anybody else's right to not be broken by blindly sucking down updates.

Again, unpopular as it is, that NO WARRANTY OF FITNESS FOR USE OR MERCHANTIBILITY IMPLIED OR EXPLICIT either means exactly what it does, and should be reacted to accordingly by users of the code (audit first), and furthermore, means Microsoft is now on the hook for damages for usurping his intellectual property; or it doesn't and we need to have a long chat about the nature of software.

> Again, unpopular as it is, that NO WARRANTY OF FITNESS FOR USE OR MERCHANTIBILITY IMPLIED OR EXPLICIT either means exactly what it does, and should be reacted to accordingly by users of the code (audit first), and furthermore, means Microsoft is now on the hook for damages for usurping his intellectual property; or it doesn't and we need to have a long chat about the nature of software.

This is a false dichotomy, and even if the disclaimer was fully effective it wouldn't imply what you say about Microsoft's liability (or even imply that the original code owner does not have liability for malicious harms arising under tort principles other than warranty.)

Reply on news.ycombinator.com