Security in Drupal: what can go wrong?

BENJI FISHER:
Before I turn it in. So security in Drupal, what can go wrong or if I had slightly more room on the slide, what could possibly go wrong? And the answer unfortunately is lots. Before we get started, as if we needed a reminder. So introduction about me. I'm Benji Fisher. I have the unoriginal name Benji Fisher on Drupal.org on GitHub, on GitLab. Don't use twitter much anyway anymore. I've joined Mastodon, but I'm not very active there. The yellow pig is my avatar. And I wear the hat in the hopes that people who recognize my avatar but not my face will realize who I am. I'm a member of the usability group and during the contribution event tomorrow, I'll be moderating the weekly meeting on Zoom. You're welcome to join, and then I'll be sitting at a table and working on usability issues if anyone wants to join me. I'm also one of the comaintainers of the migration subsystem or the Migrator API, and I'm a member of the security team. I joined last year as a provisional member. That's the usual procedure.

And in the early days of January of this year, I was promoted to a full member. You can follow along a link to this presentation on my GitLab pages, its slides.benjifisher.info. If I were registering the domain today, I would probably go for .io, but I've had the domain a long time and .info seemed like the right thing back then. And they are most recent first, so if you just click on the first link, you'll get the page for this presentation. The only thing that's missing is the slide reminding me to push the big red button. So the outline is a little daunting, but don't panic. We're in the introduction already. I'll talk about what is the OWASP Top ten? I'll talk about what is Drupal. And even though this is a Drupal camp, I sort of wanna take the outsiders point of view. So I will talk about that and then I will go through some of the OWASP Top Ten in one session. I probably have time for two. Prepared I think four of them, maybe five. But this is a list of the top ten security vulnerabilities on the OWASP list, which I'll go into in more detail in a minute and then we'll wrap up conclusion as well like the introduction.

My slides borrow heavily from other sources. I've used some of Peter Wolanin's cracking Drupal presentations and also I've copied some text from OWASP.org and the footer text on most of their pages mentions that they have a Creative Commons license. So I think I'm in good shape borrowing their text. And I also all of my slides have a similar copy left at the end, creative Commons share alike. So if you wanna borrow any of my text, just remember to give the attribution. So what is OWASP top ten? OWASP I think I've now memorized the Open web Application Security Project. Yes. It's a non-profit foundation to improve the security of software. And it is not Drupal specific. So I guess this slogan, Get off the island is getting kind of stale. That was one of the things we said while we were. Working on Drupal Eight. But it's still true. This is not a Drupal specific security thing. This is something that everyone who works with the web refers to. That's OWASP. The OWASP Top ten is a standard awareness document for developers and web application security.

It represents a broad consensus about the most critical security risks to web applications. And it's updated every few years. The most recent version is from 2021. So I started working on this presentation last year and I looked at the OWASP top ten and said, Oh my gosh, it's changed. The previous version was from 2016. So that's what the OWASP top ten is. What is Drupal? It is a content management system. What does that mean? It says enter data in my forms. I will save whatever you enter to my database then generate web pages from that. And the hackers say, sounds great, let's get started. So, for example, when you have a web form with a field labelled name, the hacker will try typing in Robert, '); Drop table students;-- Do you recognize that? Well, I see one person out of five, two people out of five nodding their heads, and third gives me away. OK, so you've seen this before. I'll fill in the rest of you in a minute. The idea is that the hacker hopes that behind the scenes you're doing something like this line of PHP $SQL=" So we're interpolating values, insert into students (name) values' ($name')"; And if they do that interpolation then adding a line break for readability, we get this insert into students name values of Robert and the close quote right for and semicolon come from what's been typed into the text field and then Drop Table Students; and what's the point of this double dash, Hyphen hyphen and SQL?

