Guy brings down thousands of npm builds
-
@cartman82 said:
Personally, I'm still undecided. I wouldn't dismiss the idea of micro-modules out of hand, but those dependency graphs do look ugly. Maybe there's some middle ground there.
The problem isn't the micro-modules, the problem is that the complex graphs of dependencies aren't just “ugly” but rather a specific kind of vulnerability. There's no clear model for ensuring that the micro-modules are done to high standard, or strong commitment by a group of developers to keeping them maintained and available. All it takes is one person getting pissed off for some reason and the whole tower of
implodes.That this was done in JS is almost entirely incidental.
-
@WPT said:
false/false.js at master · ooxi/false
Minimal amd dependency defining a contradiction (always false) - ooxi/false
That reads like a TDWTF meme: "you never know when the value of false will change."
-
@boomzilla Someone should start writing this up as an article.
-
@cartman82 Thats not how it went for me. I expected node to be crap the first time I heard about it, and everything always reinforced it since them.
-
@dkf said:
That this was done in JS is almost entirely incidental.
Sometimes there is a different culture in a language.
I don't know any node programmer, but I can imagine that someone that thinks it's a good idea would also make other bad decisions.
-
@fbmac said:
Sometimes there is a different culture in a language.
Not merely sometimes; it's a common difference.
-
@fbmac There's at least three of us around; one is a mod. And for the record, micromodules can be useful when done right, but they usually aren't. And anything that simply reimplements a basic language feature should die in the fires of Hades.
-
@dkf said:
The problem isn't the micro-modules, the problem is that the complex graphs of dependencies aren't just “ugly” but rather a specific kind of vulnerability. There's no clear model for ensuring that the micro-modules are done to high standard, or strong commitment by a group of developers to keeping them maintained and available. All it takes is one person getting pissed off for some reason and the whole tower of implodes.
Yes but all those arguments can be applied to libraries as well. There's really no difference in the model, other than the scale of things (that is, more people involved).
And for all the crying how this is the collapse of civilization as we know it, you'd think we'd hear more reports about this kind of sabotage. I mean, did anything like that actually happen? Or is it just something a bunch of people suddenly realized COULD happen?
-
@cartman82 said:
Yes but all those arguments can be applied to libraries as well. There's really no difference in the model, other than the scale of things (that is, more people involved).
Scale matters. Scale matters a lot.
If it is a small number of libraries, you can check the governance of each and build a sensible risk register, decide what needs to be mitigated, etc. If there's squillions of weeny little libraries and each has different governance (because each is just a personal publication on somewhere like GitHub) then your chance of being able to even detect that your ass is hanging out in the wind ahead of time is quite limited. While other languages also go for micro-libraries, they tend to aggregate them under common governance structures and have a standard strategy for releasing and maintaining them: that massively mitigates the risks.
-
@dkf said:
If it is a small number of libraries, you can check the governance of each and build a sensible risk register, decide what needs to be mitigated, etc. If there's squillions of weeny little libraries and each has different governance (because each is just a personal publication on somewhere like GitHub) then your chance of being able to even detect that your ass is hanging out in the wind ahead of time is quite limited. While other languages also go for micro-libraries, they tend to aggregate them under common governance structures and have a standard strategy for releasing and maintaining them: that massively mitigates the risks.
An advocate of micro libraries approach (which I'm not, just to point out) would respond that unit tests + the community would provide all the guarantee you need. If millions of users are walking a code path through this micro-library, it must be doing something right.
The simplicity also helps - you can actually run the tests and vet the code yourself, which would be almost impossible with some precompiled framework.
And finally, if the micro-library turns out to be a dud - no big deal. It's super easy to replace it with an alternative, or just write your own. If a large library or framework needs to go away, and your entire project is tied into its conventions... well, you're in deep shit, aren't you?
-
@RaceProUK said:
There's at least three of us around; one is a mod.
accalia and ben deal in other languages too, and they aren't doing anything critical on node afaik. and cartman just said its fun that doesn't count as a recommendation to me.
-
@fbmac And that has to do with you actually knowing Node programmers, why?
-
@cartman82 said:
if the micro-library turns out to be a dud - no big deal. It's super easy to replace it with an alternative, or just write your own
Not if it's a dependency 3 levels down in your 10 level dependency tree. You'd have to modify everything that depends on that micro-libray, either to rewrite them as well or modify their dependencies to your new one
-
@cartman82 said:
If a large library or framework needs to go away, and your entire project is tied into its conventions... well, you're in deep shit, aren't you?
Yes, but if you manage your risks that badly then it's your own damn fault. There's many ways to manage risks (some more blakey-approved than others) but just burying your head in the sand and hoping is about as dumb as it gets on that front.
-
@fbmac said:
cartman just said its fun that doesn't count as a recommendation to me.
I did? News to me.
-
@cartman82 said:
I mean, did anything like that actually happen?
if we're talking about server libraries, I think it happened several times. I didn't care enough to remember details, but even heartbleed was accused of being intentional and disguised as a bug.
-
@cartman82 said:
@fbmac said:
cartman just said its fun that doesn't count as a recommendation to me.
I did? News to me.
then I don't remember who said that
-
@fbmac Probably shoulder aliens. Sounds like the kind of thing they'd say
-
@Yamikuronue said:
@lucas1 Yeah, my workplace bought it, but hasn't got the servers set up yet. So we have the worst of both worlds right now.
Maybe they need someone who is qualified to build it. Like the build script options in TFS. HOW MANY PEOPLE ARE USING THAT FUTURE?
-
@lucas1 said:
Why should a machine config be in a code repo?
Nothing that is machine specific should be in the repo if at all possible.
I am agreeing with this statement.
-
Let's see if we have the :worlds_smallest_violin: emoji for npmjs. Since, y'know:
-
@Yamikuronue should we start using downvotes outside of the dislike thread? Can we make downvotes spam notifications so the user actually gets the point?
-
@WPT I really hate people who bucket everybody together. "Are we forgetting how to program?"
No. I don't use that shit. I look down on "developers" who do. They produce crap like Discourse. Fuck you.
-
@cartman82 said:
uld respond that unit tests + the community
A unit test wouldn't prevent the micro-library from opening a backdoor into your app or otherwise becoming malware.
As for "the community", how many members of "the community" do you think actually audited the code for "PadLeft"? I'm actually genuinely curious about this. I would assume anybody so lazy to search a package repo for "PadLeft" would be WAY too lazy to actually open it up and read the code.
-
@blakeyrat Why are you guys checking in your Nuget packages? We just pull them down on our build servers during CI builds. We also host our own Artifactory server that can speak Maven and Nuget. Probably other repo types too.
-
@mikehurley Because we don't have our own "artifactory" server, whatever that is, I suppose.
Look, it's a small company, ok? We do the revenue-generating shit first. We only got a dev ops person late last year, and they've been spending most of their time in a valiant struggle to make sense of our build processes.
Why do we check the NuGet packages in? So we can build our product even if the Internet gets blown-up by aliens. Any snapshot of it. It's all on our company's servers and our company's backups.
-
@blakeyrat said:
A unit test wouldn't prevent the micro-library from opening a backdoor into your app or otherwise becoming malware.
Few things would, whether in a micro-module or a full fledged library.
@blakeyrat said:
As for "the community", how many members of "the community" do you think actually audited the code for "PadLeft"? I'm actually genuinely curious about this. I would assume anybody so lazy to search a package repo for "PadLeft" would be WAY too lazy to actually open it up and read the code.
Hmm, hard to say. I occasionally dig into the source code of modules I
require, but that's usually because I want to use the advanced features, or because something is breaking. I'd probably never glance at something as simple as padLeft.
-
@cartman82 said:
I'd probably never glance at something as simple as padLeft.
EXACTLY.
Because you're so lazy you included that library instead of writing for 5 lines of code yourself. You're FAR too lazy to do a code-review.
-
@blakeyrat said:
Because we don't have our own "artifactory" server, whatever that is, I suppose.
It's a service that holds builds of packages. It can hold both release builds and checkpoint/nightly builds. It doesn't do the building; it holds the results. AIUI, it's pretty easy to set up, though I've not done that myself (a coworker set up ours). And because your organisation has its own instance that caches all the packages its software depends on, the risks are sensibly managed; everything is in your hands.
It's a useful tool.
-
@dkf I didn't ask.
-
-
Apparently @blakeyrat missed the day in elementary school when they were teaching inferring understanding when reading by looking at surrounding context. I had intended to indicate what artifactory was by mentioning it handles Maven (java) and Nuget (.net) repos.
What's nice about a server like this (there are ones I assume for npm, linux rpm/deb, and others) is you can pull an external dependency like these wacky npm mini-modules and then still have them available if they go missing from the upstream originating server. Our build process always pulls from our internal artifactory server and it handles pulling Maven and Nuget packages from those traditional sources.
-
@mikehurley said:
I had intended to indicate what artifactory was by mentioning it handles Maven (java) and Nuget (.net) repos.
Actually I did figure that out from context. One more reason why dkf's post was a waste of time and effort.
-
@mikehurley I kind of wish we had an Artifactory server where I work so I didn't have to run my own kinda/sorta server to host the Oracle Java DB drivers (because Oracle won't ever put them on Maven Central).
Maybe I should get together with .NET / JS side of the dev team and see if they'd go for that.
(I say .NET / JS because our .NET web stuff seems to be migrating to AngularJS with WebAPI services to fetch DB data.)
-
@powerlord We do that exactly with the managed Oracle .net driver for similar reasons. If cost is a concern, I think there are many free versions of these different repo servers. Artifactory is nice because it comes with baked in support for many repo types and I think it has plugins for many others. Maybe there's a limited, but good enough, free version of Artifactory?
-
@cartman82 I was crying tears of schadenfreude joy over this. This amuses me greatly. You mean, the magpies legoing together a ton of libraries they DO NOT understand as they cargo cult their way to "frontend developer" success, had one of their magic legos taken away from them, and the whole thing broke? I am shocked, SHOCKED I tell you!
-
@RaceProUK said:
@cartman82 That's what happens when idiots get a hold of shiny.
Of course, there's one user here who'll use this as an excuse to hate on OSS, even though this has nothing at all to do with the fact that this is OSS; the same could so easily happen with closed-source.
Wait ... what? o_O
I mean ... listen, I am not a hardcore OSS or CSS person one way or another. Both ways have their benefits. But ... HOW THE HELL could this happen in closed source? Closed source, by definition of it being closed source, could not be pulling in a 3rd party library to the build. If they were, then at the very least it would be partially open source, depending on the licensing terms of the OSS library being pulled in. =_=E_DOES_NOT_COMPUTE
Filed Under: What, too nit picky?
-
@anonymous234 said:
@Onyx This whole thread is convincing me that Javascript is a much worse language than PHP.
-
@anonymous234 said:
@cartman82 said:
But that's a problem with any external code. Ultimately, you have to trust the vendor wont try to screw you.
The issue here is that in other languages you generally use less than a dozen "big" libraries, whereas Javascript people seem to be willing to use 200 tiny external modules from random people. This greatly multiplies the chances of getting screwed up by any of them.
(In that particular case though, the library could run with reduced permissions, which would be nice)
THIS! SO MUCH THIS!
-
@Vaire said:
@RaceProUK said:
@cartman82 That's what happens when idiots get a hold of shiny.
Of course, there's one user here who'll use this as an excuse to hate on OSS, even though this has nothing at all to do with the fact that this is OSS; the same could so easily happen with closed-source.
Wait ... what? o_O
I mean ... listen, I am not a hardcore OSS or CSS person one way or another. Both ways have their benefits. But ... HOW THE HELL could this happen in closed source? Closed source, by definition of it being closed source, could not be pulling in a 3rd party library to the build. If they were, then at the very least it would be partially open source, depending on the licensing terms of the OSS library being pulled in. =_=E_DOES_NOT_COMPUTE
Filed Under: What, too nit picky?
Permissive licenses like the MIT License allow open source libraries to be used in completely closed source projects.
The library will still be open source, but the project using it won't be.
-
@Arantor said:
And fuck me, y'all complain about PHP. We have a (shitty) package manager but pretty much any PHP dev can master
if ($x > 0)and we have sane string padding built in. And our packages are usually less fucktarded.Who's TRWTF NOW HUH?!?!?!?!
We didn't even overload
+to mean add or concatenate!You tell 'em Arantor! >_</*
-
@Vaire Few ways something like this could happen in CSS:
First off, CSS projects are found in dependency managers like NuGet. They can still enforce their license to use their DLL by having some level of DRM (usually in the form of including a license file or certificate that you point to in your config)... so, if they stop supporting the software, and remove the dependency from the manager, you're SOL unless you have local copies.
If it's *aaS they could simply pull the plug on the entire system. CSS can also use other CSS dependencies which become unusable after those other dependencies close shop or decide they don't want to have a partnership or be a vendor anymore.
Plus, CSS could simply stop support for the product, leaving you having to choose something else, since you wouldn't risk leaving unsupported software used in production, right?
So, yeah, whether you're choosing CSS or OSS dependencies, you should always have a local dependency repo and never rely on any external sources for any of your stuff, if at all possible (barring of course stuff requiring web API's and the like).
-
@cartman82 said:
the author is strongly against this trend of "micro-libraries", consisting of just one simple function.
This is just .... incredibly amusing for me. Thanks for making my morning :D
I am enjoying watching the JS world burn. Where's my damn fiddle?
-
@lucas1 said:
People keep saying JS is crap, but it is the one of the few languages I enjoy programming in. The others are Python, PHP and Closure.
I do a lot of C# and tbh it is probably one of the best languages out there but it is soo boring to program.
You know what I am NOT looking for in the language I use to do my job, which requires I do it RIGHT the first time, because if I screw up, the company loses a LOT of money, and I probably get fired and/or sued? A language that is "exciting."
You know what I DO look for to do my job RIGHT the first time, reliably, every time, without forcing me to constantly stay up to date with the latest nonsense from Hipster central? A "boring" language that is stable, reliable, PREDICTABLE, easy to use, that I already have memorized, and I can use it to QUICKLY, and ACCURATELY do my job. So I spend time on CODING solutions to problems, and not being "excited" by the language I am using.
But, I dunno, maybe that's just me. Am I focusing on the wrong part of my job? Should I be constantly changing languages, and continuing the neverending quest to find the next best library/framework/magic lego that will do my job for me and I never have to write code again? Is the language the destination, and not the method of the journey? Have I been wrong all this time?
I am so confused now
-
-
@lucas1 Your projects must be pretty boring if the language part is what's exciting for you.
-
As per usual with el reg the gold is in the comments.
The more you know!
-
@Choonster I mean ... OK, sure? But we are skating on the edge of what the actual definition of closed source is. And every enterprise setup I have worked for that wanted everything closed source, wanted everything developed in-house as well, and audited the code to ensure compliance with that so ... yeaaaah ..... o_O
-
@The_Quiet_One You're not wrong ... but I maintain that any CSS project done that way is slapping the shit out of the definition of what it means to be "CLOSED" source.
-
Them's Good Broth! | Let's Paint the Town... Er...
