News for hackers. Stuff that matters.
Re:What NPM should do to stop a new colors attack by awinter-py on Monday January 10, 2022 @12:26PM (#29878220)
uhhh yes staying pinned to an old version forever solves some problems, but not other problems? article doesn't mention 'npm audit' and how there are cases where you want to encourage an upgrade

real long-term solve here is a code review community for widely-used public packages I suspect?

am not a huge blockchain fan but this is one thing that blockchain could conceivably do well, because reviews are public, need to be authenticated, exist as compact metadata that can fit on chain, and benefit from public reputation dynamics

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).

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

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.

Re:What NPM should do to stop a new colors attack by howdydoo on Monday January 10, 2022 @12:34PM (#29878337)
A blockchain isn't needed for that. Authentication needs "crypto"graphy, but not "crypto"currency.

This wouldn't be a complete thread without someone mentioning Rust, so I'll do it. cargo-crev is a nice web-of-trust type code review system for Rust crates. https://github.com/crev-dev/cargo-crev

Re:What NPM should do to stop a new colors attack by awinter-py on Monday January 10, 2022 @12:41PM (#29878455)
I swear I'm not normally this person but I think if 'web of trust' means a database that is replicated in parts across many different computers and uses cryptographic signing to authenticate messages, you're describing the thing known to the bros and the gen-Zs as a blockchain
Re:What NPM should do to stop a new colors attack by howdydoo on Monday January 10, 2022 @01:03PM (#29878813)
Web of trust just means "If A trusts B, and B trusts C, then A trusts C." Nothing to do with distributed databases/ledgers.
Re:What NPM should do to stop a new colors attack by mctaylor on Monday January 10, 2022 @04:07PM (#29882483)
Blockchain refers specifically to a linked-list-like data structure which utilizes cryptographic hashes at each node to store an authentication of the tail of the list on each head (node). If you have a similar structure using trees, it's a merkle tree. Replication + message signing does not imply either (necessarily).
Re:What NPM should do to stop a new colors attack by Aea on Monday January 10, 2022 @12:53PM (#29878649)
"Web of Trust" predates Cryptocurrency / Blockchain by decades.
Re:What NPM should do to stop a new colors attack by simlevesque on Monday January 10, 2022 @12:53PM (#29878644)
A blockchain and a cryptocurrency are two different things.
Re:What NPM should do to stop a new colors attack by philosopher1234 on Monday January 10, 2022 @12:27PM (#29878241)
Where did you get forever? The idea in the article is to upgrade dependencies only when the maintainers are ready to/explicitly say to.