4 ms·

Value-add to the people who actually use github to build software, of course. It's fine to discuss license terms and what you should or shouldn't expect when yo

by mithr 5y ago

Value-add to the people who actually use github to build software, of course. It's fine to discuss license terms and what you should or shouldn't expect when you use github/npm/etc, but in the real-world JS landscape, many projects (commercial and otherwise) use many open-source packages through complex dependency hierarchies. Your can think what you want about whether that's good or bad, but it's unquestionably our current reality. Protecting JS projects from malicious updates, regardless of whether or not the project license technically permits this by the author, is clearly in the best interest of users of this ecosystem.

encryptluks2 5y ago
No one took steps to protect JS projects from malicious updates. They took action in this one case but did not fix the underlying issue which is with package managers.
- shadowgovt 5y ago
  It is true that there are some vulnerabilities in the standard design for npm package management. Packages are designed to assume by default sources can be trusted and to pull aggressively. That's a system that's very convenient for developers... Assuming somebody doesn't use it in an extremely malicious way by building our trust with a working package and then pushing a change designed to screw users. Fortunately, it appears the system has been stress tested now and we can see how that damage can be mitigated. If this kind of attack can be minimized by what is essentially moderation and curation, everything's good.
  - encryptluks2 5y ago
    The only reason anything happened cause the developer intentionally crippled their own package which they had the right to do. If someone was modified a package to do something actually malicious you could go months without ever finding out.
    - shadowgovt 5y ago
      I don't disagree that there are degrees of harm and differences in the ease of detecting such harm. But what's the significance of the distinction? Whether it's found out immediately or found out months later, the remedy for the community will likely be the same if the damage is widespread enough... Flag the version as bad in npm, break the connection between npm and the GitHub repo if the damage was purposeful, and the community picks up the package and starts maintaining a non-malicious version.

by mithr 5y ago

encryptluks2 5y ago

No one took steps to protect JS projects from malicious updates. They took action in this one case but did not fix the underlying issue which is with package managers.

shadowgovt 5y ago
It is true that there are some vulnerabilities in the standard design for npm package management. Packages are designed to assume by default sources can be trusted and to pull aggressively. That's a system that's very convenient for developers... Assuming somebody doesn't use it in an extremely malicious way by building our trust with a working package and then pushing a change designed to screw users. Fortunately, it appears the system has been stress tested now and we can see how that damage can be mitigated. If this kind of attack can be minimized by what is essentially moderation and curation, everything's good.
- encryptluks2 5y ago
  The only reason anything happened cause the developer intentionally crippled their own package which they had the right to do. If someone was modified a package to do something actually malicious you could go months without ever finding out.
  - shadowgovt 5y ago
    I don't disagree that there are degrees of harm and differences in the ease of detecting such harm. But what's the significance of the distinction? Whether it's found out immediately or found out months later, the remedy for the community will likely be the same if the damage is widespread enough... Flag the version as bad in npm, break the connection between npm and the GitHub repo if the damage was purposeful, and the community picks up the package and starts maintaining a non-malicious version.