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

241–250 of 279 posts

Re: Malicious code in the purescript NPM installer

#241

Post by sergiomattei »

SCLeo wrote: post #81
svnpenn wrote: post #80

The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...

I honestly don't understand why people use packages like this. If I need this functionality, I will simply write my own. Plus, I will never able to find this specific package. I guess PureScript uses this because its author is also the author of rate-map.

As usual, everyone here will start their "I'm better than this" comments.

If you've ever used a code dependency, you are a target for malicious code. That's just how it is.

In this case, using small packages like this helps in...

1. Reliability - these packages are typically 100% unit tested

2. Convenience

3. Reduce codebase size. I can't imagine having to copy paste every little small function into a mega utils file.

Re: Malicious code in the purescript NPM installer

#242

Post by gridlockd »

munificent wrote: post #151
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…

> It's just infinitely, obviously better. Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know. RubyGems used to be namespaced this way and moved away from it. They didn't do so lightly. The problem is that ownership, and even names of owners change all the time . In the very very large majori…

> The problem is that ownership, and even names of owners change all the time.

If ownership changes, I want to know. It's perfectly fine to cause a little bit of breakage there that is easily fixed in a semi-automated, supervised way.

If a name changes, there could just be an alias, unless there's literally a trademark dispute underway, in which case the ownership-change process can be applied.

> When you have very large transitive dependency graphs, the result is constant, pointless churn.

A very large transitive dependency graph is a terrible thing to have. It shouldn't be made convenient to have it. Your package manager should scold you for it!

In all seriousness, if you have such a huge graph, then the amount of churn caused by package updates will likely be the dominating factor, not the change of ownership.

Re: Malicious code in the purescript NPM installer

#243

Post by gridlockd »

mschuster91 wrote: post #165
munificent wrote: post #151

Earlier quoted context omitted.

> It's just infinitely, obviously better. Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know. RubyGems used to be namespaced this way and moved away from it. They didn't do so lightly. The problem is that ownership, and even names of owners change all the time . In the very very large majori…

Why not resolve the owner name to some kind of uuid at time of package require/install and saving it in the lockfile? That way, a package upgrade can detect if the owner name has changed and fetch the correct package.

This doesn't solve the issue where you type "npm i -s letf-pad" and your computer gets taken over by The Russians™.

Make people copy-paste the name, it decreases the chances of catastrophic failure.

Re: Malicious code in the purescript NPM installer

#244

Post by gridlockd »

_pmf_ wrote: post #185
munificent wrote: post #151

Earlier quoted context omitted.

> It's just infinitely, obviously better. Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know. RubyGems used to be namespaced this way and moved away from it. They didn't do so lightly. The problem is that ownership, and even names of owners change all the time . In the very very large majori…

> Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know. The Maven ecosystem has been doing things better than NPM for at least 10 years. The onus is on the NPM team for justifying their pathologically bad solution, it's also on the JS community to back off their "everybody can contribute" pipe…

I think the problem is that Java people are considered "old and lame", whereas the Javascript people are considered "young and immature", respectively. While this assessment is somewhat accurate, it inhibits the process of learning from each other.

Re: Malicious code in the purescript NPM installer

#245

Post by ben509 »

ricardobeat wrote: post #98
SCLeo wrote: post #81

Earlier quoted context omitted.

I honestly don't understand why people use packages like this. If I need this functionality, I will simply write my own. Plus, I will never able to find this specific package. I guess PureScript uses this because its author is also the author of rate-map.

I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up. This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.

> edge cases already figured out.

Nope, it doesn't guarantee its invariants. This would pass all the tests and yet returns a value out of bounds:

    > s = 1e12
    1000000000000
    > e = 1e-8
    1e-8
    > s + 1.0 * (e - s)
    0

Re: Malicious code in the purescript NPM installer

#246

Post by tudelo »

trabant00 wrote: post #157
School-Cotton wrote: post #103

Earlier quoted context omitted.

It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.

> Packages being months behind the latest version is a feature, not a bug I struggle to convince devs and management about this in the past few years. Everyone's gone crazy about latest and greatest set of features with no respect for stability, maintainability, etc.

To be fair upgrading very old libraries because you hit a fixed bug to very new libraries can be a long process... but I never have worked on a project that stayed on new libraries continuously so... not sure how it works the other way.

Re: Malicious code in the purescript NPM installer

#247

Post by samirm »

runeks wrote: post #177

The work “exploit” is used several times but none of the code seems to exploit anything. Also, “malicious code” usually has a different meaning than something that intentionally makes the program crash during the installation process.

Agreed about this not being an exploit, but this is definitely malicious code.

Re: Malicious code in the purescript NPM installer

#248

Post by oblio »

allover wrote: post #202
McGlockenshire wrote: post #13

Earlier quoted context omitted.

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.

> Even PHP gets this right. It's not hard. PHP had the luxury of coming out with a package manager (Composer) later, and learning from others before it. (2012 vs 2010 for npm). Npm similarly improved on a lot of package managers that came before (e.g it's superior to Pip, which doesn't resolve dependencies [1]). > It makes me wonder why npm hasn't already moved to namespaced package names. Also, npm does have namespa…

Apache Maven was released in 2004... PHP just looked at what Java was doing. Might be a wrong idea for some things but it definitely helps for stuff such as package management.

Re: Malicious code in the purescript NPM installer

#249

Post by oefrha »

School-Cotton wrote: post #104
SCLeo wrote: post #79

Earlier quoted context omitted.

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.

Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.

My software is packaged by Debian, and the update process is me notifying the Debian Developer (DD) responsible for the package of the new version => said DD pulling the new tarball from GitHub. Pretty sure no one’s gonna notice until after it’s pushed to Debian FTP if I introduce some subtle malicious code. Point is DDs don’t review version deltas for the most part, so when the upstream is compromised, they add little to your defense (other than security by outdatedness, I suppose).

Re: Malicious code in the purescript NPM installer

#250

Post by [deleted] »

justinclift wrote: post #145
GordonS wrote: post #56

Earlier quoted context omitted.

A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.

You may be correct for javascript, whose ecosystem is notoriously unstable and the equivalent of "building on sand". eg write some code in a JS framework, then go off and do something for 18 months. Come back and there's a very good chance the entire framework has been obsoleted and replaced, perhaps even several times. In JS land that's "Doh, well of course!". In sane ecosystems (eg not Ruby), not so much. ;)

[deleted]
Post reply on HN