Npm operational incident, 6 Jan 2018
blog.npmjs.org
Npm operational incident, 6 Jan 2018
1–10 of 197 posts
Re: Npm operational incident, 6 Jan 2018
#2As others have said countless times on the original thread: new packages from different users should never have been allowed to replace the missing packages.
Even if a package is removed as malware, a user should never unexpectedly download the work of a totally new author that they haven't vetted.
Some of the protections should be done on the user side, but that's no reason for NPM to have dangerous policies.
Re: Npm operational incident, 6 Jan 2018
#3They need to pull their socks up and start signing these packages
Re: Npm operational incident, 6 Jan 2018
#4"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
Re: Npm operational incident, 6 Jan 2018
#5"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
What is your home address and phone number?
Re: Npm operational incident, 6 Jan 2018
#6"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
What is your home address and phone number?
[deleted]
Re: Npm operational incident, 6 Jan 2018
#7"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
It's standard operating procedure to elide the details of one's security posture.
Would you expect Google's security team to provide a detailed list of all of the security procedures in place to prevent access to their network?
Rejecting "security through obscurity" just means you shouldn't rely on obscurity alone. Obscurity + good security > good security alone, since it increases the threshold of time and ability that any attacker would need to bring to an attack.
Re: Npm operational incident, 6 Jan 2018
#8> no malicious actors were involved in yesterday’s incident, and the security of npm users’ accounts and the integrity of these 106 packages were never jeopardized
Maybe not in the incident itself, but the sheer fact that many of the packages were replaced by other people constitutes a jeopardization of applications that depend on NPM. The only reason why some big package didn't get replaced with code that exfiltrated data from production or subtly backdoored it is sheer luck.
Re: Npm operational incident, 6 Jan 2018
#9"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
Sure, this is "security by obscurity" in the purest sense, but its pretty common throughout the industry to not publicly disclose one's security process. Those details make it easier to circumvent.
Re: Npm operational incident, 6 Jan 2018
#10I'm curious of the manual review process. Is this synchronous, i.e. immediately when publishing a package? Or is it after the fact, where suspicious code code have already been distributed? There are plenty UX trade-offs in either direction, of course.