11–20 of 197 posts
"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.
They need to pull their socks up and start signing these packages
Can't understand why it hasn't happened still.
That is such a bad response to this.
The problem isn't that "well-meaning members of the community" decided to upload packages. The problem is that when their system decides that a package shouldn't be up it completely removes the package, as if it never existed, and allows the namespace to be reused immediately. Those "well-meaning members" should not even be able to hijack packages this way, as it means the people who aren't "well-meaning" can also do it.
What should happen is that they block downloads of the package while they investigate. That way people who attempt to download the packages get a meaningful error and people are unable to hijack the package name.
"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 t…
After left-pad I think we'd all like to see a strong, well documented methodology to keep things like this from happening again. The broad strokes can't be any more clever than what the rest of us would expect, so why not at least provide a basic idea of what you're doing and then we could trust the system a bit more.
EDIT: or better yet, don’t allow people to download the update, just keep users on the old, ostensibly safe version until everything gets sorted?
> Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or security breach was to blame and independently attempted to publish their own replacements for these packages. Ensuring the integrity of the affected packages required additional steps and time. That is such a bad response to this. The problem isn't that "well-meaning members of the communi…
Hasn't this been an ongoing issue with npm since pretty much its inception? I remember reading articles about this vulnerability and the hijacking of packages that were taken down temporarily years ago.
How has this not been dealt with systematically yet?
> 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 exfiltrate…
https://news.ycombinator.com/item?id=16087079
this is probably a good indication of how a much more serious security event would be treated by the organization.. just sayin