discussions

They are not, but npm is uniquely bad in that regard. Refusal to implement security features that would have made attacks like this harder really doesn't help https://github.com/node-forward/discussions/issues/29

PyPI is working towards attestation [0], and already has "Trusted Publisher" [1]. Ruby has had signed gems since v2 [2]. These aren't a panacea. But they do mean an effort has been made. npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4] I don't think it's fair to compare npm to the others. [0] https://docs.pypi.org/attestations/producing-attestations/ [1] https://docs.pypi.org/trusted-publishers/ [2] https://docs.ruby-lang.org/en/master/Gem/Security.html [3] https://github.com/npm/npm/pull/4016 [4] https://github.com/node-forward/discussions/issues/29

And once again calls to allow optional signing support natively to NPM will be rejected citing that it might intimidate drive-by devs who do not want to learn to setup a yubikey or nitrokey for artifact signing. I have talked to the NPM team about this multiple times over the last several years and they literally believe no signing at all is better than some devs feeling pressured to sign. You need no stronger evidence of the NPM teams negligence than these two times they refused to even accept community contributed optional signing support saying they would come up with something better than PGP. Still waiting 10 years later. https://github.com/npm/npm/pull/4016 https://github.com/node-forward/discussions/issues/29#issuec... Meanwhile PGP secures the supply chain of the Linux distros that power the whole internet, and Debian signs hundr

The question in that thread, and this later thread,[1] is how to know which keys are valid to sign a package. For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start t

Sure but logic doesn't exist in a vacuum so in most cases you are going to import / export your input data or your results to the filesystem or through the network. I actually suggested a more granular, per-module approach to this during the Node Forward and IO.js debacle years ago: https://github.com/node-forward/discussions/issues/14 At the time it was deemed to difficult to implement in Node.js after the fact, which makes sense of course. But I'm disappointed that Deno didn't go for a more bolder, more secure approach. The current system seems pretty pointless.

It's been literally years since node-forward got its talk about signing packages [1] with a lot of pushback from the npm team. Every time a new typosquatting article shows up, there's some more waffling by npm. left-pad happened to much consternation. Now this. I used to really care about trying to harden the Node ecosystem, and last year it was one of my main goals. I tried to send multiple vulnerability reports, do mass static analysis of npm packages, and wanted to contribute more to the ecosystem, but the consistent ambivalent reactions of much of the community that I talked to turned me off of the project entirely. If npm wants to continue to be a security dumpster fire, let it burn. Node is a waste of security researchers' time and an honest goldmine for black hats looking to compromise relatively powerful novice webdev hardware. I

Good luck explaining this https://news.ycombinator.com/item?id=16087079 in the face of this https://news.ycombinator.com/item?id=14905870 Literally nothing was done for 158 days. You yourself asked: https://github.com/node-forward/discussions/issues/29#issuec... "How would package signing prevent people from requesting the wrong package? The malware author could also sign their package." And here is a perfect example. Someone replaced a legit package with a malicious one. Had the original author signed the package, then then NPM users could have defended against the new malicious author, because the new author's signing key would not be in their truststore. Unsigned packages leave NPM package users defenseless. I hope that is crystal clear now.

maybe it's time to push for adding signed packages to npm long discussion here: https://github.com/node-forward/discussions/issues/29

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shasum check npm already has." I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. They've done literally nothing. https://github.com/node-forward/discussions/issues/29 Last discussion was > 1 year ago. They simply do not care. Security isn't even an afterthought.

This. I love that the Node community enjoys innovating for convenience, but ideas like this one are less than half-baked from a security perspective. Just make a few typo'd popular packages, and use npm install scripts [1] and you have a very easy remote code execution vector on developer workstations. The bigger problem I see is that npm is a circus. No package signing and a ridiculous debate on why that's been going on for a year and a half [2]. Credentials leaks of popular modules. [3] When everything is a module and everyone is supposed to include modules vs. writing their own very simple functionality for things even like isArray polyfills [4] (24MM downloads a month!), you end up with the same attack surface that gives WordPress such a shitty reputation for security. It's not usually core, it's all the plugins by authors of unknown

This is one of the most important points. And an issue for it has been open since Jan 2015: https://github.com/node-forward/discussions/issues/29 It's, imo, negligent.

> actively seeking input on new features like better numerical comp libs That is one of the most comedic issues on github. Worth a read, but tl;dr: "all we need is to compile these ancient libraries! It should be easy, they are ancient and I am async!" ... "I failed to compile these ancient libraries." https://github.com/node-forward/discussions/issues/1

I don't have very specific details as I'm a bystander too but it seems Node has been stuck in 0.10.x land since early 2013 (http://blog.nodejs.org/2013/03/11/node-v0-10-0-stable/) while Node 0.12 and 1.0 releases were being talked about well over a year ago by former BDFL Isaac Schlueter (now at npm). Joyent, the current project stewards, have not been able to deliver a stable release in that time and don't share public plans / aren't communicating very much. One of the many symptoms of that slow development process is that Node.js is basically running an unsupported version of V8 (https://twitter.com/jmayer/status/532971494695907328). From what I've read, node-forward is/was only meant as a fork in the GitHub sense: they'd try to get their stuff merged back into node mainline. The GitHub fork has since been made private (https://github.c

I didn't find the actual content of the blog post particularly informative in itself, but there's plenty of indication that this is not just someone forking to submit a patch. - https://github.com/node-forward is an organisation, not an individual and has put up various repositories centering around the forking effort. - They have set up a website, http://nodeforward.org/ - which indicates (albeit with scant detail/background) that this is an independent effort to improve node. - as zzmp pointed out, there is a fair bit of discussion around indicating some political discontent: https://github.com/node-forward/discussions/issues/7