 All right, so I'm going to kick off this session on the unexpected demise of open source libraries, software, and well, a bunch of other things that you'll learn in a few minutes. So I wanted to kick this off, this session of like telling you and you know, sharing, as for me, why the open source software movement has fundamentally changed my life. As a teenager, I guess like a bunch of people here in this room, I was able to connect using open source software, the movement itself, everything with like minded individuals, people who are thinking like me, we're sharing code, we're building things, we're able to experiment and have access to a safe environment, safe playground of our own. It enabled me to learn, improve upon my code and others and learn from them. And it gave me access to software that I would otherwise not have access to, essentially providing me for opportunities for growth, as well as opportunities to make an impact in the world itself. Now, I bet you're probably asking and trying to reminisce, you know, what was your first open source project? Were you involved in one? And so here's mine. This is, you know, the why I'm saying this. My open source project was back then 2007. Started this called Daleradios, which was, this is like my pillar project that says the everything of basically PHP, spaghetti code together with HTML, a bunch of security vulnerabilities in it and, you know, a lot of fun as a teenager, not a teenager at this point, but doing all of this in the open. This is a software that basically manages radio servers, right? It's a web application thing. And it was a very niche thing. It was like for Wi-Fi hotspot, you know, back then when the internet wasn't as available as it is today, it allowed those hotspot Wi-Fi systems to basically make a living through essentially being able to provide this Wi-Fi service with, you know, printing a username and password and making this possible. It grew to over half a million downloads from straight, this is straight from SourceForge, so it doesn't count any clones of like, you know, subversion back then or Git today and so on. So people literally went on to SourceForge, downloaded the project and created a business or something of a Wi-Fi hotspot with it. For me, the impact that I was showing, was witnessing back then was at one point I was thinking, hey, I'll go to LinkedIn and see, you know, who uses this software. And it was amazing essentially to see people who had this as part of their curriculum, right? Like as part of their experience. Like they are now Delaradius operators. So this is how I made my, I would say impact. But as you can see, we're talking about the unexpected demise of open source software, right? This is mine. This is my example. No different. I have stopped maintaining it after about five or six years. I'm no longer actively maintaining it. And you could see that obviously the SourceForge is also like less popular to these days. But it is essentially kind of unmaintained, deprecated. It leaves off today of Git and GitHub. But it's not as maintained as it is. So how does that affect and impact every one of us? My name is Irantal. Thank you for coming to my session. I'm a developer advocate at SNCC where we build developer tooling for developers, help them stay secure, all of those kind of things. I'm very active in open source related movements, anything on the JavaScript ecosystem like the Node.js, OpenJS Foundation, OWASP and things like that. Very happy to collaborate and share ideas after this talk if you have anything about this that you're interested of. But truly why we're here is and how this is connected to licensing is an interesting perspective of, you know, how open source kind of maybe, I think, perhaps just my opinion, but developed and like why it became so popular. From 2015, this is usually people in this conference show an up to the right growth of supply chain security vulnerabilities. Well, this is not that one, but it does show you an example of the affiliation of specific licenses in open source. And maybe perhaps an interesting insight here is the fact that the MIT license, which is known to be very permissive license, is catching up a bunch of those projects. That bunch is specifically 45% of them. In a more recent study by Tidely, which is another company working with open source maintainers and developers and, you know, doing all of that, they actually cite that about 90% of projects with known licenses just because there are some projects out there in libraries that do not have a license attached to them. That's a red flag. But aside from that, the fact that we know that 90% of software libraries, again, with known licenses are using permissive licenses is also interesting. This is, for example, on NPM, 1.8 million packages out of 2.2 million of them basically telling you, hey, you can take my license and do whatever you want with it. So are we taking open source for granted? See a few faces here. Usually people nod and agree and sigh because we all kind of feel maybe we have. But really what happens when we do is kind of the rigs that we're taking and what's going on, what will be there tomorrow. And so this is where I'm showing you a few stories that I have on this topic. One is the story of Left Pad. If you're within the JavaScript ecosystem, you might have heard about it maybe in the news. I'll go into why it happened briefly, but then we can move to other stories from different ecosystems as well. For example, this story of Left Pad, that's the name of library that explains of how legal actions taken by a commercial body towards one open source developer resulted in breaking thousands of projects and builds and CIs across the ecosystem, such as Node.js and Babel and very, very popular projects. So how does that happen? Left Pad is, by the way, a very small library, footprint of 11 lines of code, depending on which version you look at, but that's essentially the gist of it. So let's talk about the typical software development team that some people might have in their heads when they're thinking about their team building products or whatever. So you think that the traditional first party code kind of dev team is they write, they sit, write code, or they don't magically write code. They need that extra magic that's called coffee. It goes in. They drink it. Magically, code goes out. So they do this all the day. Developers are like weird people, but we love them. We're part of them. We are developers ourselves, so we kind of understand how this works. They also do some other things to build their code. They're not always inventing it from scratch. That would be kind of like missing the point a lot. They are using a lot of open source software that other developers have built, so they do not need to build it themselves, which so far I probably haven't told you anything new. But perhaps an interesting insight is who are the maintainers behind those packages? What happens if they disappear tomorrow? What happens if their projects disappear tomorrow? Here's one story. This developer is part of your development team if you're building JavaScript projects. Do you know Azir? Let's get to meet Azir. He is part of your development team. Let's see why. Azir maintains a package called KIKNPM package, one of those two million packages on the ecosystem. He's the maintainer of other packages, but at the moment, who cares? Just KIK is the story here. But apparently, he attracted the attention of some corporate lawyers. Interesting. Why? Well, I didn't notice. I bet Azir didn't notice either. But apparently, KIK is also the name of some popular instant messaging app that has gone commercial or whatever. NPM has stepped in as the registry of the governing body or so of all of those millions of packages and stepped in and said, hey, would you want to rename your package so this other bigger commercial body can take the name of a brand that they use and so on. Azir didn't want to do that and he essentially refused to relinquish any control of the package or change the name. And so getting concerned of lawsuits and all of those legal actions that some companies have to their disposals versus us as maintainers who are essentially doing this as non-commercial work. And NPM has kind of like failed to kind of bridge what would be an okay remediation or mitigation of the story. What happened is they have forcibly removed control of KIK and pushed out to that commercial body. And as an act of protest, Azir said, I am going to remove all of my modules from NPM and I do not want to push any open source code to this registry anymore. Went on and did that. He also maintains 250 other node modules as we've just said before. One of those is apparently Left Pad. It's 11 lines of code but it gets 2.5 million downloads and it broke thousands of builds and CI ecosystems the moment this was gone. You can imagine your team's push code. CI kicks in, builds the software, downloads from NPM, all of those NPM packages. One does not exist anymore. 404. Everything breaks. Everyone rushed to figure out what to do with this. This has some specific security interesting concerns. For example, what happened if that Left Pad name doesn't exist anymore? Could I as a malicious actor now quickly publish a malicious package and add it and now it's published and those take it? So this brought a bunch of new learnings on how the ecosystem and the registry actually needs to cope with cases like this. For us as maybe corporates or like people who depend on this from the consumer side of things, there are other learnings that we could take in. One of them was the fact that many companies, many teams and organizations who build upon open source code were not actually using one of those ways of having an internal private proxy and internal registry for them not just to have their own IP of private packages that they maintain but also to essentially have a bridge, have kind of like this caching layer which seems very, very a mundane thing and an obvious thing to do when you build systems but how about for your artifacts of open source packages? So Verdaccio is one of them. Essentially what it does, you would want to be able to run an NPM install with one of the package managers. This shows PNPM as an example. It goes to the NPM registry and fetches library and give it to you. So far so good but there's no caching here. So Verdaccio came into the picture. It's an open source project. It exists also for quite a while before the story and so on. It's, you know, pluggable. It's open source. It has zero dependencies. The idea is that you use this in order to essentially be able to cache dependencies. And so then your workflow is a bit different. Your team, whichever NPM package manager they use, they essentially move it to Verdaccio as a regular proxy. It goes out to the upstream registries, which of those that you maintain or configure and brings it back and you can spin it off as an NPM package as a standalone CLI or as a Docker image, if that's more easier for you to maintain. So one of the learnings of organizations was essentially to adopt a tool like Verdaccio for those dev terms. So that's how Left Pad got into the incident whole of fame kind of story. But we're moving on to another story. This one is a story of how you would essentially perhaps remove yourself from the open source ecosystem in order to make the world a better place. Let me ask you here. How many people here who would have been running successful open source projects, hundreds of contributions, thousands of dependent projects, right? Millions of downloads. It's super successful, but you would feel very much obligated to just stop, just remove it, stop maintaining it, make it unavailable so that your carbon footprint on the earth would essentially get lowered, would perhaps be non-existent. This is the story of that kind of maintainer. He was brave enough to kind of like put his access on the sidelines for perhaps a greener planet earth. Meet François. Back in 2011, he created the Faker Library on the PHP ecosystem. Essentially, the Faker Library as its name is a useful tool for developers because when we need to create tests, we need to use some kind of maybe random data. For example, if we're needing values like first name, last name, countries, whatever to fill a form in a database, seeding data, whatever, we might need a way to generate this automatically. Therefore, this package is called Faker, very genius here. He created this project back then. It of course grew in success. It became kind of like a very popular project on the PHP ecosystem. It got specific even extensions to Python and other kind of like SDKs in other languages, JavaScript included which we'll talk about next. It had a bunch of like contributions in terms of the data that it actually faked. It grew in support of what it could fake. It could fake phone numbers and hello messages in different languages. It really provided you plethora of strings or metadata that you could actually use as a way to fake a data if you need it to. As a dev tooling dependency, if you used it, it's not as big in size. It perhaps have weighted something like three megabytes if you size the whole thing up, which if you think about it, it's not an issue like you download VS code or whatever and that's like hundreds or megabytes and electron ops or whatever. No one thinks about this, but by 2019, this grew up to 120 million downloads overall. So many projects, so many dependent projects and contributors part of this. At this point, we are moving on to figuring out something that's like very important to us ourselves. How often are you considering the fact that the size of the software you use is actually something to think about, to be concerned of? Aside from say front end performance optimizations, which is a whole different topic, but about the consumption of the software itself. We just mentioned the use of Verdatio and caching registries for things like being able to have deterministic installs and no surprises on the network and stuff like that, but this wasn't due to the size overall. It was for other reasons. So here, for Ensoir found this, I would say, inefficient problematic issues with his dependency. And over the years, he noted that he had probably kind of attributed something like emitted essentially, something like 11 metric tons of CO2 equivalent, you know, the carbon footprint. And so, for Ensoir said, being such a significant contributor to climate change kills me. With that, we have to wonder what happens next to Faker PHP library. He had maintained other popular libraries before. One of them is Propel. It's a database or MSQL database kind of extension. And he had really bad experience handing this over when he wanted to move over from Propel and start a new project and not maintain it anymore. It was so weird, so bad experience that the gist of it was the following, right? He went to his friend and said, hey, could you please maintain Propel for me? Friend said, yes. After a while, that friend handed it off to his friend and said, hey, would you want to maintain Propel for me? Said, yes. That maintainer was like, hey, that code is shit. I'm going to rewrite it. Six years after, no rewrite. Of course, nothing really happens. And that's kind of like the end of the story there for the SWAT list, who had learned that handing over open source projects is also nothing is a thing to do, thinking about legacy and all of those kind of things, the legacy of the project. So he archived the project, said to everyone goodbye. As with open source, the GitHub repository goes. No new releases, no new pull requests for Faker. We're already at the point of the story where he decided not to maintain this anymore. It still continues to function unlike the composer, the registry, the library where you could still download it, but essentially there's no new development going on there. And so kind of like he left it with a note of, as it is with open source, people are still afraid to fork it, create a new project. Of course, if you do that, you essentially, for Faker, for example, you lose all of the, I would say, the currency of open source, all of the stars and the popularity and everything around it with GitHub and things like that. So this was also his ending note for new maintainers, hopefully for them it works out better. Some learnings here. One is appreciating maintainers. They spend a lot of time, they try to figure out ways to be able to be constructive to the ecosystem, but not just the ecosystem itself, but maybe to the planet as well, making things better. So perhaps helping support climate crisis is something we should all think about. Our third and last story for today is going to be a recent one that had also caused a lot of breakage and interesting different opinions from the ecosystem of different folks, depending on where you're coming from exactly there. So we are all using open source software here. How many times have we considered about giving back? What are we giving back? And I was in a few talks in this in the morning here today, today's sessions, and I've heard about open source transparency, funding. There's a lot of issues there. I was at theories, I talk about the role of open source foundation and how they help and the whole money perspective of it there. This isn't an easy one, but it's a struggle for many, many maintainers. Unlike the other stories though, I mean, some might have had a good ending story. I promise this one has a positive, happy ending. Okay? So Meet Mr. M, he's known today as Mark, so I could probably iterate between those two titles. He's an open source developer, a maintainer of open source projects of others, not just the one that we'll talk about. And so he maintains a library called Faker.js. Incidentally, it's not the same idea, but not the same project, not the same person. The Faker.js one, as I introduced the one before, you can assume it's the same one. It allows you to do fake data for database or whatever you use it for. But it's for the JavaScript ecosystem, so a whole different project, a whole different maintainer, a whole different story in this case too. So we won't confuse it, but we will show that it was as popular as the one before, as the other Faker project. So very popular. And like many open source maintainers, Mark is helping developers of Fortune 500 companies and Fortune 50 and so on with their work day to day. They're all ultimately depending on this in their test or whatever to essentially help the business grow, generate more money and so on. But maintainers don't get anything out of it, right? They essentially are working and are largely underfunded, if at all. So on November 2020, to make a statement and send a message, this maintainer had opened an issue in their GitHub repository stating that they will no longer be providing any free work. As you can tell from the GitHub issue responses, the emojis at the bottom of that issue queue, it was largely accepted by the community. So apparently, Mark was heard. Was he heard? Did anyone actually care? Would anyone take any action on what was stated there? Well, two years further, January 5th, 2022, correct, this year. This maintainer publishes a new version of this Faker.js library with a semantic version of 6.6.6. Yes, some laughs and everyone can imagine where this is going, I guess. This new 6.6.6 version completely nullified or, as a lack of a better word, removed any code, any source code that was actually usable, any functional code at all, any installation if you had to try to install NPM install Faker.js at 6.6.6, which is the command to install this version, would result in nothing that's actually usable because there is no source code there. As a secondary effect, they also forced push a commit to the GitHub repository, as you can see here, which again removed all the code and perhaps added some clues into what's going under with the end game commit message, but this is what happened. Now, this seems, I would guess, based on the laughs and some of the reaction here, this seems rather aggressive statement, right? Did anyone actually care? Let's talk a bit about what's going on there. Well, Faker.js 6.6.6 is broken. It's a broken package. It doesn't really work if you try to install it, but the way that projects work in NPM is essentially if you had an existing project that uses Faker, you would have to explicitly tell it to use that latest version, okay? Because the semantic version resolution of those dependency versions doesn't just take the latest of everything. It takes the latest of December or the minor patch or whatever you configure it or whatever the default is, but usually it's not the latest major. So based on the fact that Faker 553 was actually the latest stable major version, publishing a new Faker 6.6.6 probably wouldn't have caused any issue for existing projects, not existing, okay? Plus a lot of the time, hopefully developers these days know to use lockfile to pinder dependencies. So again, lower impact of what was going on there and so on. So I don't know. Perhaps nobody really felt the pain. Perhaps a small number of users only felt the pain, and maybe this was talked and was on chatter on things like hacker news and Twitter, but it didn't really provide the message or the effect, I guess, that Marek was intended to express. So we talked about all of those cases, but we know, remember, we said Marek was an open source developer maintainer and as such, they usually maintain other dependencies. Again, similar from other stories that we talked about today. They're usually not, you know, one dependency and I'm gone. These other dependencies called colors. Colors gets 100 million downloads. That's a very big number. That's a very big number of downloads, okay? We'll see in a second who was impacted from this, large organizations that you all know their names here, maybe used their services as well. So with the intro of made about Sember and how that ecosystem work in JavaScript, colors latest version that was stable and well was 1.4.0. And 1.4.1 is a new batch version, which if you lock your dependencies and you want to have deterministic installations, when you do an NPM install, you'll probably not get 1.4.1. But if any other changes would request it, they might change the lock file depending on the NPM install command you ran, but also new installations would essentially easily grab 1.4.1. So the surface, the attack surface or the blast radius here is completely different from before and to kind of like the up and the right kind of impact that this would actually make when it happens. So what was in 1.4.1 that Murak pushed outside? Let's take a look at the source code. Can read it up, read it to you, but I'll also like give you a second to appreciate the elegance of this beautiful code. So adding an infinite loop to the code base gets triggered on every use of this library. So whatever top usage, your code, your another dependency that uses colors, whatever, every usage of the library would actually trigger this part of the code base. Essentially, it's breaking any other library that is dependent on it, because then you have a whole kind of denial of service happening for the app itself. It cannot be used. If you're using it in some server side, you couldn't understand the impact if it's even a CLI or an app, it's just as much frustrating for your users when your app is simply not reactive. So with that, 100 million downloads a month have a more significant impact if we do this. I've kind of like trimmed the infinite code here to what it would actually print to the screen, but actually it was a bit more Zalgo kind of text into the screen, and it would make it look really bad. But essentially, all of the developers are now using this. So when this went out and this incident happened, you could see not a lot after that faker thing with the nullified repository was going out, it actually impacted Mary, who is using Amazon's AWS CDK, which is dependent on colors. It was actually also impacting Mina, who was also using one of Heroku's Oculus libraries, was again dependent on colors. They were all impacted by this. If you were a developer using the just testing framework from Facebook or Meta these days, you would also be impacted by this because that's also dependent on colors. So this had obviously caused a lot of issues in the ecosystems and chatter and, you know, this was a very big incident happening. Not so long ago too, we just said 2022. The interesting insight also to make here is the versioning numbers and how fast this incident actually propagated and impacted users. So what you're looking at here is the downloads of the last seven days, note the version numbers that were problematic, 1.41, and then 1.42, which also had an issue. Mark specifically also added that denial of service code to other parts of the code. And you could see for the amount of days and hours it was published, it was very, very, very fast adopted by the community, showing you how much we depend on open source. Very much. So maybe some learnings here. Use a lock file to pin down dependencies. This is usually a thing that is created automatically these days and developers should know about it. I am also part of the open SSF package best practices working group. So it's something we've also noted there. If you have developers in your team, please have them go through and review all of those best practices, things we've laid out. But this kind of makes sense. The thing is this is kind of a proactive way of managing your dependencies. But sometimes, for example, for Mina's case, he was dependent on using some project that was dependent collars, she was already having collars as part of their dependency. So if she locked it, that would actually put her in more issues. You need to remove it. So another interesting best practice to know about is package managers have a way to essentially have, this is sort of a reactive mitigation. They have a way, this is specifically the NPM package manager in some others like QR and NPM have this way to say, hey, sometimes packages resolve to a dependency, say collars 414. But I want you, due to package manager, to always override whatever they want with this other version because I know this other one is problematic or whatever. This is a way of doing that. So that's another learning that the community had to understand of how to be actively work out the issue here. Other issues or other suggestions I will make is it is not always a good idea to stay on the bleeding edge and have automatic updates. So while automatic updates are great, we kind of need to have a bit of buffer time. This is something we learned at SNCC when we have the bots open up full request to provide you with security fixes for the vulnerabilities in packages that you use. We also do that for package upgrades, just generally do that. But we've learned a few years ago, based on past incidents like event stream and others that were there in 2018 and 2019, that we need to provide developers with some buffer time. So essentially, what we want to do is say, hey, you've seen how fast 1.4 and 1.42 were having thousands and tens and hundreds of thousands of downloads. What we want to do is the bot will open upgrade suggestions for new versions of package you're using, but it will do so after 21 days, okay? Because we want to give time out for the community and the maintainer itself in case they were accidentally shipping a breaking change, in case this had some zero day whatever in it. I want to give developers this time, so please also kind of upgrade your dependencies smartly and responsibly, not just blindly upgrade everything. At that point, you just might be getting a malicious package as well. So I promised a fairytale ending. What happened with Faker, going back to Faker, but with Faker, what happened is the following. The community had an amazing group of heroes stepping up and saying, hey, Faker is a very popular project. This is, again, Faker.js, very popular project. We still want to use it. It really helps us. We use it at the company and whatever. So they kind of like, organically formed up and said, hey, let's create a new Faker.js organization, a scoped registry entry. It's a new entity. They forked all the work that Mark was actually doing at the original Faker library. So all of his contributions are still attributed and part of the source code. And they've created a whole new project in GitHub repository to maintain that Faker functionality. So this exists. Amazing, amazing work to all of those heroes who made that possible for everyone else. Maybe a few more thoughtful kind of like learnings as we reach the end of this talk. One is think about open source due diligence when you use software, right? It sounds to an extent a bit obvious, but as developers, we usually adopt packages by the blog post that says, hey, I use this and that for my tutorial, we copy paste, we use it. My friend from a different company, my colleague, the other team, whatever, it kind of works like that. And maybe at times you search for something, like say you'd search for request, which is a popular open source library in JavaScript for doing HTTP client side requests. It's like the browser's fetch or whatever existed before it. So obviously it was needed. See 15 million downloads. And then you say, hey, of course, 15 million downloads, what can go wrong? Like if it works for other 15 million developers, I guess I can use it. Except if you open this, at least now, this wasn't true for all of the time that this project existed. But for the last couple of years, if you open this in this tool called Sneak Advisor, it's a free tool that you could just Google and go into, you could search this request package and you will see that, for example, the maintenance part of it, the maintenance frequency, virtually is nonexistent across the whole year. Like last change two years ago, last commit two years ago, it's not existing. So why would you adopt and use this project next? So our kind of like tell signs for using packages usually are about popularity and stars and whatever. But those could sometimes be very deceiving, which is why kind of like we recommend this way of like having trying to score packages and provide kind of like this held score of the packages that you use. Another different example is, hey, sometimes this package makes sense for me because I looked at its maintenance, it gets regular commits, it's actively maintained. And if there's like a new vulnerability, they will probably fix it pretty quick. Latest versions show up that like there are no vulnerabilities detected directly or indirectly, so maybe I will use it. And so this takes the discussion a little bit from not just due diligence as developers when you want to adopt new packages or move to a new dependency, but also some people have been talking here a long time about SBOM and software bill of material. I won't go into that, we're kind of like ending this note, but I want to give you something else to think about. Not just software bill of material, but perhaps software bill of health. How healthy are the open source projects that you use? A typical JavaScript open source project has probably thousands of dependencies down the chain of a tree of them. What happens if one in the middle has an issue? It's just un-maintained for the last two years. What can you do about it? You can't blame the open source developer who the maintainer itself, they are literally volunteering their time to help you do whatever you need. So think about this a little bit and let maybe that sink in. So open source is great, just don't forget. The only things that last forever are dependencies, I guess not. Air miles I checked because I flew in a couple of times after COVID, they don't last forever either, trust me. Cat videos in YouTube do last forever, that's for the sake of every one of us here. So with that said, open source software is awesome, have fun with it. If you have any questions, I'm here and thank you for listening to my talk. I think we have time for questions, right? Yeah, of course. I'm just checking if this works. A document by the OMB based on the Joe Biden's executive order on supply chain. One of the things that I'm talking about is self attestation. Now self attestation of that my product, my component, my whatever is okay safety wise. Who would do that if maintainers are responsible to absolutely nothing? So maintainers are not concerned in the organization itself for absolutely nothing before that order itself, right? They literally tell you if you're using an open source package with an MIT or a battery license, you are free to do with it whatever you want. I do not take any responsibility for it. So regardless of that document, maintainers are not the person to reach out to or put the blame or demand on. You're effectively just making the matters worse when we're demanding more and more from maintainers and essentially giving nothing to help support them. I think maybe back to correlate what we learned here back to that executive order is essentially thinking, as I said, not just as bomb like your bill of material, which is important and so on, I won't dive into it, but also that health, right? Like when you use packages and developers do use packages. So the as bomb itself says, you know, I'm using these three ingredients in my product. It doesn't say what's the status of those ingredients. And there are these like other other standards kind of getting in like VEX, which is the exploitation and other like vulnerabilities of these S bombs. Great. Still, it doesn't mean say anything to the company, to the business, if they have some trickle down dependency, five layers deep that essentially did not receive any commits in the last five years. If tomorrow a new vulnerability will get discovered there, there's essentially no one to go and push a new fix. What do you do? You rush off to find alternatives, patch it, et cetera. So this is what I'm trying to go to here. This health package scoring kind of thing rather than the vulnerabilities and everything else, which I think we've kind of as an industry with S bomb and VEX and whatever with SCAs and all of these tools, we've kind of like figured it out to an extent. Thank you for the question. Yeah, I guess we will. Any other questions? Ask about log files. Yes, log files. Yes. Upstream uses something which is a bit more advanced. Wouldn't you break your own code? When you lock your dependencies? Yeah, and I mean there are no real standards for ones to use in your dependency and you lock it and provide it with a lower dependency. You mean specifically with regards to the overrides that I was giving? Yeah, yeah, yeah, yeah. Oh, okay, because otherwise it's a bit, not really the question because when you lock the dependencies you're locked and that's what you get and you've tested that the project works this way. So with the overrides, yes, you essentially have to know that you're not breaking it. To an extent, it's not that much of an issue because if you're overriding it, it's most like 99% with a reason and you know you're overriding it with locking it to a stable version. You know what works. Usually the community also knows what to recommend if you need to override it. So that's not much of an issue and I think also Sember is kind of like a practice that usually works. I will say TypeScript has shipped some versions with minor changes that were breaking changes, but overall the ecosystem, of course like this might be different for Java or Ruby or whatever, but for JavaScript we kind of know how Sember works and we can to an extent depend on it. It's still semantic and not really anything explicit. So you kind of like take it with a grain of salt. Hi, cheers. Great talk. Thank you. I was going to say I was a little bit sad about your happy ending in that it wasn't really a happy ending for Marik and that that kind of gets me onto a point that I thank you. I think one point that you've missed, I think you had some great advice for consumers but I think the one thing that to my, oh god, I'm steaming up, the one thing to my mind that was missing was to fix the problem at source you have to help the maintainers and this is almost like in response to your question where you're getting a little bit frustrated that maintainers are washing their hands of some implied obligation. They don't have an obligation implied or otherwise. As consumers I feel we have the implied obligation to help the maintainers. So if there are security issues we should be rather than pointing at them we should be helping them. I am a hundred percent with you in that. I'm a maintainer myself and I have a lot of friends who maintain software. There would be no one else more excited and appreciative of any of that working out amazing for everyone else. The issue essentially is that it's not as easy to fix. When that happened as a community for you know communities that I live in I've actually raised the topic and asked what we can do. Some interesting ideas were by the way doing something like bug bounties for security but actually for issues or features. So if you wanted something to get developed you could say hey this is my issue I've put you know 100 dollars whatever around it and if you can like build it or whatever contributors build it they get it. It's something that we drive through the platforms. There are a lot of people here from like Open Collective or GitHub funding and sponsors and stuff like that. The ability to fund maintainers has existed for a while. It's just like not happening to an extent where it's actually fruitful for them. So it's not that we need to raise awareness of helping maintainers. I think everyone know they should do it. We're still not doing it as like top level organizations and I think that's a problem that we have yet to have a good fix for. We have to stop I think right you gave me like the stuff thing but I'm here like let's talk so. Yes we can do that. Thank you everyone.