 This is a little talk about the Drupal Auto Updates Initiative. Sorry, it's been a little while since I've actually spoken at a Drupal event, so I'm a little unpolished. Please forgive me. I'm Dave, a little spiel here. I'm the director of Global Product at DDAV. So if you guys use DDAV Local or have heard of DDAV Live, I'm making the product decisions over there. I'm also a Drupal.org security team member, so if you have ever seen a security advisory come out on a Wednesday, I may be involved in those to membership reform as well. I'm also, I don't really have a title here, but I care about the Auto Updates Initiative, and so I am a Initiative Care Err About Err as the closest I could think of as a thing to talk about there. So what we're going to talk about today is kind of just like a little update about the history of the Drupal project itself. Not super interesting, I don't think. You maybe are familiar with it. Then we're going to talk about the initiative, why it exists. There may or may not be a live demo involved. And then some, I guess, call for action on your part. So we're talking about how you can get involved. It's pretty easy, but I'll talk about that in a sec. So the first thing is let's thank everyone who is involved in this project. It's been a really, I guess, a long time coming in the Drupal world, and it's kind of been difficult to get started. So the first person, organizations, the European Commission, they funded some development work for their Drupal 7 sites. And they basically have a fleet of sites and were struggling to, I guess, manage these sites in a way that they felt was easy, and then they had some money and thought maybe we can help the community at large to do updates better than we had been doing. They paid a decent amount of money. Basically, for phase one, there's plenty of phases here. And you'll hear that kind of regularly. So the phase one was funded by the EC to do auto updates in Drupal 7 and kind of Drupal 8. And then the Drupal Association and several people here, Neil Drum, David Strauss, Lucas, Tim. I don't need to name the rest of them. I'm sure other people have forgotten here. But they're kind of the core-ish initiative team. So the history here, I'm sure many of you have kind of run into this problem. The Drupal security team is primarily a US East Coast time zone oriented team. And so what this might mean for people who don't live in that time zone, like myself, and probably the majority of you guys, is that security releases get released in your evenings or in your mornings or wherever in the world. And what this ultimately means is when a security release happens, you have to be awake for it or your site gets hacked. And in at least two cases, we of the security team have seen exploits happen within four hours of an exploits or a security announcement being released. So that's obviously like the Drupal getting kind of level of vulnerabilities that have been announced. So what you guys have done, I guess, in the past is you're staying up late into the night. You have a large window of time where your developers have to be basically on call, kind of frantically refreshing Drupal.org for the security announcements come out, which is not super sustainable, I guess, ultimately. You're paying decent engineers time and a half or overtime for late night work. It's not ideal for sites that are well-maintained and have big teams behind them. Some other kind of personas here in this space, too, like site owners may not really be paying for operations and maintenance on their sites, but they just have a one-time site delivery. And they don't understand why it's important to keep their site up today, or maybe they understand that they don't have the technical capabilities to even update Drupal or do it themselves. And then there's just kind of the pantheon of what other things people do in the larger community. So the WordPress community has had auto updates for quite some time, and other closed-source projects as well. And we're just kind of living in worlds where people are kind of expecting updates to be delivered when they come automatically kind of through magic. We'll talk a little bit about WordPress later. So what are the solutions here? You've known them, you've probably done them. Have you guys ever had teams do any of these things? I assume maybe in the first to stay up and wait. You maybe have a hosting provider who does provide some sort of update solution. Maybe that's pantheon with their upstream repositories, or maybe that's Acquia with what is it, remote administration? Or I'm sure Platform has something. I'm just not sure what it is. Maybe you're doing something like on every Wednesday, or running dress shop security only on the site every five minutes, or kind of the worst case scenario is you're doing nothing, which I think in reality is probably a lot of our target audience. So the auto updates initiative, there's kind of several personas on this journey we're trying to solve for. But ultimately, there's a long tail of people who install a Drupal site. Maybe it's some sort of brochure where a site, and they don't really, it just needs to be available, but they don't really care about it. They don't have a team. And those are the kind of sites we're looking to solve a problem for ultimately. So we want those sites, it's probably the majority of sites, to be secure and to do things like updates automatically, to do things like updates automatically in a way that is secure, to do things automatically in a way that doesn't break people's sites, which is tricky. And then we reputationally take a hit for breaking people's sites when updates happen. And that, I think, is also for sure not ideal. And so let's talk about what auto updates are doing. So WordPress has had this feature in its core for years. And I'm going to take some opportunity to hate on WordPress a bit here, but WordPress's auto updates is not following a lot of best practices. I'll say that kind of lightly. They're basically downloading a zip file from a server that's automatic, sorry, controls. And they're not doing signing along those lines. They're not doing any kind of verification that that binary hasn't been altered in any way. And until, I mean, my data might be a little out of date here. But until somewhat recently, I think they were downloading that file over HTTP as well. So the Drupal community, while this feature existed, it was always kind of a WordPress has it. It's a solvable problem. Why doesn't Drupal have it? So there's kind of a lot of things we have to worry about here. So enter phase one. And today has phase one has been completed. So there's kind of a rigmarole of stuff under the covers that we have not, I guess, ran into yet. But the things that we're supporting, I'll show you in a little bit of a live demo if it's going to cooperate with me. So things you might have seen, Drupal.org. There's a PSA feed. So we have a module that you install. We can basically push things out into your Drupal site that's like heads up. There's going to be a core release just for planning purposes in its coming. So you'll be able to see this on your status report dashboard. And I think most of the majority of the admin pages inside of your Drupal installs. The big thing in this phase one initiative was the signing infrastructure. So this means basically every file, every... I'm a little sketchy on the details here, but every package that D.O.Packages is cryptographically signed. There is a whole signing ceremony if you guys have ever wanted to watch a 45 minute video of keys being passed around. There is a video on YouTube of a signing ceremony practice. It was largely inspired by the signing ceremony that the internet does when they rotate keys, which is like a four hour signing ceremony, which is kind of crazy. But basically getting keys in place to be able to sign code that is distributed from Drupal.org. And so what that makes the auto updates and how it benefits the auto updates initiative really is you can be assured that the code running on D.O. that's packaged by D.O. is the code that is coming into your site. And you can imagine why that's relatively important. There's also some cool stuff I can show you too. There's some diff generation. And there's basically a packing method that you can do things like generate diffs from two versions of Drupal. So I'll show you this. I ran this a couple of days ago. I don't know if it's still a valid URL. And I don't know how easily you guys can see that. Let me make it bigger. So I'm going to download a diff of Drupal 5 to Drupal 877. And Drupal.org will happily go and generate me the files to do that. And so you can see down here it's downloading a 25, 26 meg zip file of just the diff between those two versions of Drupal 4. And it's quite big. But if we want to go edit the URL, what is the most recent version of Drupal 8.2.3? Anyone? I don't think that will work. It's probably good. So I just want to make a point of this. And this one will go generate. It generates a 2 kilobyte diff. Show you that here if I can drag it over. Where'd it go? Sorry. And you can see basically here's the core. Here's the quasi patch version of what we would be delivering into a site. Not particularly important. I just thought it was cool to show you the things that we were doing. Where's my slides? So the other thing on the, I guess, that's the infrastructure side of things. Like the d.o, the Drupal association having to build out the tooling for being able to do that. The module side of things, the thing that will interface with their site, it's doing a couple things as well. So site readiness checks. Talk about this a little later. So the phase one scope is limited to core. Doing updates and rollbacks. No composer support. This is like the big takeaway. There's no composer support in phase one of auto updates. I'll talk about that in a second, too. And it's just core. So here's what the PSA is like. This is on a test site from a PSA that ships with the module itself. You can see on the status report page, there's a public service announcement that requires your attention. Basically, go read this thing. And there's also every subsequent admin page on the site. We'll also have messages warning as well. Readiness checks. So this is like, is your site eligible to do auto updates? And there's a bunch of stuff here. And I think you can also write your own readiness checks. So if you have some steps that you need to take on your site, you can do your own custom readiness check and it'll pass or fail. So things like, is your file system modified? Or have you incorrectly patched core? Maybe someone went in and just changed the file for you. Are you on a regal only file system? Because that basically prevents us from running new code on that file system. There's a couple PHP versions that Drupal will not run on in the 7.2 series, for some reason. I think a specific point really is, in fact, do you have enough disk space? There's other things. I can show you the repo. They're pretty easily named. You can go look at them yourself. In fact, I encourage you to do that. So the signing and packaging infrastructure. Sorry, I cut off a little bit. If you've noticed on release pages on Drupal.org, you have the ability to see SHA-256 checksums, but also down the bottom, if you want an MD5, get an MD5, if you want a SHA-1, you can get a SHA-1. And how many people just show hands have verified checksum before? OK, got some nods, good. Do you do that every time you download a file, or just from time to time? OK, cool. So every time Drupal, the auto-updates module goes and does this, it will verify a checksum, which is important from just knowing that the binary or the tar ball you're downloading is the tar ball you're getting is kind of an important check. And things like WordPress don't do this. They might today. They don't have any currency currents with the WordPress side of things. OK, live demo time. And we're going to hope this works. It should work, though. And I have a backup video in case it does not work. OK, so we've got a super high-powered Drupal site. It's got all the bells and whistles clearly. I will show you around this site, for instance. What does it have? It has content types and blocks. Actually, it has no content types and blocks. It is as pretty generic as you can get, I guess. So one thing to notice here, you're seeing a PSA. This is, again, test data do not be alarmed. I guess it's also in the past, so no big deal. But this is what you would see if the Drupal security team, or the Drupal association, or core team members, will push an update out to your site sites. Or actually, I guess you're subscribing to it. So your customers themselves are not seeing this. Didn't grab the URL, sorry. But your site administrators are definitely the people who are going to go see this PSA. And should, in fact, go read it, I guess that's unauthorized. But you get the idea. It's pushing admins PSAs to go, basically, take action, or prepare for action, or what have you. So that's the every admin page side of things. Again, this is in the slides earlier. On the status report side, you also have the same PSA. And here's the live demo portion. This is Drupal 7.68. And this also works equally well with Drupal 8. So I just happened to have a Drupal 7 site. Cron has not run recently. Here's another example. The readiness check is failing. So I'm just going to go run Cron. This will clear it up just to make sure that packaging has worked. How do I run Cron in the UI? Perfect. OK, so now I'll show you that, in fact, the readiness check has now passed, potentially. I don't know. Live demo is failing, guys. That's strange. We'll see if we can forge ahead with that readiness check failing. So what kind of auto updates looks like from a long term standpoint is you're probably never going to do it this way. There's a little phase one experimental area where I can go hit a button, basically, and click a link and trigger an automatic update. But in the future, this will likely just be enabled. And it will happen when the update happens and Cron is running regularly. So today, for instance, this is an experimental module. You can, for sure, run it on your site if you want to. But we recommend keeping a close eye on it as it's still kind of new. It doesn't have widespread adoption. Talk about that in a second, as well. So who wants to come up here and click a button? Nobody? Do you want to? All right, let's do it. Let's upgrade core. So I want you to just click my mouse, aggressively click. Just tap. How's that? That might be working. Cool. Update successful. So to prove that this is not all snake oil, let's go through and just verify that we have indeed upgraded to the latest version of core. And I believe we have upgraded to the latest version of core. Cool, right? So live demo complete. Maybe worth mentioning. We do want you guys to install this in your sites today. You do not have to run it in production, but we see no reason why you couldn't. There is a 1.0 release of the module, so it's covered under the security team policies. We kind of want people testing the corner cases here, because I'm sure there are a lot of them. We've seen some stuff where sites don't update. We just basically want more eyes on the code, more eyes on the process, so we can kind of iron these things out before the auto updates module itself rolls itself into core, which is hopefully soon. Let's move this. OK, so what's phase 2 of the auto updates initiative look like? We realize you guys probably are doing fewer and fewer untarling of tar ball balls and deploying them to servers these days. So phase 1 is going to be a little bit more these days, so phase 1's maybe not super helpful to you. It's definitely kind of a building block for us. There's a lot of infrastructure stuff. There's a lot of assurance stuff that we need to hammer out a bit, but the reality of the auto updates initiative is it's probably getting to be useful in phase 2 to you. There's a couple other hairy problems in phase 2 that weren't in phase 1. We've kind of deferred those for a while, so you guys have heard at least about the composer initiative in core. Yeah, see some nods, cool. We needed that to happen for a couple of reasons, and we need some more work for a couple more reasons. Composer is kind of a hairy beast, consuming as much SRAM as basically one Google Chrome window wealth for basically figuring out dependency trees and all that. We want to do basically the work of auto updating a composer-based install site inside of a web request. So what that means is there aren't 16 gigs of RAM available to calculate my dependency trees. So we're trying to get some sort of lower memory consumption composer. This on two fronts. There's some tweaks in, I forget the name of the composer package, and I didn't write it down to my speaker notes, so forgive me there. But there's the composer tweaks for Drupal that help eliminate some of the dependency tree figuring out, and that does help to remove a significant portion of the memory footprint there. But we're still talking about two gigs to 1.5 gigs, and no way is anyone giving that much memory to their Drupal sites, or hopefully not. So we have to figure out how to put a lower memory, basically update of Drupal into the portion of your web request that hasn't been used by your site. So what we're thinking about there is creating of a new front-end controller. I'll use an analogy. Have you guys used Capistrano for deployments ever or have heard about Capistrano? All right, I see no one. Who knows what that is? One person. Cool. So it's kind of a similar concept to Capistrano, and I realize that's meaningless to you guys almost. So what Capistrano deployment is doing, and this is how Cisco updates its firmware. This is how Chrome OS does your updates of your laptop and things like that. So what it's doing is saying, I have one partition and I have another partition. And in Capistrano land, to kind of beat this analogy, you have a folder structure where you have your live site and you have the next site. And all you're doing is basically flipping a sim link in between those two sites. So your dock route is a sim link to one or the two of these options. And you'll be doing something very similar with a composer install, where you have your known good sites like today. You'll have an updating site that's next to it that is using spare web requests to basically fill out this composer install. And then we'll send a request in the spare cycle to the other site to make sure that the site's like 200-ang. So we're not flipping the switch to a broken site. And then the secondary site, I guess it could be writing this. Is this the whiteboard? Would that be helpful to visualize? Yeah, no, OK. So excuse my horrible handwriting. You have the live site. Oh god. Can anyone see that? OK, cool. So you have a live site and you have an updating site. I don't know if you can add. And so requests are coming into here, right? And in the spare cycles of your live site, you're sending basically chunks of updates to the updating site. So when the update has gone through, can you guys see this thing? And the update has come through. We'll send a web request here through an update mechanism. So your customers will never get like a 500 site as horribly broken kind of message. And we'll verify that this is good or it's bad. If it's bad, we won't do anything. We'll probably just delete it. If it's good, we will then point the traffic. So the AV controller here. Oh my gosh. Third one's a charm. Let's see. Maybe shaking it helps. So there's an AV controller that is deciding where the traffic's going. So everything's going to the live site. The update's verified. This goes away. This comes to here. And now your site's updated. And all the traffic's going to the new updated site. It might trigger an email like, hey, your site's been updated. Maybe go check it out. And then if an admin comes through, something's horribly wrong, the person can go easily, run a command to then switch it back, do some DV rollbacks if necessary, get on with play. But in theory, this should work. And this is modeled through every firmware system does these kind of updates this way. And also, we can contribute here, too, because all good Dribble developers in the Composer world are managing your Dribble contrib in Composer files, right? Yes, good. We also want to switch the signing infrastructure a little bit, too, and actually kind of two broader community-based things here as well. We are working on the AB controller with the Type 03 community. And recently, the Joomla community as well. So this may become the way relatively more and more open source CMS PHP-based projects are going to be using their sites or updating their sites. So it's kind of a broader community kumbaya thing being here, I guess, too. And also, just the signing infrastructure, it's a little complicated. And anytime you talk about cryptography with people, you kind of get either excitement or terrified response. So we're switching to a little bit of a more understood update framework. Oops, I'll pull this up to just show you the. So it's got TUF, I don't know how you pronounce anything. I'm in my tooth, I guess. And it's basically a Python project, but it's a framework for securing software update systems, which is exactly what we're running here. It's got all the right buzzwords on the home page, cloud native, if you guys know what that is. Linux Foundation sponsored. And we're probably going to implement, I think, the verification side of the update framework for Drupal's.org's signing infrastructure. But this really doesn't matter, ultimately. It's just a kind of coming soon. And so how you can help. I kind of mentioned this already. You guys can run the auto update module. Go download it on Drupal.org. It's automatic underscore updates. It's for both Drupal 7 and Drupal 8. Give it a code review. More eyes on it, the better. Go install it. Go test it out. Go run the readiness checks. Give the team feedback. You guys know how to file an issue in this UQ. We're in a Slack channel. You can join us there and complain or loud give us praise, depending on your perspective, I guess. If you're interested in getting involved, kind of different vein. But this is more like you want to actually go write the code that does this. Our project page is here. We have our hashtag auto updates in Slack. It's pound auto updates in Slack. I don't know what your perspective is there. We have regular initiative update meetings on the first Thursday of the month. I think the next one is the 2nd of April at 8 o'clock UTC. And thank you. I realized it's a little short. So I'll probably use it there. But any questions? I'm happy to show you things more. Please. Sorry if I ask you about what is about pages? What we're talking about? What is about pages? So I have lots of pages on Drupal 4, contribute modules, not sure that automatic updates will work with them. You have a lot of pages. Patches. Patches. God, I'm sorry. As long as you're managing your patches in a predictable way and for phase one, you're probably not super, a super vial of cannabis. But if you're managing your patches through a composer with Cameron Egan's composer patches plug-in for composer, you'll be OK. Anything you can do with composer-backed tooling will be fine, because ultimately, we're just running a composer update in the updater process here. Thank you. Hello, Rose. Go back to your phase one approach. Are there any considerations in terms of server permissions, fine permissions? Yes, there are. So let me just pull up the reviewer. So here's the toggle sum of Drupal 8's readiness checks. So we've got, is the person who runs the file, is the person who owns the file, in an nginx context, can we update the file? That's in this file, basically getting the user, comparing it to who is running it, to who is owning it, and seeing if we can do that. So that'll be a topic for that user. Yeah. I mean, it won't actually change the ownership of the file, but it will check to see that the ownership is like, you're in the right group. You're in the right ownership, that kind of thing. The other file system related is the file system read-only. So if the file system is read-only, we can't write to it, obviously. So you can't really auto-update your site if it's read-only. Don't think there's another one related to necessarily the file system itself, besides disk space? Did you have a specific like? No, just my local user group, the guy who owns far more than I ever will, who's worried about the side of things in terms of using the course-match group. So I won't say there isn't inherent risk with having your entire file system or entire web root be writeable. That's kind of like, we don't want to accidentally turn Drupal into a botnet just by executing our arbitrary code in it and basically having everyone mining for Bitcoin on their instances. So there is some risk, but I will say, if you have an ops guy and you have a big team, and here's where this gets a little sticky. If you have a professionally managed site and you're paying an operations and maintenance team to do operations and maintenance, auto-updates might not be a great fit for you guys, because you're right. This is true, but what it does do is you could say, OK, I think here's the perfect scenario. Your PSA announcing some Drupal vulnerability comes out a few days before we release the vulnerability fix. You then maybe put your site into read-write mode or something like that. Your file system admin goes and remounts the disk mounts to make the file system writeable. The auto-update comes and happens, but your team doesn't have to stay up for an eight-hour window and the patching, and now two in the morning, and everyone's super pumped out the next day. And then your team can just come in, verify that the patch worked, do the get commit, go do a normal release, and kind of the normal order of things. That's where I think auto-updates will save the most time for teams that are doing the day-to-day professional management of a website. The real goal, I think, of the auto-updates initiatives is for that long tail of people who just installed the site once 10 years ago, and it runs Drupal 5 still, and how has it not been hacked yet? Just brings me up to the second question. Assuming you have module compatibility, would it work for major updates, 8 to 9, for example? Or is there a hope that all data will work? I don't know that anyone's specifically given consideration for a major update. Because the audience you're thinking of would expect that. Maybe? I don't know. That's where, if you have that question, I would say, come into the channel and ask. Because to be fair, I think maybe someone's given it, like, I think that'd be an idea. But I mean, the 8 to 9 transition should be easier than any in the past. So in theory, sure could we do it? Yeah, maybe. But there might just be like a, we're not going to do major versions as like a safety protection in the code for some sort of really big screw up. Anyone else? Questions? Comments? Yeah? The whole composer memory thing, I mean, you kind of spread it across the line. I'm so confused. Why does it need so much memory? Just the dependencies at that level. I didn't make that sound. Let's go over this question. When we have an automated update server that we homegrown ourselves, you can propose the using script to, I don't know, support about 100 sites. And so, yeah, with that, we'll get paid to support it, but it makes sense to automate it. Right. Because otherwise, it's crazy. But the component thing is a massive pain. Yeah, so. Is that a blocker to, you kind of need a whole separate server to run all of your updates on because of the amount of memories you need. There's kind of three spear points happening here. There's Composer 2, which may or may not be a dependency. I'm hoping not because I don't know how soon or late that isn't coming. But there are memory, there's considerations for better memory management in Composer 2. There's the other thing. So I guess to back up and explain why this dependency tree thing is happening and generating all the memory, the more stuff you have installed in your Composer, Jason, the more dependency graphing it's going to have to do. So there's a module that has x, y, and z dependencies who have x, y, and z dependencies. And there's a dependency tree calculation that's happening. And it's kind of just inherently expensive. So one of the stupid things that happened when the Composer initiative was looking into things was they found Drupal dependency that I think had 10 plus years of history and 10 plus years of releases. And we emailed the person and said, hey, you have a lot of releases for PHP versions that aren't supported anymore. Can you delete those for us? And that dependency tree calculation saved a gig of memory from us. So there's also some spelunking we can do to release history to make things a little tighter. The other spearhead. I don't remember the third one. Sorry. But then people also suggest that we can do things like if you've used dependency tree, if you've ever given Composer.json to a service before and it spit you out a block file. That is another solution there. But we don't necessarily imagine that it will be feasible for the Drupal.org infrastructure to basically calculate everyone's dependencies, especially when there's a security update, calculating millions, tens of millions of websites dependency trees in a timely manner and spitting out a lock file to those people might not necessarily solve the world's problems there, either. It's just kind of a hairy mess. Sure. I thought that another thing was a relevant question. That's a bit of a size limit. But when you're doing automatic updates and you're doing that through point of clicking and changing files in the file system, is there any consideration for then putting all of those changes in files and configurations into the repository or some kind of like automating outside of it? So I know on Pantheon, they should be automatic updates and then that goes into your hit-with-mode and you can then deploy that from you there to the page to live, presumably using some of the things that are similar, but is there anything, is that part of this consideration yet? There's been a little consideration to that because there are people who do provide services in that space, like Pantheon, like Acquia platform, I'm sure. Amazing, I'm sure it does something there as well. Here's a good point to take on the desk side. All the updates are done great. Right. Yeah. I think there needs to be a little, probably, community participation from companies around what they want to do. Because I think, again, this is the long-tail problem. We're trying to solve not for agencies or companies who manage website deployments. We're trying to solve not that my mom has a blog, but my mom's blog. And she doesn't know or understand or care about updates. The worlds of, I think, the square spaces and the wicks that are the version of the software that they're running on your site doesn't really matter. And they're just shipping updates to you as they come. That's kind of where this is as well. OK, I'm running Drupal 768. And I upgraded to 769. But I don't care about that as a business owner. Frankly, I care about my business. And I care about my website being secure. But I don't care about what is a minor point release of this Drupal module or this core. It doesn't much matter to me. And that's the long-tail is what we're solving for, not necessarily that. I guess that's also where the tension comes in around security, though. Like, I'm a business owner, small business owner, I just care about security. However, I'm willing to let my website have right access to the file system in order to do the updates. And, oh, my password is actually not that strong. Or somebody has an employee, and then suddenly somebody gets access. Yeah, that's kind of the story. I think there is, like, I would welcome you to contribute that, like, OK, I need, like, post-actions, for instance, after my site updates. It would be great if there was detection, the PHP is detecting, like, you're in a Git repository. And maybe we, like, create a branch and can create a commit in that branch or something like that. It sounds like a great feature request. Yeah. Just to, yeah, I mean, continue to think about that. Yeah, actually, I don't know if I can find this really quick. The amount of automatic versus auto updates, kind of frustrating. So maybe it's on, let me see. So we have some personas someplace out here. OK, yeah. So these really went, I could think, in deeply. And, like, how we thought about this, I think the majority of auto updates are trying to fill these two use cases. Probably even the third one. But really, like, as I said earlier to this gentleman here, like, if you have a team who's doing O&M, like, this is kind of a minimal value. But beyond, like, your team doesn't have to stay up at nights and every Wednesday when, like, our release is coming out. Like, that's taxing. Date's based on dates. It's covering that as well, I don't know. Kind of not. So, but kind of not on purpose. And I'll preface that with, we've kind of got a handshake agreement. And I feel like, for the recording, actually, it may kill me if I figured this, to say this wrong. But I think the process for core is in a security update context, there will not be a database update, I think. So the need for doing, like, an UPDV as part of the end process, we don't need to do it. Since maybe we're patching just the dependency, there's less cases where, like, we have to run SQL queries to fix a security. I don't think there's been. I'd have to do some digging into this. But I don't think there's ever been a Drupal security issue that has required a database update. But again, going back to the target audience of, you know, Decloning Norr, over the lifetime of a release that's been settled. Right. That's where some players need it. Yeah, and I think they just won't be intended to. And I think, well, if you have a Drupal site, you can run the updates through the UI very easily. Similarly, like, we could just call that same function and run the updates on the behalf of the user as well. I think there's just a little more risk involved there. Obviously, updating table schema's a little easier to do now that it's a transaction inside of Drupal 8. Drupal 7 is still kind of risky, wild, wild Westland. But yeah, I hear what you're saying. Anyone else? Time is up. Yeah. Seems like this is mostly well-updating core. Is there any idea of, in the future, updating control modules as well on display? Or is it something that you find hysterical? So that's definitely on the radar of phase 2. Because really, Composer, if you have a site and you're managing it with Composer, you're going to be managing your contrib modules with Composer as well. So that is solidly a phase 2 thing. And yeah, there's a security update for a contrib module. The theory is that will also work too. Anything else? Go install the module on your sites. Please, give it a code review. Help us out. Submit those future requests. Cool. Thanks for coming, everybody.