4 ms·

From the module description for peacenotwar: > This code serves as a non-destructive example of why controlling your node modules is important. I've complaine

From the module description for peacenotwar: > This code serves as a non-destructive example of why controlling your node modules is important. I've complained loudly about supply chain weaknesses in the past. But this action, by a trusted author whose identity is known, is not something that our usual models are prepared for, and I'm not sure what we're supposed to learn from it. Our defenses are tuned to protect against attackers who don't want to be known and who don't have a public reputation built up which they burn in one go.

nyanpasu64 5y ago
Making projects more trustworthy: checks and balances, replacing the culture of single-author micropackages with larger multi-maintainer projects (like Qt) where maintainers review each other's work (as well as outside contributors), reducing the ability for one rogue individual to pull stunts (instead requiring the coordination of multiple people, which is not impossible but more difficult). Avoiding delegating trust: simpler dependencies with the minimum necessary functionality for each user, writing code not to ease the job of maintainers, but to better teach users learn how it works, empowering users to review/contribute upstream changes or fork the library if they desire. This conflicts with Boost-like entangled "multi-maintainer projects" where every library has a sprawling tree of internal dependencies, but (I'd argue) not more modular large projects.
powersnail 5y ago
> I'm not sure what we're supposed to learn from it That a individual's reputation doesn't earn enough trust to be an unchecked link in your supply chain. Dude can go rogue at any time, and you have no idea of what might be the trigger, because you don't actually have any personal knowledge of them.
ryukafalz 5y ago
>I'm not sure what we're supposed to learn from it. That just verifying the identity of a software author isn't sufficient to ensure the software is safe. We need to build our software such that the damage that can be done by a malicious actor in control of one component is isolated to that component. There's still some danger from malicious code even in that case, but it's far from the "total system takeover" that any malicious node library can do now. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...
pabs3 5y ago
The lesson is that code peer review is essential for every piece of code, including dependencies and every update. The crev folks have a potential solution to that: https://github.com/crev-dev/ https://github.com/crev-dev/
- rectang 5y ago
  I don't believe that outsider review scales. The amount of energy it takes to review unfamiliar code vastly exceeds the amount of energy it takes to hide something malicious, and a chain is only as strong as its weakest link. Ongoing review by project committers — highly invested insiders, familiar with the codebase — is more realistic, at least in terms of actually detecting problematic code. I was disappointed when I learned that crev's scope includes code quality, a highly subjective and inflammatory subject. I can't see how crev avoids becoming a poo-flinging venue. It seems to me as though competing initiatives which limit the focus to verifying publisher identity hold more promise.
  - pabs3 5y ago
    It likely very much depends on which reviewers you get, for eg Google Zero folks are probably good at code review. I think crev probably handles that through trust scores for reviewers.
- pishpash 5y ago
  The lesson is never auto-update, i.e. pin versions all the way down, like the old days when everything was compiled in.
  - pabs3 5y ago
    That doesn't solve anything, since the version you have could have the issue and you wouldn't know it if you hadn't audited it.
rplnt 5y ago
> and I'm not sure what we're supposed to learn from it. Commit your dependencies and be lazy to keep them up to date, but scan for vulnerabilities. It's far less likely you'd be hit with a 0-day attack than a broad attack (or bug) like this one.
journey_16162 5y ago
I was using node-ipc for an Electron app I'm developing (not published yet). I considered removing it way earlier in favor of just passing messages via Electron main processes, as I considered node-ipc an unnecessary attack vector potential. I was absent from development for the past 2 months, so I did not update the package, and I'm not in Russia or Belarus. However, if it did affect me, I: - Take full-data daily backups to external hard drive (I have 3 in total and rotate them) - I have setup multiple user accounts on Linux for different applications and run them via su / sudo. All it could delete was only the source files which were backed up anyway. I always considered it stupid that a random node module downloaded from Internet with Internet access should have access to all files on my filesystem. I guess all it could do to me is require me to spend an entire day installing the system. I have a detailed spec on what packages to install to replicate exactly the system I have at the moment. Sometimes it pays off to be an Arch Linux geek. In the future, I will have a setup where I will have a full emergency system backup on the pendrive, so even losing the entire computer I could hook all my data and the OS to another computer in a matter of minutes and would lose a maximum of 1 days worth of work. An npm package removing all files on system just because a user is in a country is pure evil, but really, having a backup can go a long way.

