6 ms·

>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 str

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

runarberg 8y ago
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.
- bendmorris 8y ago
  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?
  - RSZC 8y ago
    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
    - LeoNatan25 8y ago
      React Native then. 1200+ last I remember.
  - mannykannot 8y ago
    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.
- BeeOnRope 8y ago
  It is much less likely the original maintainer will turn malicious, especially a trusted member of the community.
- trickstra 8y ago
  > 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...
  - RSZC 8y ago
    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.
RSZC 8y ago
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.
- trickstra 8y ago
  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.
  - RSZC 8y ago
    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?
    - bendmorris 8y ago
      #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.
- wpietri 8y ago
  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.

runarberg 8y ago

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.

bendmorris 8y ago
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?
- RSZC 8y ago
  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
  - LeoNatan25 8y ago
    React Native then. 1200+ last I remember.
- mannykannot 8y ago
  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.
BeeOnRope 8y ago
It is much less likely the original maintainer will turn malicious, especially a trusted member of the community.
trickstra 8y ago
> 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...
- RSZC 8y ago
  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.

RSZC 8y ago

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.

trickstra 8y ago
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.
- RSZC 8y ago
  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?
  - bendmorris 8y ago
    #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.
wpietri 8y ago
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.