Yes, it's the common character for SQL. So whatever else comes after there is ignored. And that's why the hacker typed that in. So this is what a hacker thinks of when you tell him that I've got a web CMS and you can type data into my fields and I'll save it to my database. For those who don't know, that example comes from XKCD, which also has a Creative Commons license Exploits of a Mom. And I'll just read the last panel. Well, we've lost this year's student records. I hope you're happy and I hope you've learned to sanitize your database inputs. What else is Drupal? It's an active international open source software project about page says that the Drupal community is one of the largest open source communities in the world, where more than 1 million passionate developers, designers, trainers, strategists, coordinators, editors and sponsors working together. And Drupal takes security seriously. Come on in. This is the session on security in Drupal. And we're still in the introduction stage.

Haven't gotten into the nitty gritty just yet. But Drupal does take security seriously. The security team is an all volunteer group of individuals who work to improve the security of the Drupal project. Members of the team come from countries across three continents. The team was formalized in 2005 with a mailing list and has had three team leads in that time period. And the three continent parts sometimes means that we work around the clock. The sun never sets on the Drupal security team and you know, I'll be working on something and pass it off to someone in Australia, works on it, passes it off to people in Europe. And then I wake up and see what they've been doing. So that's the end of the introduction and you now get to choose the OWASP top ten or the column headers and as I said, four or five of them, I have filled in. We can talk about A01 broken access control, A02 which is cryptographic failures, A03, which is injection, which is sort of what I was borrowing from XKCD. I'm not prepared to talk about insecure design or security misconfiguration.

I can talk about 06, which is vulnerable and outdated components. And just to round out the list, those are the only ones I'm prepared to talk about. But to round out the list, identification and authentication failures, software and data integrity failures, security logging and monitoring failures and server side request forgery. So as I said, you get to choose from the four that I have prepared. And in one session, I usually have time to cover two of them. So where should we start?

STUDENT:
Are these in the order of their top ten? So one being the most critical?

BENJI FISHER:
Yes Or most serious. So it's a combination of how critical it is with how common it is.

STUDENT:
Like it did color in the very most. So what's the week one?

BENJI FISHER:
OK, A01, Broken Access Control. So this includes several types of vulnerability, such as information disclosure, edit or delete by unauthorized user or cross-site request forgery and more. What do I say on the next? OK, so let me just point out that one and two are basically failures of authentication for two different types of operations. So if you think in terms of the CRUD operations, create read updates, delete, information disclosure is when there's authorization failure for read and edit or delete are update or delete or I guess create. So the first two are failures and then authentication for those operations. I'll say more about what a cross-site request forgery is because see the CSF come up a lot. And you know, it means something specific. And yeah, we'll talk about it. So let me talk about horror stories. So one site that I was asked to look at decided for some reason that they needed custom access control for user edit pages. Like, user slash/1/edit. Why they thought they needed custom access control is beyond me.

But since they had it, I had to look at it. And when I looked at it, I realized they had left off a not. So instead of granting access to edit user one, just user one, they granted it to anyone but user one. Yeah. So and do any of you have horror stories that you'd like to share? Things you've seen in the wild from custom modules or anywhere else? OK. So how do you protect yourself from horror stories like this? How do you stop them from happening before they happen?

STUDENT:
You test it.

BENJI FISHER:
You test it. Yes.

STUDENT:
User two and try and edit user one.

BENJI FISHER:
So manual testing, log in to someone else, logging is an anonymous. You know you've written the access control, test the darn thing. An automated test would also be nice. So yeah, testing is one way. How else?

STUDENT:
(INAUDIBLE)

BENJI FISHER:
Louder, please.

STUDENT:
Have someone else take a look at it.

BENJI FISHER:
Have someone else take a look at it. Yes, we have a term for that. It's called code review. Both of these suggestions make one of the points that I like to make which is that anything you do to improve your code quality in general will also improve your security. OK, so code review, manual testing, automated testing, these are good for code quality in general. They are also really important for security. So what are the answers I wrote down? Code review, automated tests, you know what custom code you're writing. Make sure you test it. Question.

STUDENT:
Yes. When you install a module that has the badge, what does that mean? Does it mean is there a known protocol that the code (UNKNOWN)

