3 ms·

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 ow

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?
      - seandougall 8y ago
        This is certainly true, and the statement that NPM is _run by_ "morons" is, while immature in its phrasing, at least potentially aiming toward a legitimate point. However, the post in question also labels NPM's _users_ in broad strokes as "morons", which can make no such claim of legitimacy. It's just a puerile, baseless insult that is devoid of content and detrimental to the poster's credibility.
      - ubernostrum 8y ago
        There's a reason I picked numpy/scipy as examples. Among popular Python packages, they're among the genuinely hardest to build from source. You need several non-Python dependencies, including multiple language build toolchains, to get a working build, and need to dive into notes on things like ABI compatibility between different FORTRAN compilers in order to make sure what you're doing will work. So, setting up something like a PyPI -- again, because that's what I'm familiar with -- that "just" adds the feature of building the packages on machines owned by the package repo is not exactly a simple thing. And PyPI currently hosts over 1M different released packages, so take that number into account when figuring the complexity of all the different things it might have to support. 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? Or, to put it another way, is it possible that people who leave drive-by "helpful" "suggestions" in comment threads about package repositories vastly underestimate what they're asking for, and often don't even really understand the problem domain?

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?
    - seandougall 8y ago
      This is certainly true, and the statement that NPM is _run by_ "morons" is, while immature in its phrasing, at least potentially aiming toward a legitimate point. However, the post in question also labels NPM's _users_ in broad strokes as "morons", which can make no such claim of legitimacy. It's just a puerile, baseless insult that is devoid of content and detrimental to the poster's credibility.
    - ubernostrum 8y ago
      There's a reason I picked numpy/scipy as examples. Among popular Python packages, they're among the genuinely hardest to build from source. You need several non-Python dependencies, including multiple language build toolchains, to get a working build, and need to dive into notes on things like ABI compatibility between different FORTRAN compilers in order to make sure what you're doing will work. So, setting up something like a PyPI -- again, because that's what I'm familiar with -- that "just" adds the feature of building the packages on machines owned by the package repo is not exactly a simple thing. And PyPI currently hosts over 1M different released packages, so take that number into account when figuring the complexity of all the different things it might have to support. 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? Or, to put it another way, is it possible that people who leave drive-by "helpful" "suggestions" in comment threads about package repositories vastly underestimate what they're asking for, and often don't even really understand the problem domain?