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

Malicious code in the purescript NPM installer

harry.garrood.me

Post reply on HN
Print view View original

71–80 of 279 posts

Re: Malicious code in the purescript NPM installer

#71

Post by kjksf »

naniwaduni wrote: post #61
matthewbauer wrote: post #32

Earlier quoted context omitted.

That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.

npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.

NPM's size is first and foremost dependent on the popularity of JavaScript.

All other "modern" (where "modern" is "last 20 years") package managers have zero curation.

Perl, Python, Ruby, Go, Rust, Dart, JavaScript.

You say: "if they had curation, they would be better".

I say: "if they had curation, they would have lost to a competitor that doesn't have curation".

People care about having more packages much more than abstract fears of security or quality of those packages.

Re: Malicious code in the purescript NPM installer

#74

Post by delinka »

geofft wrote: post #36
hombre_fatal wrote: post #6

Another reminder of how annoying it is for a package system to have unqualified package names. Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`. This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better. You see all so…

How would that have helped things in this case? If we go with the hypothesis of an angry maintainer getting revenge, would they not be just as angry at their project being forked by the community, and just as able to sabotage it via other libraries still in their namespace? (And perhaps more willing, since their original name is still around.) If we go with the hypothesis of a compromised account, people will still b…

Why would anyone who owns a namespace be willing to leave a package that's moving to another maintainer within their own namespace? A namespace tends to come with a reputation, and if you give an outsider access to the namespace, the reputation can change without the owner's consent. No, I don't think I'd be allowing @delinka/ExcellentPackage to be maintained by someone else. They can fork it to @fredralphbob/ExcellentPackage and I'll turn off @delinka/ExcellentPackage when I'm done maintaining it. Yep, it'll break dependent installs, but that's the point: get dependents to move to the proper version. I think of a namespace like a domain. If I host a project at project.delinka.engineer, I'm definitely not transferring access to the subdomain to a new maintainer.

Yep, we still have people who would eschew best practice and go against my method above, but that happens everywhere. Just because a solution isn't perfect doesn't mean it's not an improvement.

Re: Malicious code in the purescript NPM installer

#75

Post by toupeira »

hedora wrote: post #54
krainboltgreene wrote: post #45

Earlier quoted context omitted.

Please list the group of people you trust to manage 1,037,274 packages.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

Looking at [1] and [2], in unstable it actually seems to be:

- 31K source packages

- which build into 136K binary packages

- consisting of 1.2 billion lines of code

[1] https://sources.debian.org/stats/

[2] https://packages.debian.org/unstable/allpackages?format=txt....

Re: Malicious code in the purescript NPM installer

#76

Post by dcbadacd »

braythwayt wrote: post #64
dcbadacd wrote: post #58

Earlier quoted context omitted.

I don't know how you believe laws work or what you hope to discuss but the reality is that in the case of software, laws offer deterrence and recourse to any malicious actions. It's absolutely stupid to take a repository by an anonymous person, execute it and hope it's not malicious or doesn't have any bugs. Not to mention there's nothing obliging that a piece of software has to be bug free, maintained - go and now d…

You are arguinng a strawman. We are not discussing bugs or maintenance, we are discussing a person acting maliciously. Furthermore, you are talking about people being "stupid," which has no place in a discussion of whether a person giving away code has an obligation to not act maliciously. Never in the history of the courts has a defendant's lawyer gotten up on his hind legs and intoned, "But your honour, the plainti…

You started the thread by saying that if you used a library that is broken by the maintainer you would call that malice. Things being broken is directly related to bugs and maintenance - detecting if and how a breakage is malice is the first problem in your arguments.

I'm also trying to tell you that your whole base premise is wrong, that even expecting some library to work or to keep working is too much (unless you apply one of the solutions I offered). Calling certain behaviors stupid absolutely has a place in a discussion about when people play with fire and then are surprised they get burnt, I think you deliberately missed my point that if you put yourself in danger you only have yourself to blame and most laws do care about that nuance. In the end the job and obligation of keeping the software you write secure is just as much on the person writing some libraries.

We can argue if x or y are effective defense in courts or not but as I said, that hasn't been tried out in the case of open-source software being broken. I also have to repeat that when you look at malicious software and changes in practice then the law applies retroactively and you have to deal with preemptive defense yourself - going back to my first point(s), you have to change the way you develop software instead of hoping what you randomly execute is good.

Hopefully you now understand what I'm trying to say to you better, English isn't my first language, sorry.

Re: Malicious code in the purescript NPM installer

#77

Post by throwaway3627 »

You know a platform doesn't care about security if either:

a. They don't do end-to-end integrity and non-repudiation (not signed hashes of files, not just https, not just hashes, but signed archives/files that can be verified as coming from the developer either with gpg, s/mime or x509 certs)

b. They allow packages to execute code or scripts on download or installation

And, they don't care about your time if they don't automatically offer a prebuilt, reproducible binary mechanism with a build-from-source install/verification option.

Re: Malicious code in the purescript NPM installer

#79

Post by SCLeo »

hedora wrote: post #54
krainboltgreene wrote: post #45

Earlier quoted context omitted.

Please list the group of people you trust to manage 1,037,274 packages.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

Honestly, I think the reliability of those packages are not guarded by these people, but rather by the corresponding communities of those packages.

If one of the community failed to secure its package from malicious people, these people at debian are not going to be able to stop it.

Thus, those packages are still guarded by a huge community.

Post reply on HN