BENJI FISHER:
So the question is I'm repeating for the recording. If you install a contributed module and it has the security badge, what exactly does that mean? And I should say settles easy to type. Please do feel free to interrupt and ask questions. So this is the badge we're talking about. I'm looking at a project page for contrib module C tools. It has the badge. Stable releases for this project are covered by security advisory policy. Look for the shield icon below. And in fact, every release listed on this page has the shield. Does that mean that the security team has reviewed the code and decided it's up to snuff? No. The security team does not have the resources to do that. The security team is mostly reactive as far as contrib modules go, people report issues to us. The module maintainers are responsible for fixing them. We help when we can, but we don't proactively go out and search for vulnerabilities. We don't actively go out and review full releases of modules. So at least one of the maintainers of the module has to have gone through the security review process.

And had one of their modules reviewed by some community member with an eye towards code quality, Drupal coding standards and security. And they've gone through that process and gotten the seal of approval. Back when I started, you had to go through that process before you could create projects on Drupal.org. And now the same process is used to give you permission to opt your module in to security coverage and get this patch. So I see you nodding your head. So I guess I've answered the question satisfactorily. So a third way to avoid this sort of horror story is don't write custom code. Use contributed modules which have been through code review which are open to the public. So they potentially have lots of eyes on them if they're popular modules used by governments and other enterprise clients that have the budget for it, then they've had security review by those customers. Use Drupal core, prefer doing things through configuration over writing custom code. I personally think that if customers knew the true cost of custom code, the maintenance burden, the security risk, they would ask for less of it or they might not just use Drupal in first place.

OK, so I promise to say what cross-site request forgery is. And the way it works is that mysite.com has an image tag. One way of doing it and the source is https:// example.com and some other site/node/123/ delete. And so what happens when an administrator, for example, .com visits mysite.com? They load this page. The web browser dutifully does a get request, loads the page for the image source and they load Node/123/delete. That is a cross-site request forgery. It's some elements, such as an image tag on mysite.com that has a link or a reference, an href or source attribute to a different site that makes it cross site. And again, the danger is that someone who has special privileges on the target site visits the site with that tag. So why doesn't this work?

STUDENT:
Because you don't have access.

BENJI FISHER:
Because you don't have access? Well, most people don't have access, but I happen to be an administrator for Example.com. When I visit this page on mysite.com, it'll load node/123/delete on the site that I do have access to. It still won't work. Why not?

STUDENT:
Maybe modern browsers just block that kind of thing I think.

BENJI FISHER:
Suggestion is modern browsers block that sort of thing. I don't think so.

STUDENT:
OK, maybe not.

BENJI FISHER:
You know, that sort of a hard question. Just looking at a link, how do you know whether that's a link to an image or to an admin form or what?

STUDENT:
If you're logged out on the target site, you're OK.

BENJI FISHER:
I'm sorry.

STUDENT:
If you're logged out of example.com, you would be OK.

BENJI FISHER:
OK, I might be logged out on example.com, but even if I'm logged in in another browser tab, it still won't work because Drupal has confirmation forms. And last time I gave this presentation, someone pointed out that many years ago on a different system and it might have been PHP BB just that's the error it was. Someone decided to have an admin page and for every piece of content, every blog post or every bulletin board post, they would have administrative links to publish, unpublish or delete. And then one of the browsers which back then might have been Netscape or Internet Explorer decided, OK, for convenience, we will preload every link on every page you visit. So one lesson from that is that you should respect the semantics of of HTTP and get requests should not change state. And a confirmation form is submitted with a post request, not a get request. So that's respecting the semantics. But then, this particular attack won't work. I cannot guarantee that nothing similar will work in Drupal.

I'm sure that security problems will continue to be discovered, but what sort of incorrect assumptions lead to this sort of vulnerability? Not sort of a vague, open-ended question. So I think the next slide, so use confirmation forms. Don't delete anything just on a get request. And sort of the assumptions are that when someone visits a delete form, they have clicked on a delete link. The assumption is that any page, any route you provide, you know how people got there and they're well intentioned. But that's in fact not true. People will tweak URLs, they will add, edit or delete to the end of the URL just to see what happens. They'll delete the last component of the URL to see what the parents page or directory is. Sometimes they'll do it just out of curiosity. Sometimes, they'll have an honest reason for doing it and sometimes they'll do it maliciously. On a similar note, don't assume that form requests come from the form that you created, right? You create a form, people click submit on the form and they go to the processing page.