nyanpasu64 5y ago

Making projects more trustworthy: checks and balances, replacing the culture of single-author micropackages with larger multi-maintainer projects (like Qt) where maintainers review each other's work (as well as outside contributors), reducing the ability for one rogue individual to pull stunts (instead requiring the coordination of multiple people, which is not impossible but more difficult). Avoiding delegating trust: simpler dependencies with the minimum necessary functionality for each user, writing code not to ease the job of maintainers, but to better teach users learn how it works, empowering users to review/contribute upstream changes or fork the library if they desire. This conflicts with Boost-like entangled "multi-maintainer projects" where every library has a sprawling tree of internal dependencies, but (I'd argue) not more modular large projects.

powersnail 5y ago

> I'm not sure what we're supposed to learn from it That a individual's reputation doesn't earn enough trust to be an unchecked link in your supply chain. Dude can go rogue at any time, and you have no idea of what might be the trigger, because you don't actually have any personal knowledge of them.

ryukafalz 5y ago

>I'm not sure what we're supposed to learn from it. That just verifying the identity of a software author isn't sufficient to ensure the software is safe. We need to build our software such that the damage that can be done by a malicious actor in control of one component is isolated to that component. There's still some danger from malicious code even in that case, but it's far from the "total system takeover" that any malicious node library can do now. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...

pabs3 5y ago

The lesson is that code peer review is essential for every piece of code, including dependencies and every update. The crev folks have a potential solution to that: https://github.com/crev-dev/ https://github.com/crev-dev/

rectang 5y ago
I don't believe that outsider review scales. The amount of energy it takes to review unfamiliar code vastly exceeds the amount of energy it takes to hide something malicious, and a chain is only as strong as its weakest link. Ongoing review by project committers — highly invested insiders, familiar with the codebase — is more realistic, at least in terms of actually detecting problematic code. I was disappointed when I learned that crev's scope includes code quality, a highly subjective and inflammatory subject. I can't see how crev avoids becoming a poo-flinging venue. It seems to me as though competing initiatives which limit the focus to verifying publisher identity hold more promise.
- pabs3 5y ago
  It likely very much depends on which reviewers you get, for eg Google Zero folks are probably good at code review. I think crev probably handles that through trust scores for reviewers.
pishpash 5y ago
The lesson is never auto-update, i.e. pin versions all the way down, like the old days when everything was compiled in.
- pabs3 5y ago
  That doesn't solve anything, since the version you have could have the issue and you wouldn't know it if you hadn't audited it.

rplnt 5y ago

> and I'm not sure what we're supposed to learn from it. Commit your dependencies and be lazy to keep them up to date, but scan for vulnerabilities. It's far less likely you'd be hit with a 0-day attack than a broad attack (or bug) like this one.

journey_16162 5y ago

I was using node-ipc for an Electron app I'm developing (not published yet). I considered removing it way earlier in favor of just passing messages via Electron main processes, as I considered node-ipc an unnecessary attack vector potential. I was absent from development for the past 2 months, so I did not update the package, and I'm not in Russia or Belarus. However, if it did affect me, I: - Take full-data daily backups to external hard drive (I have 3 in total and rotate them) - I have setup multiple user accounts on Linux for different applications and run them via su / sudo. All it could delete was only the source files which were backed up anyway. I always considered it stupid that a random node module downloaded from Internet with Internet access should have access to all files on my filesystem. I guess all it could do to me is require me to spend an entire day installing the system. I have a detailed spec on what packages to install to replicate exactly the system I have at the moment. Sometimes it pays off to be an Arch Linux geek. In the future, I will have a setup where I will have a full emergency system backup on the pendrive, so even losing the entire computer I could hook all my data and the OS to another computer in a matter of minutes and would lose a maximum of 1 days worth of work. An npm package removing all files on system just because a user is in a country is pure evil, but really, having a backup can go a long way.