NPM Vulnerability Discussion on Twitter

• npm

  48 17,233 2.1 JavaScript

I checked the password-reset flows for most major NPM contributors that use regular webmail accounts like Gmail too.

< 10% had useful 2FA enabled. Most were just password reset questions or had a backup email to some old expired and re-registerable forgotten earthlink accounts etc.

I do this stuff all the time.

The solution is what all sane OS package managers do: code signing.

NPM has rejected this at least as far back as 2013 when they rejected a PR by someone that implemented it for them: https://github.com/npm/npm/pull/4016

I don't know what else to do but keep publicly trolling them at this point. Unsigned code is a free pass for remote code execution when an account gets taken over.

Meanwhile Debian maintains hundreds of signed nodejs packages. It is very doable. NPM seems to just want to reduce deveopler friction at all costs.

• discussions

  1 149 10.0

  Soliciting ideas and feedback for community driven collaborative projects that help Node. (by node-forward)

  

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 to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.

It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]

[1] https://github.com/node-forward/discussions/issues/29

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• HomeBrew

  1,281 39,303 10.0 Ruby

  🍺 The missing package manager for macOS (or Linux)

  

• isnan

  1 0 10.0 JavaScript

  Test whether value is NaN

• rfcs

  7 41 4.6

  RubyGems + Bundler RFCs (by rubygems)

  

> < 10% had useful 2FA enabled.

I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA.

[0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...

[1] https://github.com/rubygems/rfcs/issues/35

• enquirer

  18 7,487 4.9 JavaScript

  Stylish, intuitive and user-friendly prompts, for Node.js. Used by eslint, webpack, yarn, pm2, pnpm, RedwoodJS, FactorJS, salesforce, Cypress, Google Lighthouse, Generate, tencent cloudbase, lint-staged, gluegun, hygen, hardhat, AWS Amplify, GitHub Actions Toolkit, @airbnb/nimbus, and many others! Please follow Enquirer's author: https://github.com/jonschlinkert

  

> I don't fully understand why packages like this are so popular.

It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. Now `iseven`, `isodd` are downloaded alongside `importantPackage`.

My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/

• Babel (Formerly 6to5)

  58 42,888 9.8 TypeScript

  🐠 Babel is a compiler for writing next generation JavaScript.

  

The reason it doesn't get called out is because the philosophy of "thousands of small packages" has spread far and wide. [1]

For every person calling it out like we're doing here, there are ten others praising maintainers able to whip ten semi-useless packages per week.

It's not just random maintainers making small packages. The core infrastructure of Javascript is in it. Babel is made of hundreds of packages, which all live on the same repository (because of course the maintainers don't want the hassle of maintaining multiple things). Some of those packages don't even have anything of importance in it, just metadata, a couple flags and some boilerplate [2]. The package is just a way of organizing code. Webpack, ESLint and others aren't exactly better.

The reason people do it is because other popular people have been doing it for a long time, and nobody calls them out on it.

[1] https://blog.sindresorhus.com/small-focused-modules-9238d977...

[1] https://github.com/babel/babel/blob/main/packages/babel-plug...

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project