When you build that processing page, understand that that's not the only way people can get there. People will try to craft post requests to target your processing page. Use CSRF tokens. So I won't go into too much detail there. I do have a link to the documentation page on Google.org explaining how to use them. But that's for example, when you submit a delete form, a confirmation form, it generates a token and then when processing the page, it validates that token and they have to match in order to go through the delete. And remember, that forms are hard. And getting back to what I said in the introduction, a web CMS from the point of view, security is one of the worst ideas ever. Forms are hard and you look at the Drupal form API has it's complicated. It is not object oriented. It has all sorts of annoying problems, but it has been through several generations of security hardening. And it does pretty well to prevent the common attacks. So one of the things I said in the description of this session is that I like to talk about how security problems are communicated.

So let's look at it particular security advisory or SA from 2021. Again, the link goes to the full security advisory or if you, for those who came in late, if you go to slides.benjifisher.info or maybe I'll quickly go back to the introductory page follow along. If you go to slides.benjifisher.info, that has links to all of my presentations, including this one, right. This is where I was. So the security advisory when this particular vulnerability was discovered, so project Drupal core, the date was 2021 September 15th. Security risk moderately critical, ten out of 25. And then there's this sort of gobbledygook which you can look up. I think AC is access control. So that's, and...

STUDENT:
(UNKNOWN)

BENJI FISHER:
Yeah, even I don't know. I know where to look it up. The A, the second one is access control and that's either do you need to have be logged in as an authenticated user or can you do it as an anonymous or in the other direction do you have to have special privileges. But basically, those components are what go into the score ten out of 25 for this one. Does the security advisory have a link to a further explanation of what those codes mean?

STUDENT:
Might be able to hover over it.

BENJI FISHER:
Yeah. As that presumably shows up on the recording, AC access complexity, A is authentication and so on and so forth. So yeah, there's information there. The vulnerability is cross-site request forgery. And there's a link to the CVE, Common Vulnerability Enumeration. I should learn that one. It's easily Googleable. And the text, the Drupal Core Media module allows embedding internal and external media in content fields. In certain circumstances, the filter could allow an unprivileged user to inject HTML into a page when it is accessed by a trusted user with permission to embed media. In some cases, this could lead to cross-site scripting. So basically saying someone could use a media embed field to create a cross-site request forgery. That's something in the page. And then an administrator visits that page. So it's not really cross-site, it's same site. And this is typically vague. We don't want to give you enough information that you can exploit the vulnerability when we announce it.

But it does say basically what went wrong. And the solution normally is to upgrade your version of Drupal. The solution, right, as I just said is to upgrade to the version released along with the security advisory. And the code fix, if you look at the solution is that when you're editing a WYSIWYG field with a media embed to add a CSRF token to the header of the jQuery request. So of course, when you're using the WYSIWYG field, you've got JavaScript involved and it's doing some sort of Ajax Request to update the page. So that's the request that has to be protected with with a token and then of course validate the token and the code that responds to that request. If you follow the link, it shows the actual code change. So this is some javaScript for the media module. And we're basically just adding an HTTP header to the request. And that's somewhere down here. We're generating the token or checking it. And it was this. Token equals that. Yeah, this is where we're checking the token. Don't wanna get too much into the detailed code.

So that's what I have to say about access control and cross-site request forgeries in Drupal. Any questions before we move on? Yeah.

STUDENT:
I have one question. So I'm just (INAUDIBLE)

BENJI FISHER:
A little louder please.

STUDENT:
Oh, sorry, would you qualify, like, using something like a URL alias as the added version of adding security? like because if you use an alias, you can probably change it so that a person can't just go in and delete part of the URL to figure out what you're carrying?

BENJI FISHER:
So is using a URL alias and added level of security. And the point is that if I don't use aliases, if I just make my pages node/123, someone can add /deletethat and maybe it'll work whereas if they're using the alias to page and they add /delete, I suppose that might defeat some attempts. I think that by default, Drupal puts the...

STUDENT:
Node ID in the body parts.

