Hacker News Reader

Comment by bendmorris | Hacker News Reader

>He had no way of knowing the person who took it over would use it maliciously.

Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name.

He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.

View on HN

The latter solution isn't much better - all the community momentum of the first project is instantly gone. Now you have a set of forks, all with a different small set of patches on top. Which are maintained? Which will be maintained going forwards? Any new user looking for this functionality has no idea. Maybe none of them.

He didn't give anybody the power to do things in his name. He gave a stranger the power to contribute to a shared codebase. He never claimed to be a BDFL of this codebase. Your vitriol would be much better aimed at node modules which depended on non-fixed code which they didn't audit.

losing the "momentum" on an abandoned package is a much better choice than having it fall into the wrong hands together with all the people who use it and didn't even know about the change of owner.

That's a false dichotomy. The actual options are:

1. Dead project

2. You share access to lots of people and they act responsibly

3. You share access to lots of people and they act irresponsibly

#2 is waaaay more likely than #3.

Still seems to me like people are blaming the wrong person here. If you're writing a cryptocurrency-related module (the target of this specific attack) and you're using npm modules written by somebody you don't know, what the hell are you doing?

#2 is more likely than #3 because a reasonable person gives access to another contributor or someone they spent a few minutes vetting, not a total stranger with no GitHub history.

Exactly. Both ways have have costs and benefits. It's certainly easy take this one example and say, "All projects should optimize for this very rare failure case." But you can bet that if he just closed his 700 packages down, we'd have plenty of people explaining how that was the wrong solution, that he should work to find maintainers.

As far as I'm concerned all of this "he should have" stuff is more proof that he's right: maintaining a popular open-source package for free can be no fun at all.

>The latter solution isn't much better

It is unquestionably better than your users, whose trust you've earned over time, suddenly finding that their app is mining cryptocurrency.

>He didn't give anybody the power to do things in his name.

His name is still on the project he gave away access to, so yes, he did.

>Your vitriol would be much better aimed at...

I think criticism is warranted here, but I don't think I've been especially vitriolic about it. Frankly, OP made a poor choice and is now making excuses by complaining about not being rewarded for maintaining the project rather than own up to it. There was a better way to do this without him having to perpetually maintain the project.

And moreover, the herd of commenters here on HN are projecting their dissatisfaction with entitled open source users onto anyone who criticizes OP.

As a user of free software you should always accept the risk that it is maintained by a malicious actor. It is just as likely that the original author will turn malicious. You as a user have the responsibility of auditing all the free software you use.

People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?

React does not have hundreds of dependencies:

  └─┬ react@16.6.3
    ├─┬ loose-envify@1.4.0
    │ └── js-tokens@4.0.0
    ├── object-assign@4.1.1
    ├─┬ prop-types@15.6.2
    │ ├── loose-envify@1.4.0 deduped
    │ └── object-assign@4.1.1 deduped
    └─┬ scheduler@0.11.2
      ├── loose-envify@1.4.0 deduped
      └── object-assign@4.1.1 deduped

React Native then. 1200+ last I remember.

The point, I think, is that this is the real problem, and while Dominic might have made it harder for the attacker to get this exploit into the wild, there is nothing that he could have done that would have prevented such an outcome.

If one is writing something as security-critical as a Bitcoin wallet, then not using React (and other things with a similarly wide attack surface) is indeed the best you can do. Security is not tolerant of half-assed measures.

It is much less likely the original maintainer will turn malicious, especially a trusted member of the community.

> It is just as likely that the original author will turn malicious

it absolutely isn't. The original author is a real person, with a twitter account, with a profile photo, with videos of talking at conferences. I accepted the code in my project because such author wouldn't get away with injecting the code with a backdoor. But a random alias that quietly takes over a package I didn't even know was abandoned because the author was too lazy to write "This package is no longer maintained" in the readme? That didn't give me any chance...

Depending on the author's reputation isn't much better. Maybe the author uses a weak password and doesn't have 2FA on his npm account. You have absolutely no idea.

Reply on news.ycombinator.com