The latest npm security kerfuffle
-
-
@Unperverted-Vixen said in The latest npm security kerfuffle:
@Lorne-Kates Support needs to be implemented in the HTTP server first.
Just have github check if the commit was made using IP packets with that evil bit set. If yes, add warning. If no, everything should be fine, right?
-
@cvi said in The latest npm security kerfuffle:
@Unperverted-Vixen said in The latest npm security kerfuffle:
@Lorne-Kates Support needs to be implemented in the HTTP server first.
Just have github check if the commit was made using IP packets with that evil bit set. If yes, add warning. If no, everything should be fine, right?
Well, depends on whether you need to do probabilistic correction per the RFC, but yeah, pretty much.
-
@dkf said in The latest npm security kerfuffle:
@Carnage said in The latest npm security kerfuffle:
The only reason JS even still exists is that it was the only choice for years and years
… for deploying into users' browsers. Why people started writing server software or general desktop software in it, I really don't know.
When all you have is a footgun, everything looks like a foot.
-
@dkf said in The latest npm security kerfuffle:
@Carnage said in The latest npm security kerfuffle:
The only reason JS even still exists is that it was the only choice for years and years
… for deploying into users' browsers. Why people started writing server software or general desktop software in it, I really don't know.
For general desktop applications it is obvious: each platform has its own UI framework, but all of them have a web browser and on all of them some can be integrated into a package as a web view. Which makes it a practically portable UI framework. With the advantage of having a large supply of code monkeys that can write for it.
For server it makes much less sense, because all the async code needed there for filesystem access is a major pain in the arse.
-
@dkf said in The latest npm security kerfuffle:
@Gąska said in The latest npm security kerfuffle:
Name it like "People Whose Code You Should Never Ever Trust", and include their Github usernames, full names (if available), and all the projects they're in charge of, and their dependents. I wonder how big the outrage would be.
Nice idea. It'd end up in court.
What should end up in a court is the people who pulled this off. I actually believe the correct solution is just to make sure the maintainers of these packages put some real identity behind them that they can't easily change when they do something evil, and preferably can be traced by police if it is really bad (e.g. while I don't think I have my physical address associated with my online identity, police could probably get my phone number from Google or other place where it is registered as authentication second factor, and then get my identity from the operator). It's not like most people have a good reason to publish open-source code anonymously. Some may (e.g. when publishing exploit demonstrations), but it does not apply to this kind of common helper libraries. And I am not saying you shouldn't be able to publish code anonymously at all—it just wouldn't be trusted.
See, it even used to be common. Major open-source projects (e.g. Linux) have their releases signed by the maintainer using PGP. But lately people just put junk in npm, or present it on github, with no verification at all.
-
@Bulb Sounds like a good case for an npm module or seventeen to me. The funny thing is, I have lurked a long time on node mailing lists and complaints about npm are about as old as npm. A billion ways to prettify your source code and severe limitations in the basic tooling to maintain yon stack of rotting White Castle sliders.
-
@Gribnit It's not ranting against npm. At least not specifically. Because it is not specific to npm in any way.
-
@Bulb said in The latest npm security kerfuffle:
@Gribnit It's not ranting against npm. At least not specifically. Because it is not specific to npm in any way.
Aw, I wish it was. I wonder if CPAN has signing.
-
@Gribnit said in The latest npm security kerfuffle:
I wonder if CPAN has signing.
Doesn't look like it, but it does have an associated identity for each release. Apparently, you have to log into a system (PAUSE) in order to do the release process and there's some (probably basic!) checking before issuing an account there. I guess it comes down to this: do you need just the identity of the publisher, or do you need their real name too? I've always found with software that I only really need the former; YMMV.
Also, they probably don't screw things up by leaving a project in a half-transferred state.
-
@dkf Well, you have to log into npm too. But these accounts – all of them, npm, cpan, pypi, rubygems, github etc. – are a dime an infinity. You can always create a new one for whatever no good you are up to and leave very little trace behind.
I would also note that while Google Play developer accounts are not free, and payments generally do leave some useable trail for enforcement to follow, I never heard Google would file complaints when they do discover malicious applications uploaded in the Android store, so nobody is hunting publishers of those down either.