5 ms·

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

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.

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.