What NPM should do to stop a new colors attack

Re:What NPM should do to stop a new colors attack by Hizonner on Monday January 10, 2022 @12:45PM (#29878509)

The real long-term solution is for projects not to have hundreds of weird dependencies.

If dependencies are pinned until developers update them, you have massive security holes, because developers can't be trusted.

If you take the latest dependencies on every update, you have massive functional exposures (and security holes), because different developers can't be trusted.

If you have "community review", you create a new class of thankless work that nobody will want to do... except power-tripping control freaks who want to gatekeep over whatever their personal obsessions may be.

If users have to pick the versions, nothing will ever work, because users can't be trusted (and wouldn't want to do it anyway).

[ Parent | on HN ]

Re:What NPM should do to stop a new colors attack by awinter-py on Monday January 10, 2022 @01:52PM (#29879650)

review is a compliance function and may be more likely to attract payment than writing OSS, paradoxically

also companies may devote in-house resources to do it

best case IMO is that normalizing paid review leads to normalizing paid bugfixes / feature requests. people need to start thinking about what monetized github looks like

[ Parent | on HN ]

Re:What NPM should do to stop a new colors attack by salawat on Monday January 10, 2022 @03:04PM (#29881228)

Hahahahaha.

You think anyone will pay anything more than lip service to QA?

That's a good one.

[ Parent | on HN ]