BENJI FISHER:
The node ID, I was going to say in the header of the HTML, it has a canonical link which I think has the note ID. So I don't think that using aliases is going to be give you too much protection. Any other questions? OK, then let's go back. And choose the second stage of our adventure. And let me do a time check. It's 9:48 and we have a full hour, but I'm not supposed to use the full hour, right? So, yeah, we should be able to cover a second one. If you wanna go by list, number two is cryptographic failures. Although injection is more fun and vulnerable and outdated components is more actionable. So I've given up...

STUDENT:
Injection.

BENJI FISHER:
Say again?

STUDENT:
Interjection.

BENJI FISHER:
Interjection. You mean injection?

STUDENT:
Yeah.

BENJI FISHER:
OK. So A03 injection. So in earlier versions of the OWASP top ten, they had separate categories for SQL injection and various JavaScript injections. And they combined all of those into this category in the current revision. So the official definition is that user supplied data is not validated, filtered or sanitized by the application. So again, that's what what we borrowed from XKCD in the introduction. Dynamic queries are used directly in the interpreter. Hostile data is used within search parameters to extract additional sensitive records. Hostile data is directly used or concatenated. So yeah, again, it could be a SQL query that has user data inserted unwisely. It could be a PHP command or system call that includes user data insecurely various ways. And the worst case to date of injection in Drupal was SQL injection came in 2014. The official name is SA-Core-2014-005. Do you know the common name for this? OK.

STUDENT:
Drupal again.

BENJI FISHER:
Yes, this was Drupal garden. And the procedures were a little different back then, but if you subscribe to the mailing list, you got an email on Wednesday, whatever data was. I think it was like Aprilish of 2014. Drupal seven includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks. A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. This can lead to privilege escalation, arbitrary PHP execution or other attacks. This can be exploited by anonymous users. So I remember when I read that email. And there was a bit of luck involved because I subscribed on my personal email account and I didn't normally read my personal email while I was at work. But I was, I don't know, bored or tired. For some reason, I was reading my personal email and I read this and my jaw dropped. And my response, this is from memory. So it's not verbatim, but I wrote an email to my boss and to the client and I said, because of the severity of the vulnerability and the simplicity of the update, we tested and updated the site today.

So it's a good thing I did that because within seven hours of the announcement, there were automated attacks in real life and I got my fix in within those seven hours. I was pretty pleased with myself, although, as I said, there was an element of luck involved. So let's have a look at what the fix was. In my email, I talked about the simplicity of the fix.

STUDENT:
This was the entire fix.

BENJI FISHER:
This was the entire fix. And you might have to read it twice to see what the change was. See it?

STUDENT:
Yeah, it's inserting array values.

BENJI FISHER:
So before iterating over this array as key goes value dollar, eye goes to dollar value. Before iterating over it, we're going to apply array values. So now, instead of whatever string keys were supplied, we're just going to have integer keys. And then in that for each loop, we are concatenating dollar i, the key from the dollar data. We're concatenating that with some variable dollar key which comes from some other place in the code. And the problem is that dollar data is user supplied. We are processing a form. And no one ever expected those string keys of the array to be tweaked in strange ways. We made the common mistake of assuming that when we're processing a form, someone submitted our form and didn't modify it. And I wrote at the bottom comments snipped from both. So this is just the code change. So yeah, I was pretty comfortable applying that change and updating the site. Didn't think it was going to break anything which is an important point that security patches go to great lengths to avoid any disruption.

STUDENT:
We typically for security updates, we don't really test. We'll do a quick glance at the test environment. Just make sure there's no way it's been a death or anything. When we look at the depth of changes, usually a little bigger than this, but you can see it's usually, you're putting wrappers around the static CSL or very little things like that. And I think it's nothing that would change.

