3 ms·

Not sure about this bit: > This is quite a bit of work, but is necessary to avoid falling victim to attacks like _event-stream_. Reviewing dependencies is imp

Not sure about this bit: > This is quite a bit of work, but is necessary to avoid falling victim to attacks like _event-stream_. Reviewing dependencies is important, but I don't think anything the author mentions would have made a difference with event-stream. The whole issue there was that malicious changes were snuck in via a change of maintainers and a later update to a child dependency, so when people initially adopted it as a dependency there were no red flags in the library to find.

square_usual 7y ago
He talks about reviewing dependencies when they are updated, as well, which certainly would help if someone snuck in malicious code in a minor version change.
- fenomas 7y ago
  Well, he talks about reviewing when he upgrades a dependency, but the tricksy thing about event-stream was that people could get the malicious change without having intended to upgrade anything. The only thing that really prevents such issues is version locking of transitive dependencies (which the author doesn't mention, but it could be that his package manager does it by default, or similar..).
  - colonwqbang 7y ago
    I had missed that npm doesn't (didn't?) lock package versions by default. That's really scary.
    - fenomas 7y ago
      It does today, and I could be crazy but I think it did even before event-stream. But of course some users will have been on old versions of npm, or not checking in their lockfiles, etc. I should add, I was probably wrong to talk about lockfiles preventing such issues. With event-stream the malicious code was hidden deviously enough to evade a pretty rigorous check - if a Node update hadn't deprecated one of the functions used in the payload, I suppose we might still not know about it. In such cases a lockfile is at least a layer of defense, but naturally it only helps if you're lucky enough to have installed the library before it got corrupted..

square_usual 7y ago

He talks about reviewing dependencies when they are updated, as well, which certainly would help if someone snuck in malicious code in a minor version change.

fenomas 7y ago
Well, he talks about reviewing when he upgrades a dependency, but the tricksy thing about event-stream was that people could get the malicious change without having intended to upgrade anything. The only thing that really prevents such issues is version locking of transitive dependencies (which the author doesn't mention, but it could be that his package manager does it by default, or similar..).
- colonwqbang 7y ago
  I had missed that npm doesn't (didn't?) lock package versions by default. That's really scary.
  - fenomas 7y ago
    It does today, and I could be crazy but I think it did even before event-stream. But of course some users will have been on old versions of npm, or not checking in their lockfiles, etc. I should add, I was probably wrong to talk about lockfiles preventing such issues. With event-stream the malicious code was hidden deviously enough to evade a pretty rigorous check - if a Node update hadn't deprecated one of the functions used in the payload, I suppose we might still not know about it. In such cases a lockfile is at least a layer of defense, but naturally it only helps if you're lucky enough to have installed the library before it got corrupted..