Welcome friends, I'm Jared, and you are listening to The Change Log, where each week we interview the hackers, the leaders, and the innovators of the software world. As the creator and longtime maintainer of ES Lint, Nicholas Zakis is well positioned to criticize GitHub's recent response to NPM's insecurity. He found the response insufficient and has other ideas on how GitHub could secure NPM better. On this episode, Nicholas details his ideas, paints a bleak picture of NPM alternatives like JSR, and shares our frustration that such a critical piece of internet infrastructure feels neglected.
But first, a big thank you to our partners at fly.io, the platform for devs who just want to ship, build fast, run any code fearlessly at fly.io. Okay, Nicholas Zakis, talk to NPM on The Change Log, let's do it. This is the year we almost break the database. Let me explain.
Where do agents actually store their stuff? They've got vectors, relational data, conversational history, embeddings, and they're hammering the database at speeds that humans just never have done before. And most teams are duct-taping together a Postgres instance, a vector database, maybe Elasticsearch for Search. It's a mess.
Well, our friends at TigerData looked at this and said, what if the database just understood agents? That's Agent at Postgres. It's Postgres built specifically for AI agents, and it combines three things that usually require three separate systems, native, model-context protocol servers, MCP, hybrid search, and zero copy forks. The MCP integration is the clever bit your agents can actually talk directly to the database.
They can create data, introspect schemas, execute SQL without you writing fragile blue code. The database essentially becomes a tool your agent can wield safely. Then there's hybrid search. TigerData merged a vector similar to search with good old keyword search into a SQL query.
No separate vector database, no Elasticsearch cluster, semantic and keyword search in one transaction. One engine. Okay. My favorite feature, the forks.
Agents can spawn sub-second zero copy database clones for isolated testing. This is not a database that can destroy, it's a fork, it's a copy off of your main production database if you so choose. We're talking a one terabyte database, fort, and under one second, your agent can run destructive experiments in a sandbox without touching production, and you only pay for the data that actually changes. It works.
All your agent data, vectors, relational tables, time series metrics, conversational history lives in one queryable engine. It's the elegant simplification that makes you wonder why we've been doing it the hard way for so long. So if you're building with AI agents and you're tired of managing a zoo of data systems, check out our friends at TigerData at TigerData.com. They've got a free trial and a CLI with an MCP server.
You can download the story experimenting right now. One, TigerData.com. Well, friends, we're here with our new friend and good friend, Nicholas Azekis, known by many things created as lint, author of many books, and a person with angst, you know, who doesn't have a little angst out there. Yeah, we all get some angst.
But this one recently against the GitHubs, stewardship, and securing of NPMs, I know a lot of people have an issue with it. So when I saw this post, I read this post, I get you on the podcast. Here you are. Welcome to the show.
Yeah. Thanks for having me. I think thanks for having me back. I think I've been here before.
Just party. You know what we were talking about yesterday? I know I'm online. I feel like I've met him before, but I didn't actually go back in our catalog and look you up.
So I would only assume it was either an old, old episode of the changelog or a not-quise old episode of dance party. But for sure, you've been on network. Yes. Definitely.
I wasn't on the podcast. That's why I said that. And welcome to the podcast. Yeah.
Welcome to the both of us and the three of us. What is the best way to open this can of worms? I mean, we can go the end and work way back. How should we begin this discussion on securing NPM and what GitHub can do about it?
Yeah. That's a good question. I think it might help to talk a little bit about 2025 and what was going on with NPM and then we can jump off from there. So in September alone, there were 500 packages that were compromised on NPM, never mind the rest of the year, just 500 packages in that one month.
And those attacks didn't really look any different than any of the attacks that we've seen before, which is basically like somebody steals some credentials one way or another. They start publishing compromised packages and they usually add like a pre-install or post-install script that executes the malicious code. And then they publish that to the registry and they just wait for people to download it. And then as it downloads and that pre-install or post-install script runs, that's when the trouble starts happening.
And we've seen a bunch of different iterations of this. Sometimes it's just like looking to steal crypto. Other times it's looking for secrets. I mean, that was one of the big things last year was running TruffleHog to discover secrets on the user's machine and then using those secrets to propagate itself.
And I think that we're pretty lucky so far that the damage caused by these packages has been pretty minimal. One person lost like $500 in crypto or something like that. But it was getting to the point where to me it's looking a lot like somebody or a bunch of somebody's are trying to figure out how to get packages into NPM that will get distributed as quickly as possible to do something that is a lot more damaging than what we've seen so far. And that was basically what led me to stop and think about what's actually going on with NPM, what could change and I think more like what could the next attack look like if things don't change.
And from a maintainer's perspective as well, right, because you're looking at it from the lens of somebody who's maintaining highly used open source projects over the course of forever, right? Yeah. So like ESLint, which I help maintain over 200 million downloads a month. And we have had from time to time these very mysterious pull requests that show up where all it is is somebody like changing a dependency with no description or anything.
And when we ask them, Hey, what are you trying to do on this? What's the point of this pull request? We get nothing. It doesn't happen a lot, but it's happened frequently enough that it's always felt to me like a penetration test to see how easy it would be to land a pull request on ESLint because it's downloaded so much.
And knowing that it's going to go out basically immediately to all kinds of CI systems and personal laptops and what have you, we're always very, very careful about changing dependencies and thinking about which dependencies we want to add into the ESLint package JSON file. Because there is a big responsibility when you have a package that's downloaded so frequently it might so many different people. And it just kept coming back to like no matter what I'm doing, no matter what security practices we're putting into place, it seems like there's always some way for somebody to get in and cause trouble. And we did have, I want to say maybe nine or 10 years ago, we did actually have a compromised package get into ESLint, but it was one of our own packages.
And it was kind of traditional, somebody had reused their credentials on another site that site had been hacked, and they ended up having their NPM credentials stolen as a result. And then they could publish ESLint packages using that. After that we changed so that nobody's individual NPM account has published rights for ESLint packages. But we're still in this situation where we use so many dependencies and not to mention like dependencies of dependencies that it's almost impossible to protect our users if some malicious package gets in the dependency tree somehow.
So GitHub did respond to this or they have done some changes. I don't know if it was a response or the timing was correct that it seemed like it was a response. We had for us, we could do down the show last year talking about just the onslaught and some of the details of those hacks and it was fun to hear about how the hackers are either hacking. At the time I think GitHub had announced some changes but hadn't actually done them yet or rolled them out.
You addressed some of those from a maintainer perspective. It seems like your read on the GitHub changes to the way it works is more maintainer burden and perhaps too tightly scoped, is that fair to say or one, give your impressions of some of the things they're doing to react to this because they're in the position of the platform to be the most influential reactor or are they the ones that have to basically make some changes, right? Yeah, so my read on the changes that they made was that it was pushing more responsibility onto maintainers. So eliminating the kind of older style tokens, I can understand, you know, fine-grained tokens are way more secure, like that makes sense.
But then limiting the lifetime of those tokens, they went through a bunch of iterations. I think they finally landed on like 90 days. That alone, like if you're doing token based publishing, like now you need to remember to update your tokens every 90 days, or you have to implement some sort of automation to do it for you on top of whatever else you're already doing. And the response to that was, well, you know, if you use trusted publishing, the open ID connect feature that they have in GitHub actions, then you don't need to actually store a token anymore.
It's generated on the fly and you can just publish using that. And that sounds great. Like it's a good solution to not just have a token laying around somebody. Yeah.
It's not a lock-in thing though, right? It's not a lock-in thing. That's great if you're on GitHub or GitLab also supports it, but what if you're not on either of those platforms? Right.
Like not every company in the world that's publishing NPM packages is using GitHub. You know, they might have private repositories, they might be publishing directly from their internal repositories and not having stuff out on GitHub or GitLab. And then the other problem is that there's no two-factor authentication for trusted publishing. And as a result, the OpenJS Foundation even came out and just said for critical packages, we recommend that you don't use trusted publishing because if somebody is able to get access to your GitHub repo, all of a sudden they're going to be able to publish your packages and you won't know until it's too late.
So trusted publishing is the beginning of a good solution. It's just not all the way there yet. Can you break that down? What exactly is trusted publishing?
Yeah. So you explain that. So trusted publishing is basically you go into NPM and for your individual package, you say, I want to enable trusted publishing from this source code repository specifically. And then this workflow specifically, the exact name of the file.
And when you enable that, then you can upload your GitHub Actions workflow file into your repository and set the permissions for ID token. And then GitHub Actions will, when it runs that workflow, will request a token on your behalf from NPM and then bring it back in and use it just for as long as the workflow is running and then that token is no longer useful anymore. So basically, it's on demand one time use tokens for NPM. Is that used by a lot of maintainers?
Is it well, it's not fully implemented though, right? Well, so it's partially implemented now without de facto authentication. That's the big thing that's missing. And there are a lot of people who are moving to it specifically because they don't want to have to deal with rotating tokens every 90 days.
That's just a lot of work. And especially if you consider, like, I think for me, I might be a maintainer for something like 100 packages, maybe more than that, I'm not sure. Some of them are pretty small and inconsequential, but sometimes those are the ones that make their way into larger dependency trees and it can get in trouble with those. And so the initial reaction from myself and a lot of maintainers, we read the post about the changes, was like, how are we going to scale this?
How am I going to update all of these packages to do all of this? And there was no batch operation to update a bunch of packages. You have to go in individually to each package and go through multiple two-factor authentication approvals as well, just to do it for one package. And I've been told that there's going to be a batching tool coming out.
I'm still not there yet. But in the meantime, they still rolled out these changes fairly quickly to people to kind of force changing over to the granular tokens with shorter TTLs and the trusted publishing. And so there were just a lot of maintainers that were like, you're just throwing a ton of work onto our plate and the tools to help us do that work aren't even there yet. Can you walk through why trusted publishing is trusted?
What makes that trusted? With this part of the workflow, the single workflow YAML file and actions, what makes that trusted? Yeah. So it's trusted because it is known ahead of time that that is the one location that you can publish from.
Like any other workflow that you add, you can ask to get the ID token and publish to NPM. But that workflow is untrusted. So it can't actually use a token to publish to NPM. So it ends up being just a form of validation between that workflow and NPM to validate that it is allowed to publish that package.
So the, I guess, pre-ceremony, the PETA factor of this pre-ceremony is what makes it more trustable because you're going to go through the emotions of actually setting it up, naming it, defining it, putting the repo. There's some sort of song in between GitHub and NPM to trust that singular YAML file. And that's the one that's trusted. That workflow.
Yeah. Which again, like, is actually a nice system. If you're on GitHub or GitLab and you don't worry too much about needing to factor authentication, it's a decent system. But to me, and it's still GitHub and NPM saying, okay, maintainers, you need to do more to protect everybody from you being a victim of your credentials being stolen.
Which is why, in my post, I use the analogy of credit cards where, like, there's a lot of fraud using credit cards, and that's why credit card companies keep introducing new ways of validating that you're the authorized user of the card that you're using, whether that be the CBC number on the back, or the chip that is in the card, or in Europe needing to add a pin in addition to your chip, they do all of that stuff to hopefully prevent people from using your credit card number without your permission. Which is great. Like, we should do that. There needs to be some way to help consumers of credit cards users of NPM to protect themselves from having their information stolen.
But credit cards don't just stop there, like, they're also doing anomaly detection with each transaction that's coming through to figure out, like, does that look like something you would normally do? And so if you've ever been traveling or just make a big purchase, you may get a text message that says, hey, we just got this charge for this amount at this location. Was this you? And if you say, yes, it's as great, you know, go right ahead, if it says no, then it'll block the transaction and they start the fraud investigation process.
And in that way, they know that, hey, nobody's going to be 100% at protecting their information for being stolen for a variety of reasons. So let's not just rely on that. Let's also do some analysis and see if we can figure out if something bad is going on before it gets too far down the line. And that's where I think that NPM has been kind of missing some clear actions that they could be taking to protect us better.
What makes you think they're not doing that already? And just doing it poorly? Well, from what I can tell, they have some ability to do this. Because they said in one of their blog posts that, like, once they identified the pattern of the credential stealing attack, then they were preventing new packages from being uploading that had that same kind of signature.
So they do have that capability to do like a real-time analysis of packages as they are being uploaded, but it just doesn't appear that they're doing much else with that capability just because of how frequent the attacks have been. Like if it was like, oh, once a year, it's like, well, maybe during those 11 months, you know, they were kind of tweaking some knobs and twisting some things and trying to figure stuff out. And it was like every single month, another attack, almost doing the exact same thing. And then later them coming in and saying, like, here's what we did to clean up the mess.
And I just feel like the technology is there to prevent the mess before it happens. And for whatever reason, I'm guessing, probably lack of resourcing, that it's just not getting done because I have talked with folks who work on NPM, like, they're really dedicated, they're really smart. And the sense that I always get is just like, there's a really big backlog, there's not enough people to work on it. So the stuff just kind of sits until there's an emergency.
And my read on the response last year, and I have no inside knowledge of this at all. This is just my interpretation of what I was seeing was that the things that they were rolling out were things that were probably already on the roadmap and just needed a little push. And this was the push of like, you know, running it up the chain and just saying, hey, these like three things we've been trying to get through for the past nine months, like this would actually really help with these attacks. So can we prioritize and resource these?
And that's why we got those. Just my theory, but it just, it seems like, and I gave this feedback directly to them too, that I just feel like all of this is attacking the problem from the wrong end at this point. Well, friends, I don't know about you, but something bothers me about getting up actions. I love the fact that it's there.
I love the fact that it's so ubiquitous. I love the fact that agents that do my coding for me believe that my CI, CD workflow begins with drafting, Tom will file for get up actions. That's great. It's all great.
Until yes, until your builds start moving like molasses, get up actions is slow. It's just the way it is. That's how it works. I'm sorry.
Because our friends at NameSpace, they fix that. Yes, we use NameSpace.so to do all of our builds so much faster. NameSpace is like get up actions, but faster and like way faster. It caches everything smartly.
It caches your dependencies, your Docker layers, your build artifacts, so your CI can run super fast. You get sort of feedback loops, happy developers because we love our time, and you get fewer. I'll be back after this coffee and my build finishes. So that's, that's not cool.
The best part is it's drop in. It works right alongside your existing get up actions with almost zero config. It's a one line change. So you can just make your builds, you can let your team, and you can finally stop pretending that build time is focus time.
It's not. Learn more, go to namespace.so, that's namespace.so, just like it sounds like it said. Go there, check them out. We use them.
We love them. And you should too. Namespace.so. Well, there's one big difference between the credit card companies and GitHub slash Microsoft.
Otherwise, I agree with you entirely with the methodology of like, you know, inference and fraud detection and like analysis, be more proactive than reactive, et cetera, is that the credit card companies get paid for transaction, you know? So like, there's money directly tied to that process. And what is NPM to GitHub to Microsoft, you know, it's, it seems like it was a fig leaf at a time when NPM needed one, you know, to continue to exist. And so acquisition, but where is the revenue coming from?
Like what, what's it doing for GitHub? What's it doing for Microsoft? And so I understand all that we tend to get cynical over time. I understand why it's hard to actually allocate more resources because it's like, this is not their main thing.
It's not even, they're like seventh main thing. It's just like a thing that they have that's hanging off another thing that they bought. Like they bought the GitHub and they got the NPM and they're like, well, I don't know you know, like I understand it's the rest of it's the stuff and what do they lose? When we have these, they lose a little bit of goodwill, right?
A little brand tarnishment, but not much, not losing enough trust that they're not making money on transactions where it's like credit card company. You got trust that credit card company in order to actually use their card. And for Microsoft, you know, if there's another NPM security breach, I'm sure they don't like it. Nobody likes it, but it's not revenue generated.
And so how do you actually get that done? And it's probably explaining some of the, what you're sensing is the lack of resource and it's probably the reason why. I'm not sure if you ever, if we ever bridge that gap, you know, like how is it ever going to be worth it for them? Yeah.
And I think that's exactly the problem is that the NPM registry is a huge cost sink. Yes. Like it is widely expensive to run requires a ton of bandwidth. All kinds of companies are relying on it every day running in their CI.
And when the NPM company, NPM Inc, was running, like they needed to sell because they couldn't afford to run the registry anymore. Right. And it really was GitHub being like, hey, you know, we are a haven for JavaScript developers. They didn't have to do that.
They needed it because at the time, I think it was just a few months earlier, they had actually announced their own NPM compatible registry built into GitHub, which is still there, but doesn't seem like people use all that much except maybe as like private repos inside of companies. So they didn't really need to buy NPM. I don't know who would have bought it otherwise. But at the same time, it's like, you know, if you adopt a dog, you should take care of the dog.
We all agree on that. Like you can't just adopt it. Take care of the dog, GitHub. Well, I mean, I think they would argue, well, we are taking care of it.
We have a staff of free and their entire point. We're paying. I'm just paying out that number. But you know, like, well, there's three people full-timers.
We can calculate that out. We're talking a million dollars a year that we're just keeping the dog alive, you know, whatever the number is. Yeah. Absolutely.
And it's not going to get better than that. I'm not going to go to two million. There's no reason to as long as the dog is still alive. Now maybe it gets so bad that the dog eventually dies.
Right. Well, so my counter to this argument, which I completely understand is that all it takes is one attack that costs people millions of dollars in some way or costs a company millions of dollars before this becomes not just a like, oh, yeah, hey, we're keeping it alive. But, you know, like there's a responsibility because if you don't take care of that dog, he's going to start biting everybody in the neighborhood. And then you're looking at not just like, oh, this is, you know, it tarnishes our reputation.
Like it doesn't look good. Now you're looking at like significant financial repercussions. And you know, I'm sure there's stuff in the terms of service that says that they can't be sued. But that's just going to ask like, you actually go after them legally for negligence or something.
You know, there still might be some big company out there that's like, hey, you know what, we're just going to try it because we're a multi-billion dollar company and we have the money to throw at lawyers. And why not? We'll give it a shot and see what happens. But this has been my concern for several years now is that when you treat these attacks as a nuisance, you leave the door open for more sophisticated attacks that are going to cause more trouble in the future.
And I don't know what those look like. I mean, I could imagine another type of situation where we had the crypto stealing package, like, what if that wasn't targeting a crypto website? Like, what if that was targeting like a major banking website or a major stock exchange website? What would happen in that situation?
And with those people who lost money through an NPM package that was compromised, would they even understand what was going on? Or would it just be like, oh, by virtue of being on the laptop? I just got screwed. I feel like that bigger attack is coming if something major doesn't change.
It's likely, right? I mean, it's likely that a large player in some game with deep implications is using dependencies from NPM. It's like a 99% likelihood that someone's using it somewhere on the front end and it's attacked vector. You may already be exploited, right?
Yeah. You may, you know, these little pokes may actually be just a precursor. Nicholas, do you have any insight into how staffed NPM is given your presence in the community ? I don't.
I've only had direct contact with one person and I don't feel at liberty to discuss what we've talked about, but I don't have an idea of how big the team is. My only sense is that it's fairly small. I would say, demystify the black box of staffing, just so the community knows, is it being staffed? Is it understaffed?
Is it, you know, like, I don't know. I mean, if we're relying on this registry ecosystem, at least be clear on what's not clear with that part of it. Like, tell us. It's, I think last year, I opened up an issue on NPM and maybe by the end of the year, it got a response, like not even a like, oh, this is a good idea.
This is a bad idea. I'm just like, oh, hey, that's interesting. And that was a good indicator to me that was probably not resourced appropriately. I mean, especially when like PMPM came out after one of the attacks, I was like, okay, we're not going to let people install any package that's like newer than seven days old or something.
And I hope that that would prevent people from like rapidly downloading compromised packages before they could be caught and removed. And that PMPM moved faster than NPM, I think was a bit of a wake-up call for me. Now, they're doing it on the client side. So, you know, how big of an effect does that have?
I would guess, like, not huge, but they were trying to do something that they seemed like might help and was within their power to do so, which I applaud them for. And like with NPM, it just felt a little like, okay, these were some stuff that we were planning on doing anyway, and we're just going to roll those out. And yeah, we'll see what happens. Let me ask a question that's maybe been asked, but maybe not directly like this.
Like, is it still pertinent to even use NPM, given the fact that she put an issue out there and did that long to get a response, or just the seemingly lack of speed or initiative on the nuances? Like, I don't think security is a nuance, but you'd mention that there are nuisance, which is a close N word to that. You know, what's going on? I mean, should we keep using NPM?
Are there alternatives? Should we create an alternative? If it was a possibility, what would that organization look like? Do you have any insights there?
Yeah. So I think the short answer is that like the inertia behind NPM is so great that it's very difficult to extricate ourselves from it at this point, like any, I mean, any JavaScript package that you want to install, you look at the readme, it says install from NPM, like people don't even know what else to do besides go to NPM to look for these packages. And, you know, Dino started an alternative package manager called JSR, which I actually had high hopes for because I think that they put the type of thought into security, instability, and stuff like that up front that NPM has kind of been adding on as it goes, just like right from the start, like not allowing package names, squatting, reserving certain package scopes that could be confusing to people, like when I went to go sign up for DSR and I tried to grab the ESLint scope, because my initial reaction was like, oh God, like here's another place that I need to grab all the usernames on, and ESLint had been reserved. Like you couldn't actually go on the website and just say like, okay, I want the ESLint scope, you actually had to apply for it and prove that like you're the right person to be handling that scope.
And they approved me really quickly because they knew who I was and that I was involved with ESLint. So I was able to get that. They had trusted publishing right from the start or else you have to use two-factor authentication to publish locally. They, you know, no pre-install or post-install scripts.
There's just a lot that was really good about JSR and it basically suffered the same fate as NPM, just not a much faster timeline, which was basically, you know, there was a lot of interest early on, a lot of activity, a lot of iteration, like I was filing issues on the JSR. GitHub repo, they were getting answered like some time within hours and things just getting fixed and pushed out. But eventually that timeline started expanding to the point where I wasn't getting any responses anymore. Even to bug reports, there was, I mean, I was finally able to get one response when a new version of Dino was pushed out and that broke the command line, the JSR command line tool.
It was finally able to get a response from them to get that fixed fairly quickly. They had announced that it was going to be an open governance registry for JavaScript and they had formed a committee that had people from like NPM and Dino and I think Open JSR foundation and Volts and that just kind of went nowhere. There hasn't been any updates since then. Like JSR is still running, but as far as I can tell, it's mostly an abandoned project at this point and there's just, you know, some of the Dino diehards, like really like to use it, but it doesn't seem like it's ever going to be a real competition for NPM registry.
What was the downside to pre and post install hooks? I get what they do, but what was the downside you said there's none on JSR? Is that something you agree with? Is there a way to do it safely with your thoughts?
So pre and install and post install scripts on NPM are designed to let you run additional commands after install in order for a package to work and, you know, NPM is based on a package manager at Yahoo where I worked for five years called Yinst and Yinst was the way that all of the machines were built inside of YAM and these pre and install and post install scripts could run in Yinst to help you set things up after you got resources installed and that turned out to be pretty helpful to be able to set up machines. That was copied over into NPM with the same idea. The difference though is that Yinst was an internal system, so there was implicit trust with all of the packages that were published in Yinst. For NPM being a public system, you don't have that implicit trust and I think that this is probably something Isaac would have rethought when he was designing the system, knowing what he knows now, but the NPM ecosystem kind of became dependent on those scripts because of the ability to publish native NPM packages that were actually compiled like C, C++ packages where you can't publish the compiled artifact itself because it has to be compiled individually for each machine and so these post install scripts are what allow these native modules to be used and installed on any machine because it just downloads a source code and then on your machine it compiles it into the form that can be used and then you can just run it and there are a lot of packages that use that now because every once in a while somebody will say well we'll just ban pre-install and post install packages, but if you do that you kill off a non-trivial portion of packages on NPM that people are relying on and the other thing about that is you can actually say NPM install dash dash ignore scripts and it won't run any of those scripts and that's a great solution unless you end up with one of those packages in your dependency tree that needs to be compiled and you might not even be aware of it and so just disabling that or just always saying like don't run those scripts that also has the effect of potentially breaking people's experiences in ways that they didn't anticipate and if you've ever had any trouble with a deep dependency that needs to be compiled that wasn't compiling it is really difficult to debug and so I think any package manager that would start from scratch or any registry that would start from scratch now would be wise to not even have this concept of pre-install and post install scripts and just say we're not dealing with compiled packages at all which is what JSR does but if you want to enable compiled packages it's kind of the necessary evil you have to accept.
Do you mean the post install or pre-install is gonna install a compiled binary and that's the threat is that compiled and you can't see into it? No so the threat is that the pre-install and post install can run anything? Yeah exactly. It might not compile anything and this is what happened last year was these packages would download and install TruffleHog which is a secret scanner and just execute it and find all the secrets and tokens on your computer when you downloaded it.
It's one of those situations that like Dino was trying to prevent with its permission system like okay you have an NPM package like should it be able to call back out to the internet for some reason by default? Like that kind of seems like a bad idea and so the permission system in Dino was built so that any time a package was trying to do something that was unanticipated reach out to the network read something on the file system you would have to opt into that behavior and I know there's been some experiments with that on NPM. I don't think that those permissions actually apply to pre and post install scripts I remember correctly but that is something that they could look at as well. I'm just like okay maybe pre-install post install scripts are not allowed to just willingly like go out to the internet maybe they need to get like opt-in permission from the user in order to do that first.
I imagine that would be a little bit more complicated than I'm making it sound but it's another option around those. I mean my preferred option which I talked about in the post is just say hey you know if a package previously did not have a pre-install or a post-install script and then it adds one don't allow it to be a patch or a minor version upgrade like force it to be a major version upgrade because for most people that will not be installed automatically as like the minor patch versions are so if you just said like oh hold on for this like 1.x branch of this package you never had a post-install script before and now you do sorry you got to bump that to 2.0.0 before we're going to publish it for you and I think that that alone would slow down attackers tremendously because people just not automatically be downloading those packages anymore and hopefully someone like maybe of socket or maybe it's NPM themselves will then have the time to identify that as malicious and get it pulled down before it is downloaded millions of times. That's awesome. I suggest like if it's I like your idea of course is why I think a major version bump is it's gonna slow it down it's not gonna prevent publishing it still allows movement so if it's your package you just don't move along but anyone else has to sort of adopt that based upon their December but what if you were constantly scanning any package or project that had a pre or post install script anytime those were added or included and forever more that one gets special attention special scrutiny on that script if you're basically forming something if you're doing something the theory is if you're making a network call if you're doing an install of any sort it's looked at and has to be scanned and verified like a security verification so that at least you have some check and balance.
Yeah I like that idea a lot I think that for too long we've just been saying like oh you know they go and add a post-install script and gosh like that's terrible but yeah it's great if it's done wisely yeah I like the idea you know a lot but there are all kinds of things that I think can be done with these packages to just make sure that they're safe and yeah I love that idea of just providing extra scrutiny to those I mean it could be the case that like you even need like a waiting period if you're changing or adding you know post-install scripts like and this is the thing that I found a bit frustrating is I feel like there are some low hanging fruit options that are out there that would actually not be very resource intensive to implement on NPM which is why my suggestion of just requiring a major version bump was one of the things that I put out there like I don't think it's super complicated to implement but like let's just start doing something during the published process instead of just relying on people discovering it after something has been published and then downloaded a bunch of times. You can even introduce when you got verified publishing you want to verify publishers you know if you're going to give somebody the peanut factor to you know make a token you know renewable in some way shape or form or just in time credential that makes sense for the for the maintainer why not only give certain types of ability like the pre and post-install for example if it's such a powerful thing anyone who wants to use that in addition to that verify all maintainers or the organization or the maintainer the kind of core maintainer and it has some sort of connection to one real person inside of that package project whatever and if you can't if you can't do that then I'm sorry you don't get that very special ability for this trusted network or should be trusted network it takes people though right but a lot of economy a lot of that really you can do a lot with that process now I think that the the resources for that would probably be fairly high and probably more than it could get in a short term let me say that I think if you if you're GitHub though right if this is GitHub which it is then you have GitHub at your at your ready so for those publishers one easy way you can do it or one easier way as you can leverage the already need for securing GitHub which is that project or that person has to use GitHub auth so you have a one person or somebody there like you can leverage at least get a bot and all the security put behind GitHub itself to have one verified member or at least one member in the party gotcha yeah yeah interesting I think potentially an easier solution which is a little bit heavy-handed as you could just say okay all packages that have pre and post install scripts right now you can keep doing it anybody else you don't get to do it we're basically cutting that off now and saying that you know we're grandfathering in all those old packages so they will continue to work but new packages sorry you're out of luck we're just not going to do it for you you need to figure out a different way to to distribute stuff and you can just tell your users a couple steps a four and a half to write I mean yeah yeah that's that's the easiest probably you know method that you could do is just to your users you got to do something for and just an after to make this work right yeah it's unfortunate yeah just go ahead and write your own shell script you know or you know here's a shell script download it and you need to run this and then after that it's fine right it's yeah but you know again I feel like there are some lightweight solutions that could be done instead of putting more responsibility on maintainers every time there's an attack well friends this episode was brought to you by Squarespace I love Squarespace I'm a user Squarespace and Squarespace is an awesome almond platform where you can stand up a professional site offer paid services get paid the whole thing without running a single line of code or debugging CSS they've even got blueprint AI now which takes basic info about what you're building and generates a fully custom site with actual design recommendations not a template you have to fight with but a starting point that already looks like you thought about how to look and for the data nerds out there I know you that's me too builds in analytics are cool see your traffic see your revenue see your bookings see your sales figure out where to focus all from one single dashboard no third party apps no gpr headaches just there for you and whether you're launching a site project selling a course or finally replacing that under construction web page you've been kicking around Squarespace handles the website part so you can focus on the thing you actually want to build and the content you want to create so head to squarespace.com slash changelow for a free trial and when you're ready to launch use our offer code changelow to save 10% off your first purchase of your website or a domain once again squarespace.com I'm saddened by your report about JSR I had I hopes for it to seem like like you said it off to a good start and I wonder what happened there like what why but what about vault you mentioned vault that's another one that's been up and coming from a long time you know JS ecosystem people Darcy Clark and friends and then backed by a lot of people who have been around the ecosystem forever and have you know benefited and had issues with MPM over the years is vault been manifest is a thing is still becoming a thing is a viable option because eventually we can't make it up do anything and so they're not going to do anything we can continue to tell them they should try to convince them but having some other alternative which I was hoping JSR would be calm would be at least somewhere you could put your efforts into and say let's all do this instead and it would be grassroots and it would be a lot of work and I understand there's billions of things being downloaded every month off of MPM but if the package maintainers had somewhere to point people and say you know what for new versions of the s-lint you got to go here you know put it in your post install scripts this is an old version of the s-lint for the new version I'm only publishing on this other platform for you know go remember blog for the reasons and you can get like the top 100 packages for maintainers to do that you could probably make a dent but we have to have somewhere to go and if JSR is not going to be it is vaulted alternative what do you know about that one yeah so vault as far as I know was not in the business of providing a registry it was more around tooling around MPM like a new client that does fancier stuff or yeah basically new client does fancier stuff more secure etc. I haven't seen anything notable come out of that in fact again I'm starting to think this might be me you know I opened I was trying out one of the vault tools and I went and I found a problem and I opened an issue on the GitHub repo again it just sat there for months just no response at all until very very late I mean again maybe by the end of the year somebody was like oh this is fixed in the latest version just I don't know what's happening over there and it just I don't think that JavaScript registries are good business fundamentally and I think that you know MPM Inc figured that out and glad for them that they're able to get out and get the registry into a place where it would at least be up and running I feel like JSR basically the same thing happened where JSR was being funded primarily through Dino even though they wanted to make it more of a community thing but like fundamentally like they came up with it they were running it you know they had it on their infrastructure but you know they are a startup like they need to figure out ways to make money and JSR was just a way to spend money I mean it's nice it's a nice gift to the ecosystem but they still need to figure out a way to turn a profit to pay back investors so the chances I think that JSR is going to grow up into something else is probably pretty slim and like you I was pretty excited about it I think they got a lot of stuff right but one of the challenges of again like having a competitor to MPM is like number one you can't actually do quote unquote binaries like ES Lynch on JSR and you can't just say like JSR install ES Lynch and then just run ES Lynch like it doesn't work that way and then two any alternative to NPM needs to be compatible with NPM like because unless you're able to use all of the packages just in that new registry you're going to have to mix and match between NPM and that new registry sure and that's also something that JSR just did not get right if you try to use JSR packages in with NPM packages in a package that you want to publish just straight up doesn't work you have because we tried to do this with one of our yesland packages because the nice thing about JSR is Dino published a bunch of like standard library type packages on there and they're really good and so we wanted to use one in one of our packages and it ended up being such a pain that we just copied the source code from the JSR package into our repo in order so we could package it and publish it up onto NPM so like that story was just not there at all it was okay if you were just building up an application that you were not going to be publishing to NPM you're just going to be deploying like that worked okay but then going and publishing that back to NPM just did not work at all so we're stuck yeah i don't know you got an idea all right let's hear it well what if and i know bunn is not a registry but what if bunn is very fast what if by the sheer weight of enthropic behind bunn now saw this as a blind spot in an opportunity they obviously invested in bunn anyways i'm not sure the implications behind it there's a lot of speculation of course but with the sheer weight they have with just the weight their deep coffers their money their etc what if they can recreate what NPM is they're already NPM compatible what if they could redo but better with maybe AI native provenance etc anomaly detection taker advice nickel is it's like what if what if they took it on and they said you know what we're gonna do this could they could they sway all the maintainers away from NPM by the sheer weight of who they are right now yeah i don't think so okay and part of the reason is it seems like a lot of developers are very skeptical of AI companies and providing data that can be used to train AI's like there's there was a lot in 2025 with people being like oh look at this like terms of service they've now included that your data can be used to train AI's and i feel like if enthropic were to start a registry that would be like day one people being like wait a second am i just feeding enthropic like my copyrighted material so it can continue to train clod i think that would be a major barrier to that i think that's a fair point yeah what about they just what about the users you know all i need to do is convince clod to use their registry and then the rest of us are just writing we're just writing clods back at its point i'm really yeah well i i think it would be interesting if if they started having clod said like no you got to use the enthropic official registry but i can also imagine you know similar upset developers user back latch against clod now yeah totally yeah and also just you know from an operational standpoint i don't know that enthropic has the operational experience to be able to keep a high volume registry up and running at this point i mean that's something that i mean there were really smart people explain that what does it take to do that i would be lying if i said i knew exactly okay so you're speculating but well no because i know like i knew a bunch of people who started npm and could work together at yahoo really really smart people coming from yahoo that had really really good operational systems and being able to pull people you know from that ecosystem in to help build up npm i mean people forget now but like the npm registry used to go down a lot in the early days and even after they got their funding like it took a while before it reached stability and there's you know a lot of again i'm not going to lie and say i know how to keep a registry online myself because i've always been more of a front end developer than a back end developer but just you know off the top of my head how many like read replicas that you need and where you need them what sort of traffic are you getting from publishing and how frequently and like how do you cache effectively to make sure that ci systems are up to date and also not unstable there's a lot that goes into managing the registry i would say you know it's probably kind of similar to like running youtube in a way because youtube before they got bought by google like this was also a problem of just like managing the scale that was going on and part of my google was an ideal destination for youtube was they had the infrastructure and the operational knowledge in order to keep that site up and running even with all of the traffic and all the bandwidth that it eats up every day and again if you look at cloud like how frequently does cloud go down because they run into like bandwidth issues like it still is more frequently than you'd like to admit they're getting better but like it still happens so you're you're not down with you don't think the world will be down with anthropic slash button registry npm compatible anomaly detection ai native etc etc i don't personally i think that for a registry to have a chance to compete with npm i think it has to come from a company or person starting a company that is already trusted by the community and that's why i thought jsr had a real shot because coming out of dino coming from ryan doll already had like a lot of trust in the community and you know always presenting himself as like wanting to do the right thing for the javascript ecosystem i thought jsr really had that shot and to see it kind of fade away has been really disappointing well i think jsr was open source and supposed to be it is like you said governed open so there's opportunity for somebody else to pick up a band to run with it if there's no movement from the dino team any further if we look around all these different package ecosystems like how do they all do it or is npm at such scale that it doesn't really matter how ruby gems does it how purl continues to do and purl has like cpan which is mirrored around the world on different servers rust i think is rust foundation but it's like way smaller in terms of how many crates there are compared to npm packages um java i think java isn't made and run by like a single entity that sells commercial services are these all just like the scale isn't the same so it doesn't really matter how they're doing it successfully or what are your thoughts on it yeah i think that's exactly it i think it's a scaling problem um because like there are package managers around before npm existed and ruby gems so crates came around afterwards it was kind of inspired by npm but like they don't have anywhere near the scale no but what about pie pie for instance like python has huge scale yeah i don't know that much about the python ecosystem i mean neither knows the python's foundation python what foundation yeah it seems to me these other languages usually follow a predictable pattern of at some point some developer was like we need a package manager they made one people started using it they started a foundation or non-profit or something that just kind of gets donations to keep it up and running yeah and i think that that's where like the java script story kind of in sideways i was like you know it was started as you know a side project by isak schluder and trying to find a home for that he started npm a for-profit business and i think that that was probably the point at which the divergence from other languages hurt the long-term plan for the registry like because again like once you become a startup you take vc you're on the hook for making money you're figuring out how um and if you can't figure out how they want you to sell to try to get as much money as possible get it back like you know maybe in some ideal world um the mpm registry would have ended up instead of at a for-profit company in you know at the time the jquari foundation which went on to become the openjs foundation right i think that an ideal world that is probably what would have happened although i don't know you know eslent is part of the openjs foundation so i do have some insight into how the foundation works and i also don't know how the foundation would have been able to afford to keep the registry running probably the same way any foundation does is just donations they have to just beat the streets for bigger donations from funded companies that really want java script to win like google for instance when the web wins google wins at least historically and so they would be probably a sponsor and it would just be like let's just break even and continue break even and pay these bandwidth and cost and aws cost or whatever it takes to run the thing and that's how they're all running but like you said the scale is bigger than the model i did confirm python software foundation i'm not sure what i was talking about with python science foundation but uh the psf has oversight and donations sponsorships aws google data dog provide ten that fastly provides ten thousand dollars per month hosting that's just reading this from a lm look up so fact check that but it makes sense that like that's that's the way it's working it probably doesn't always work great there's some sure there's push and pull on the direction and there's white drama around all the things but like that's kind of how community run important things are maintained and continue but they don't have the profit motive behind them and so i think you're right on track that it was like turning it into a business it's probably a long-term death now and here we are and had it gone to the open js foundation versus two gib perhaps that would have killed it off for good or perhaps it would have given it a better chance i don't know obviously we can't do the uh parallel histories but i think it's not and it's in okay place it continues to exist it operates pretty well but it's so important now that the stakes have been you know ratcheted up on security side and there are more things that need to be done and there's really not much of incentive besides like you said some pending nuclear moment of terrible press and like user backlash and all these things a huge security breach perhaps legal action that would actually motivate them to really go after it or it's the cool factor man it's the cool factor of implementing anomaly detection and like these verified users and like that would be that'd be a fun job you know to to save potential i mean it's not safe because i mean you're going to keep using it but you're kind of using it but grudgingly you're not exactly thrilled that your mpm is not as secure as it's scared yeah you know you got it's wrong the options like the road to there is paying with potholes and thieves and you know people with weapons and stuff trying to take me out it's like that's like a road that's an exaggeration of course but uh you know you've only got the one road to go down and not much choice and even if there was choice based on you've said necklace is that even with that choice there might not be a mass exodus away from mpm to something else just because of its gravity i mean the package is behind mpm is three point i mean if this math is correct as of late 2005 3.1 million packages as according to wikipedia so wikipedia is better i mean that's a lot of packages that's a lot of people to move i mean you don't want to swap out your just-in-time credentials let alone move to something else with maybe different tooling maybe better tooling who knows yeah they have a good reason yeah and security rarely moves people very fast or far it might this community though i mean if there's a lot of fear of its uncertainty because of security in particular it seems like the profit incentive could be there and when you see companies like vaults and companies like socket springing up basically because of these problems right like it seems like there's some possibility there of um you know just saying like look you know there are companies that are willing to pay for these types of services like maybe we can offer those services and use that to offset some of the cost of implementing these changes on mpm just say hey if you want like the fastest notification of potential security threats or what have you like sign up for the service we're going to use that money funnel it into the mpm team and you know start funding it that way i just i feel like there's a lack of creativity in the solutions at this point because there's this whole world of possibilities out there um to be able to turn it from turn mpm from just like a cost sink um into something that could maybe break even or you know maybe at least just not be the albatross that you're dealing with constantly um like i think it's wishful thinking at this point that github would willingly spin off mpm into a foundation i mean they could certainly do it like it it wouldn't hurt them financially to just say hey you know what we want to start a foundation or give it to the openjs foundation as part of that we've come to an agreement with you know google and meta and whoever else that like we're going to jointly fund registry operations um by donations to the openjs foundation openjs foundation will be in charge of like hiring engineers to work on it based on that like maybe that's an offering for them uh i don't know if it'd be open to that but so yeah there's just there's a lot more options out there than i think are being discussed or even considered at this point for sure for sure let me take this uh as an opportunity to invite anybody who has insight into the underpinnings the behind the scenes of npm uh open invite come on let's talk about whatever you want to talk about let's even spitball some ideas live here in the podcast maybe we even spin up a cloud code session and whip up a new feature for you know what i'm trying to say but we'll get some we'll get some action here i'm gonna say get nicolas hired on there to come in and write the ship you know bring him in he's got good ideas would you do that nicolas hey happy to if i can help there you go i'm i'm i'm here willing to help yeah what is your day what is your day look like what do you have to well i'm at the moment independent software engineer so i just take on you know contracting consulting work i work on yes lint um as i'm able and i do uh coaching for software engineers just helping people when they kind of reach those upper levels of the ic track you know tech leads staff engineer principal engineer um which i did you know in a former life um just helping people kind of navigate companies and leadership and communication and politics and all the things is that one on one is a small group how does that work out yeah it's one on one um just do remote zoom calls and yeah just talk about you know the challenges people are having and give some tools and suggestions of how to deal with situations that might come up because uh you know anybody who became a tech lead they'll know that basically when you become a tech lead they say hey congratulations or tech lead go do tech leading stuff and uh don't really tell you what that entails so that's when i come in and just help people figure out how to work effectively in those roles and you know manager manager and um get stuff done how likely is that person is already employed and attacked lead and they're just like hey can uh not like at this role can i use some discretionary spending for some leveling up yeah that's a hundred percent of the people that i work with are people who are already employed at a company um a lot of times the company will even pay for the coaching um through their professional development expensive and uh you know sometimes the managers reach out to me and just say hey um i have this person that i'm working with um that i really like to get them some coaching either because they just don't have more senior people at the company i work with a lot of startups that just don't have those really senior people that can help mentor people um or sometimes the really senior people are just too busy don't actually have the time to sit down and do that sort of coaching and mentoring um sometimes it's the engineers themselves who reach out and i always encourage them to talk to the manager to see if they have professional development funding that might be able to pay for it too because you know if the company is going to benefit from you becoming a better employee then um seems only fair that they should pay for it too how can they reach out to you what's the best way to say hey Nicholas i i need some help yep so you can drop by my website it's a human who codes dot com slash coaching and that'll give you all the information about like what i do how it works you can see some testimonials uh and there's a button for you to apply and fill out a form that just tells me about you and i can figure out if it would be a good fit because i i'm one of those people who i want to make sure i can help you with the situation that you're dealing with and if not then i'll try to help you find somebody who can and how should i get home contact you to come help fix home game security the same way slash coaching go emails the folks at github um i'm in a slack with them already so they can reach out at any time dm near you all right get up the the tables are turned back to you come on the pod let's talk about mpm or reach out to Nicholas whichever you prefer that's your next move you go let's make it happen Nicholas anything else on your mind anything else you want to talk about it could be on topic off topic regarding what's going on in software world or anything before we let you go yeah i just uh just wanted to say about ai um i don't think it's hype i still see people out there saying oh it's just a hype train it's not like personally myself i have seen like a 10x productivity improvement in the amount of code that i can now generate versus writing and especially when you're like jumping around from project to project um saving me a ton of time like there's it'll be really difficult for me to be productive writing code for yes lint right now but uh with ai like hey you know i know what i need to get done and i can describe it fairly quickly and just kind of let ai go off and do it so if you're one of the stragglers out there who's still not embracing ai uh in your day to day like 2026 is the year you gotta start doing it now 2026 is the year there you go how about resources for maintainers who have to maintain mpm modules packages whatever do you have any resources for them any any advice for them maybe they're not paying attention as much as they should the details where could they go to become leveled up yeah that is a good question but i don't know i have an answer to let's see that resource exists i feel like that's just like a natural thing too because i mean mpm i don't even i don't know i don't know against docs but i would imagine like that's the need there but they're already not doing other things as well as they could so let's just do those things better yeah but the docs can be you know maintainers out there who've been down the road have the bloody knuckles and the scars to prove it and the backward-facing desire for everyone else following them or following mpm or the ecosystem to be leveled up in some way shape or form i'd love to see that happen so if you're out there doing something like that you've got that resource or that's your next big ai generated things i mean that really could be something you can generate over a weekend you can invent a hundred new docs that were never there with a few prompts and uh your buddy your new buddy Ralph and clod just circling around whatever get it done if i'm remembering correctly i think openjs foundation might have put out something along these lines just not a hundred percent sure all right cool well nicholas thank you for coming on the pod and sharing your time again with us back here on the changelog and thank you so much for your angst and sharing that and uh just pushing the needle on what could be a secure mpm coming to you sometimes soon thanks for having me all right then that's your changelog interview for this week thanks for riding along with us what do you think about mpm is it being neglected is there a way to save it are we being overly dramatic let us know in the comments links in the show notes thanks again to our partners at fly.io to breakmaster cylinder for the beats and to you for listening we appreciate you more than you know that's it this one's done but on friday come on back we're talking clogbot slash multbot personal software and the death of software as a service talk to you then