BENJI FISHER:
So for the recording, I'll summarize that, someone in the audience says that they don't do much testing when the security update comes out, and that's the idea. So if you're already on the current version and don't have any pending updates, it should be pretty safe to apply the security update. So yeah, install it. In your testing environment, make sure you don't get an immediate white screen of death. Sure. But consider bypassing your usual complete QA routine when applying a security update. It's probably not necessary. We did fail recently. The language switcher update from a month or two ago. We failed in making it non-disruptive. But we try. So I actually think that although the fix was in that line of code, the actual problem came a few lines later in the code. And here I've added line breaks for readability. This was actually one line of code and the query is a p-reg replace. We take dollar key and sandwiched in between some delimiters for p-reg and then we implode the array keys inserting commas.

And we do that replacement in the query. And that single line of code comes with a seven line comment. And that's just doing too much in one line. And this gets back to what I said that the things you do for code quality are also good for security. And this was not good code in terms of readability. If you can't read a line of code, you can't verify that it does what it's supposed to do and it might introduce a security vulnerability. This should have been broken down into two or three statements. That's my personal opinion. And, you know, maybe if it requires seven line code comments, that's a hint that it should not be a single line of code. So that's all I have to say about SQL injection. But I guess that's good because it's almost 10:00 and I do wanna leave a little buffer at the end. So any questions about injection? There are other types of injections. Yeah.

STUDENT:
Could we go back to the previous slide and take a look? So to understand what key is in the code fix, would that be starting with zero because we're now dealing with an array of data compared to what key would be in the vulnerable code?

BENJI FISHER:
So let's see. I think. So the question roughly is what is the relation between the variable dollar key in this line on this slide with the variables on this slide, is that a fair summary?

STUDENT:
In the relationship between the vulnerable key?

BENJI FISHER:
Yes. And how has it changed? So let's see. This line of code is defining the new keys array. And it uses the variable dollar key, which I think doesn't change. So this is defining new keys. And the keys of new keys are after the fix. They're going to be something we control key and something numeric whereas previously, the keys were something we control, concatenated with user supplied data. So it's really the keys of the new keys array. Yeah.

STUDENT:
How would that have been user supplied? The first example. And what I mean is maybe could you walk us through like if an attacker was putting data in a form, is that how they would exploit the vulnerable code?

BENJI FISHER:
Yeah. So if I remember correctly, say it's the user login form and you have the field of name and you have the field of password. And it involves sort of tweaking the forms so that instead of a single name, you had an array of names as if there were multiple values there. And then doing some some further dastardly stuff there so that when you submit the form, the array is certainly not what we were expecting. And it had somehow injected some string keys that had some malicious code in them. So anyway, this slide, the line of code that changes is the line of code that defines dollar new keys. And then the variable dollar new keys is over here. We take array keys of new keys. So exactly the things that got fixed. And we're imploding those and then we're doing some p-reg replace on them.

STUDENT:
It's my understanding the array values function. I don't remember off on my head, but it sounds like it just throws out the current keys and just assigns the number, basically.

BENJI FISHER:
Yes. So we have array keys on this slide. We have array values on this slide and that's exactly what it does. It throws out the keys that were supplied. And re-indexs numerically. OK. Any other questions? OK. So I think I should go to wrap up. So conclusion. I'll just repeat the summary. We talked about what is the OWASP Top Ten and what is Drupal? We covered A01 and A03. And we're now in the conclusion. And here are some references. There's a link to my slide decks. This is the most recent one at the top, April 27th 2023. That's today. And my source files. So if anyone has any interest and wants to contribute, I would love to have help filling out the remaining six columns. It's all in the GitLab repository. The source is basically markdown files and images. A link to the OWASP Top Ten and the 2021 version of the OWASP Top Ten Drupal security team page. Drupal Core Release cycle. It's sort of important to know the difference between a major release, a minor release, a patch release. Security releases are always patch releases.

And that also talks about what the schedule is, which is also important. I have a link to the security advisories where we communicate about. That problem is the most recent one is from last week. Yeah, it was last week, April 19th. And the problem there was that certain private files could be accessed without properly checking. There was a mistake in how we checked access for them. And I could say more, but then they would boot me off the chain. I have a bias towards Drupal core. I sometimes forget that there are thousands of contrib modules out there. This slide is here to remind me that there are various contrib modules that will help with security. One is the security review which basically gives you a checklist. Have you done this, have you configured that? There's the paranoia module. I think that was more important for Drupal seven than for Drupal eight, nine, ten. But it guards against PHP eval from the web interface. Such a bad idea. Like the PHP filter. Terrible idea. The security kit which helps you configure various HTTP headers and other things such as content security policy, origin checks to prevent cross-site request forgeries.

