The really scary thing is probably the malicious npm dependencies. If I think about the projects at work with and all the different packages and the hundreds of dependencies no one knows. And it's probably even worse in really big companies like Microsoft or Facebook, they probably got thousands across their products. I hope for us all that they scan them very regularly.
This is why my work will only use enterprise supported distros like RHEL. We don't have the manpower to stay on top of every single package update to ensure they're absolutely safe.
What does RHEL have to do about NPM package dependencies in software projects? A server or a developer’s desktop machine using RHEL would still be pulling the same packages from NPM as another other distro…unless I’m missing something?
You're right, I'm a dumb dumb and misread the whole thing as RPM, whoops!
No worries! I thought maybe RHEL had like their own NPM repo or something (I think NixOS has python packages, so that kind of thing isn’t unheard of), but then that didn’t really make sense so I wanted to make sure I was understanding.
There goes the argument of non technical users falling for scams.
The tables have turned!
I do wonder if this would be negated by containered applications
Oo that's a sneaky one, very impressive.
Examine dependencies and installation scripts. Very recently published, net-new packages, or scripts or dependencies that make network connections during installation should receive extra scrutiny.
I'm a little surprised npm doesn't already do this and give you a big blinking warning in the install process about it.
How do Linux distro's deal with this? I feel like however that's done, I'd like node packages to work in a similar way - "package distro's". You could have rolling-release, long-term service w/security patches, an application and verification process for being included in a distro, etc.
It wouldn't eliminate all problems, of course, but could help with several methods of attack, and also help focus communities and reduce duplication of effort.
Linux distros typically use a key signing party to help shore up their security concerns, but I wonder how github would go about implementing something like that.
Man that’s clever
[DO NOT DEVELOP MY APP]
The really scary thing is probably the malicious npm dependencies. If I think about the projects at work with and all the different packages and the hundreds of dependencies no one knows. And it's probably even worse in really big companies like Microsoft or Facebook, they probably got thousands across their products. I hope for us all that they scan them very regularly.
This is why my work will only use enterprise supported distros like RHEL. We don't have the manpower to stay on top of every single package update to ensure they're absolutely safe.
What does RHEL have to do about NPM package dependencies in software projects? A server or a developer’s desktop machine using RHEL would still be pulling the same packages from NPM as another other distro…unless I’m missing something?
You're right, I'm a dumb dumb and misread the whole thing as RPM, whoops!
No worries! I thought maybe RHEL had like their own NPM repo or something (I think NixOS has python packages, so that kind of thing isn’t unheard of), but then that didn’t really make sense so I wanted to make sure I was understanding.
There goes the argument of non technical users falling for scams. The tables have turned!
I do wonder if this would be negated by containered applications
Oo that's a sneaky one, very impressive.
I'm a little surprised npm doesn't already do this and give you a big blinking warning in the install process about it.
How do Linux distro's deal with this? I feel like however that's done, I'd like node packages to work in a similar way - "package distro's". You could have rolling-release, long-term service w/security patches, an application and verification process for being included in a distro, etc.
It wouldn't eliminate all problems, of course, but could help with several methods of attack, and also help focus communities and reduce duplication of effort.
Linux distros typically use a key signing party to help shore up their security concerns, but I wonder how github would go about implementing something like that.