Earlier quoted context omitted.
445 12th Street, SW Washington, DC 20554 1-202-418-1440
That's probably an illegal sublet fyi.
It’s the headquarters of the FCC.
Npm operational incident, 6 Jan 2018
61–70 of 197 posts
Re: Npm operational incident, 6 Jan 2018
#62Earlier quoted context omitted.
I agree in principal about not relying on npm during deployment. For a novice, what is the best way to ship modules?
My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...
Committing your `node_modules` is a bad idea. The best answer is to either use an offline cache of package tarballs that have been committed to your repo, or an NPM caching proxy.
Yarn has an "offline mirror" feature built in, and Shrinkpack is a tool that can create an offline mirror based on an npm-shrinkwrap.json file.
I wrote about using Yarn's offline mirror here: http://blog.isquaredsoftware.com/2017/07/practical-redux-par...
Re: Npm operational incident, 6 Jan 2018
#63Earlier quoted context omitted.
I don't think the dispute resolution process makes them untrustworthy. It's an annoyance. It's the unpublishing that's a huge security flaw vector, and the fact that they didn't actually fix what they claimed is pretty bad.
To me it's a trust issue. Their dispute policy breaks trust in two ways- 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. What you say is also a problem. The fact that they…
I agree as well. The guy published his kik package well before Kik was even a company. There was no reason for the npm team to resolve the situation they way they did. If someone already owns your Twitter ID or Facebook page name, well they're closed private services. Same if someone buy's your domain name (see the case of Nissan).
You don't have a right to a name on every service on the planet just because you trademark it somehow.
Re: Npm operational incident, 6 Jan 2018
#64I think it's time to replace npm in default Node installs. They've shown a history of negligence for package handling and procedure. Why should Node continue putting the trust of such a substantial part of not only their ecosystem but the JS ecosystem as well into such unreliable hands?
the official node.js Docker image comes with yarn as well as npm. but this is an issue with the npm registry, not the package manager shipped with node. both yarn and npm use the npm registry. EDIT: it may be worth debating why npm (a binary produced by npm, Inc) is shipped with node.js at all, but that's upto the node foundation
I’m pretty sure npm is shipped as Javascript source by node.js
Re: Npm operational incident, 6 Jan 2018
#65Earlier quoted context omitted.
Yeah, about two years ago NPM stole a package name from an existing user and gave it to a company to use. The user then said that if he can't trust NPM to actually treat package naming fairly then he was just going to delete all of his packages[1]. This broke a ton of packages on people (in part due to "left-pad" disappearing), so the community went ahead and registered/uploaded all of the packages to NPM again. Afte…
Just had a quick look - the "kik" package isn't in even use anymore - the whole thing was just drama theatre from by a messaging app I've never heard of. Despite it having 200 million users. Apparently.
Kik is mostly popular outside the west, it is pretty popular in South East Asia.
Re: Npm operational incident, 6 Jan 2018
#66Very disheartening to see that NPM has not grown from the kik or left-pad incidents. Users should not be able to republish on top of old package names without some kind of intervention.
Of course, NPM's response to the kik/left-pad problem was also pretty awful. Make it so users can't delete packages. Cool. For those of you using NPM's private offerings, this also applies to you, so hope you don't care about cleaning up your private NPM registry content.
Getting pretty tired of this. Their open source operation seems to suffer from poor handling of community and technical issues, at least from a high level. Their private registry operation is very lean on features, and also suffers from very confusing limitations. I'm surprised at how long it took there to be read-only API keys. Until last year, you literally had to give your CI keys that could publish to your organization if you wanted access to private packages. And you had to pay for an extra user for the privilege of doing it wrong. It's fixed now but it still blows my mind that it took so long. Aside from faster installation, it's actually a lot better to just use private Git URLs instead of NPM's private offerings.
NPM will never properly take the fall. They will take just enough blame to seem responsible and then shift the majority of the poor decision making onto other actors in the community in their explanations. Third time in recent memory.
Re: Npm operational incident, 6 Jan 2018
#67> who believed that a malicious actor or security breach was to blame This was a security breach. Their anti-spam system should block repos by freezing the module name and returning blank files, not by deleting the entire module and subsequently allowing anyone to upload new modules. This is leftpad all over again. Update: Woah, so I was checking out my old NPM namespaces and apparently someone took control over http…
It's not a "breach" technically. No malicious person caused the packages to be removed by circumventing authentication/authorization systems. It is a security issue though. A bug and serious security issue, yes, but not technically a breach.
Re: Npm operational incident, 6 Jan 2018
#68Earlier quoted context omitted.
To me it's a trust issue. Their dispute policy breaks trust in two ways- 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. What you say is also a problem. The fact that they…
> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. You can as long as your package name isn't trademarked or likely to confuse users installing the package. > 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. I'm actually f…
>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name.
> You can as long as your package name isn't trademarked or likely to confuse users installing the package.
Trademarked where exactly? You know, there's quite a lot of world beside US.
> I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity.
What makes you trust them in this matter? They haven't displayed such behaviour, and their behaviour up until now slightly suggests the opposite.
Re: Npm operational incident, 6 Jan 2018
#69I left an Ethereum related project precisely because of the house of cards feel of it being built off JS and npm modules. They're a great example of how a project can be exploited by a malicious module which could proceed to extract all the tokens.
If my hat is black, I'm writing a daemon which monitors relevant npm modules and uploads subtlely modified versions if and when the possibility to do so occurs again. Particularly, but not only, targeting crypto currencies.
Re: Npm operational incident, 6 Jan 2018
#70Earlier quoted context omitted.
Yeah, about two years ago NPM stole a package name from an existing user and gave it to a company to use. The user then said that if he can't trust NPM to actually treat package naming fairly then he was just going to delete all of his packages[1]. This broke a ton of packages on people (in part due to "left-pad" disappearing), so the community went ahead and registered/uploaded all of the packages to NPM again. Afte…
Just had a quick look - the "kik" package isn't in even use anymore - the whole thing was just drama theatre from by a messaging app I've never heard of. Despite it having 200 million users. Apparently.
> a messaging app I've never heard of. Despite it having 200 million users. Apparently.
Yeah it's tough for me to keep track of which apps are/aren't significant because I'm not in the loop with every community out there.
I'm guessing the users are distributed among small pockets in a network of people who all know each other -- like how in the 1990s there were pockets of "MSN Messenger" and pockets of "Yahoo Instant Messenger" and pockets of "AOL Instant Messenger" users randomly scattered around various schools. OR like how Orkut grew so precipitously in Brazil.
Or it's a generational thing -- I think there is a certain age group of people in the US who used Yik Yak, another who uses tbh and co, and so on.
I would generally trust Facebook employees to tell me which apps are "real" / growing since they have Onavo surveillance and other sources (https://www.wsj.com/articles/facebooks-onavo-gives-social-me...). But aside from those data, I'm not sure how else to keep track of which apps are "real" / big.