9 ms·

source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github rele

by zalebz 8y ago

source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github releases? can the eslint-scope team not figure out the someone that did the publish? I'm an open source newb but I have to think someone had to accept this malicious code at some point for it to ripple through and make it to release/publish right?

fmpwizard 8y ago
npm doens't take the code directly from the github repo, so far it looks like the new code was publish directly to npm, so there is no git commit to look at as it never was part of the official github repository
mklauber 8y ago
From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.
- consumer451 8y ago
  > someone published their own code instead of code from the github repo Sorry for my ignorance, I have not been a real dev for over 10 years, but wouldn't a better way for NPM to take new packages be for NPM to own the build process? As in the owner of a package would tell NPM: please build and publish from this previously registered repo. Then NPM would have it's own Jenkins servers actually run the build? Based on my very limited understanding the main problem I see with NPM is that I have no idea if the code in the repo was the same code used to build the package. This is what happened in this case, correct? Wouldn't NPM owning the build process solve this problem? I realize this would be a huge load for NPM, but NPM has the world's security riding on its shoulders. I'm ready to be told why this is dumb now... edit: grammar
  - mijamo 8y ago
    But how would you know that the sourced on NPM same as the ones you have? Except if you require all NPM packages to be hosted on Github but that does not seem like a good idea to me.
    - consumer451 8y ago
      Couldn't some simple standard be developed to allow non-github repo hosts to also be used?
      - proneb1rd 8y ago
        Like gpg the payload and make sure npm has a public key.
  - PeCaN 8y ago
    No, that's a fine idea and would've prevented this problem. The build reflecting the repo is a very sane thing to do. Unfortunately NPM is run and used by morons so that'll not happen.
    - ubernostrum 8y ago
      I'm more familiar with the Python/PyPI world, where the "morons" also don't "just" do all the "simple" and "sane" things random internet commenters "helpfully" suggest. But if you want to spin up a package repo that can, say, build the numpy/scipy packages from source and doesn't end up compromised or overloaded as a result, be my guest. Until then, though, maybe hold off with the "morons" commentary and the attacks on people who are doing their best to solve genuinely hard problems at zero charge to the community?
      - Kalium 8y ago
        You're absolutely right! People should hold off on unmerited attacks on those working hard to solve genuinely difficult problems. Yet, is it perhaps possible that tying together build and distribution systems is not an unsolved or unsolvable problem? Bundling build processes with source packages is not a novel notion or even a novel approach. Builds being reproducible is similarly not a novel idea. Or, to put it another way, is it possible that working hard is not a good explanation for other-than-optimal solutions when other options are known?
shusson 8y ago
publishing is separate to the source code. If someone stole the publishers credentials, then they could publish [1]. Only NPM servers would be able to know something special (not the credentials) about who did the publish, e.g IP. [1] https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag...
dpkonofa 8y ago
The someone was a publisher for ESLint whose credentials were stolen separately from this. The malicious code itself isn't stored in the codebase, it's stored in a pastebin doc that's called by URL. Theoretically, the person that did this can change the content of that pastebin file at any time to get new/different code run on machines that have this installed.

by zalebz 8y ago

fmpwizard 8y ago

npm doens't take the code directly from the github repo, so far it looks like the new code was publish directly to npm, so there is no git commit to look at as it never was part of the official github repository

mklauber 8y ago

From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.

consumer451 8y ago
> someone published their own code instead of code from the github repo Sorry for my ignorance, I have not been a real dev for over 10 years, but wouldn't a better way for NPM to take new packages be for NPM to own the build process? As in the owner of a package would tell NPM: please build and publish from this previously registered repo. Then NPM would have it's own Jenkins servers actually run the build? Based on my very limited understanding the main problem I see with NPM is that I have no idea if the code in the repo was the same code used to build the package. This is what happened in this case, correct? Wouldn't NPM owning the build process solve this problem? I realize this would be a huge load for NPM, but NPM has the world's security riding on its shoulders. I'm ready to be told why this is dumb now... edit: grammar
- mijamo 8y ago
  But how would you know that the sourced on NPM same as the ones you have? Except if you require all NPM packages to be hosted on Github but that does not seem like a good idea to me.
  - consumer451 8y ago
    Couldn't some simple standard be developed to allow non-github repo hosts to also be used?
    - proneb1rd 8y ago
      Like gpg the payload and make sure npm has a public key.
- PeCaN 8y ago
  No, that's a fine idea and would've prevented this problem. The build reflecting the repo is a very sane thing to do. Unfortunately NPM is run and used by morons so that'll not happen.
  - ubernostrum 8y ago
    I'm more familiar with the Python/PyPI world, where the "morons" also don't "just" do all the "simple" and "sane" things random internet commenters "helpfully" suggest. But if you want to spin up a package repo that can, say, build the numpy/scipy packages from source and doesn't end up compromised or overloaded as a result, be my guest. Until then, though, maybe hold off with the "morons" commentary and the attacks on people who are doing their best to solve genuinely hard problems at zero charge to the community?
    - Kalium 8y ago
      You're absolutely right! People should hold off on unmerited attacks on those working hard to solve genuinely difficult problems. Yet, is it perhaps possible that tying together build and distribution systems is not an unsolved or unsolvable problem? Bundling build processes with source packages is not a novel notion or even a novel approach. Builds being reproducible is similarly not a novel idea. Or, to put it another way, is it possible that working hard is not a good explanation for other-than-optimal solutions when other options are known?

shusson 8y ago

publishing is separate to the source code. If someone stole the publishers credentials, then they could publish [1]. Only NPM servers would be able to know something special (not the credentials) about who did the publish, e.g IP. [1] https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag...

dpkonofa 8y ago

The someone was a publisher for ESLint whose credentials were stolen separately from this. The malicious code itself isn't stored in the codebase, it's stored in a pastebin doc that's called by URL. Theoretically, the person that did this can change the content of that pastebin file at any time to get new/different code run on machines that have this installed.