It helps prevent against cross-site scripting. Guardr, I say on this site it's a Drupal distribution with security in mind. I think they're trying to move away from being a distribution to being a module or a set of modules that you can install independently. And that gives you a starting point for more secure configuration. The two factor authentication module for many years since Drupal eight was released, it was in Alpha. And it finally has I think a full release for Drupal nine and an RC release for Drupal Ten. Is that where we are now? An alpha release for Drupal tens, but a full release compatible with Drupal nine. And I am pretty optimistic that they will have a full release for Drupal ten before Drupal nine goes end of life in December, or November actually. Question.

STUDENT:
Yeah, I was curious. Could you go back to the two factor authentication module? Yeah, I was curious your thoughts on this seems to be like a common theme with big contrib modules right now with Drupal ten readiness where a lot of them are not protected by the shield yet are still in alpha beta status. I just wanted to note I was curious of your thoughts on like, you know, what's a reasonable or good timeline for us Drupal nine developers to get our sites to Drupal ten.

BENJI FISHER:
OK. So the question is given that many modules still don't have full releases that are compatible with Drupal ten, what should we as site maintainers do when our sites are on Drupal nine? And should we be upgrading. What should be our plan to upgrade to Drupal ten? So some practical advice is that there are a bunch of considerations when upgrading to Drupal ten. And some of them you can do while you're still in Drupal nine. So a big one is seek editor. And you have to make a decision. When I upgrade my site to Drupal ten, am I going to stick with the Seek editor five module that's in core or am I going to install the Seek editor four module which is now a contrib module? It used to be in quartz. Now contrib. And you know, probably in the long run, you're going to want to convert to seek Editor five and you can convert to seek editor five and Drupal nine, they're both in core. So, one thing you could do right now is upgrade from seek editor four to seek editor five. I haven't actually done that.

I imagine it's not simply a question of disabling one and enabling the other. I suspect there are complications there. And yeah, that would be a good thing to do now. Now get you ready for Drupal ten. If you haven't already switched to PHP 8.1, you can have some fun doing that while you're still on Drupal nine. I have gone through.

STUDENT:
We've found that that's more work than Drupal 10.

BENJI FISHER:
Yeah, someone in the audience agrees.

STUDENT:
(UNKNOWN)

BENJI FISHER:
Yes.

STUDENT:
In our experience.

BENJI FISHER:
So someone in the audience agrees that that the PHP upgrade is a bigger deal than the Drupal upgrade. I got a Drupal seven site onto PHP eight. It was not fun. It took a while. Let me say one more thing on this subject. Static analysis will not catch all the problems. So that's some practical advice. When it's time to go to Drupal ten, you just have to make your security decision. Am I going to install a module that only has an alpha release. But is compatible with Drupal ten? Am I going to go through some composer cheats to install the Drupal nine version on my Drupal ten site? Maybe that'll work. Do I have the resources to help the module maintainers get their issues fixed so that they're comfortable making a full release? Do they have a plan issue for what they need to do to get from Alpha to a full release? Does that help?

STUDENT:
Thank you. You're welcome. Yeah, the two factor authentication module. I think the state of Massachusetts uses it. So there are some big players using it. I expect it will get the attention it needs before November. So sooner the better. And, oh yeah, and one other thing, the jQuery update module. So I actually helped a little bit on this. So now has a full release for Drupal seven and I did a code review and filed a couple of issues shortly before the 4.0 release. And it was sort of crazy that you had the choice of using the version of jQuery distributed with Drupal seven which has no problems or installing the jQuery update module which was until a few months ago in Alpha. Maybe it was beta, I forget. It certainly didn't have a full release until a few months ago. So yeah, that was a bad situation, but that's been resolved. So questions, you've already been asking questions. And last side on my deck is the copyleft. Ooh. (APPLAUSE) And I, 10:12. My timing is good. Push the big red button.