Nice to see you. Nice to see you. Introduce you as we go by. Peter Robinson. It's Josh Gilbert. Nice to see you. Thank you. Nice to see you. Nice to see you. Good to see you. Good to see you. Nice to see you. Dan Parker. Ta-da! Hi. Hello there. Carol Hayes. Nice to see you. Rowena H. John. Nice to see you. Kathy O'Connor. Nice to see you. Donna Toronto. Nice to see you. Howdy Roads. Nice to see you. John Dongeback. Nice to see you. Kim White. Nice to see you. I had a feeling that I was seeing some people on the level here that I've been seeing. Not too many people you can look up to, but there are two of them. All right. Well, I think I'll come back here with you. I know we're going to make a squeeze-in closer together. We're going to have a lot of that. We're going to shut that away. We're going to have ladies who can get in. Some of the women are over here, so we're not going to step in right by that. I need to have the lady in the red suit come over this way. Ben, if you would come in just a little bit closer, please. I need it if Nancy and I have to come in. Okay, everybody come on in. Last time I had an act like this. We want to hear the ladies. We want to hear your ladies' style. Can you get to the seat? Can I see everybody? Ready? Thank you. All right. Thank you. Thank you very much. I did want to say something about this in the group picture. If anyone's concerned, you can go around me. Thank you very much. Many group pictures in Hollywood just would fight to get on the end. Most people think the center is the place to be. Finally, somebody pinned him down. Why? Pretty logical. They always begin in the caption, beginning from left to right. You're going to read the whole thing. I always get my name. What did you mean by that? Why? I have a reputation for Irish stories. I've been passing them on. I've been passing them on. The one about the little Irish priest during the war was so anti-British that his sermons were always digging the British and finding the Bishop said, I never interfere, but we're at war now. There are allies. Certainly you can stop venting your wrath at the British while this is going on. So he did not have another word about it. Finally came Easter. He had his Easter sermon ready. And he said this morning in Easter, he said, I'm going to preach to you about the last supper. He said it was the last supper, and he said it was disciples. One of you here this night will be training. He said, I repeat, one of you here this night will be training. And up spoke Judas Iscarii. He said, if I sign out, gentlemen, you don't mean me. You don't mean me. Thank you. Okay. Thank you very much. I don't think I can press it on because I can't put the twist on it. The accent. Well, it's good to see you all. Good to see you all. Mr. President, we have just a little bit of a result basically. We need to do one more if we don't mind. We need to do just one more. Thank you very much. All right. Yes. Is there my wife over there? My daughter Kathleen in California. Oh, there. And her daughter Sidney. My daughter Ann. Ann. And her daughter. Sid. She's only going to see the cameras. My son-in-law, Catherine A., and my daughter's... Hello there. Mr. President. I think you and you are going over to Paul C. Miller. The recognized international authority on matters of military and diplomatic ceremony. Paul C. Miller has devoted 45 years of service to his nation. A prisoner of war and twice injured while leading combat troops during World War II. He completed a distinguished military career in 1960 before becoming the director of ceremonies and special events U.S. Army Military District of Washington. Through his leadership countless White House, state, and other official events of worldwide significance have been executed with great skill and unparalleled precision. Presented at the White House on this day by President Ronald Reagan. Thank you, sir. I'd like to say one thing. Thank you for electing my wife, Sid. Thank you, God. Thank God we have enough to demand Ronald Reagan elected President. Bless you. Thank you very much. Thank you, ma'am. Thank you, sir. I think maybe we ought to go back and get a family. Thank you. Paul, I've lost you. That's great. That's great. Okay, that's the... That's the shortest number we have. Number nine? Well, here, Mr. Suit in ear, suit. I'll forget it. You're very welcome. Yes. You have a career of service, and I've seen some other numbers of them more than the same thing. Thank you, sir. Well. Why don't you start the loan? I'm sorry. Does he live abroad? Hello, Mr. President. These are my parents, Eve Iveney, George Iveney, sister Loretta, my emolace, Betty O'Donnell, and Bob O'Donnell, Mr. President, and my brother and sister Laura Romney and Mike. We have a lot of, a lot of, a lot of people. I'm sure it's you and Mrs. Iveney. Oh, okay. All right, thanks. All right. At this date, the view of his nomination by the President and confirmation by the Senate for promotion to the rank of Lieutenant Colonel of the United States Army. Okay. It takes pleasure in awarding the Defense Superior Service Medal to Robert R. Iveney. Major Robert R. Iveney, United States Army, distinguished himself by exceptionally superior service as Army A to the President from July 1984 to June 1986. Major Iveney continually displayed superior leadership, exemplary foresight, and tireless effort which were of paramount importance to the President and the nation. In his highly visible position, he routinely planned and coordinated numerous events of national and international significance. His role as the emergency actions officer for presidential travel was accomplished with expertise and professionalism. Major Iveney served as the White House agent responsible for supervising the use of Department of Defense resources, supporting Commander-in-Chief travel throughout the world. His performance as the military coordinator for the 1985 Economic Summit in Bonn was particularly noteworthy and contributing immeasurably to the office of the President and effectiveness of the White House military office. The distinctive accomplishments of Major Iveney reflect great credit upon himself, the United States Army, and the Department of Defense. Major Rotten is departing to command the first squadron of the 3rd Harvard Cavalry Regiment, Fort Bliss, Texas. Thank you, Mr. President. It's been both a privilege and an honor to serve you for the past two years, and I just want to say that it's been an education as well, and I only hope that I can take with me to Fort Bliss all the traits of leadership and concern for others that you've shown here, so I appreciate it very much. I would also like to say a thank you to my wife, Mary Ann, and our children, who have put up a lot of absences and have been a very supportive family. And last, I have to give a note of appreciation to my parents, who 40 years ago had the courage to leave Hungary and to leave Europe to find a new wife in the United States of America. Certainly, if they had not done that, I would not be here today. Well, now, how about all of the family coming over and surrounding us here? Brian, we're a first-generation here. Well, if we could maybe just get the IDs first, then we'll be about as good the O'Donnells after that. May I have you come in just a little bit tighter, sir? Thank you. Mr. President, you can stay here. Okay. I'll be right back. It's late arrival. It's probably what you mean now for the group. Okay. One of the eights, second lieutenant of the Academy, but I did have to remember the one of my first assignments in World War II was the handling of the commissioning direct from civilian life, from technicians and people on up through the writing and directing ranks and pictures that were far above any draft possibility rating, but would be willing to accept direct commissions in the military reforms and tasks in line with their work. And I thought about that when I was painting these on because there I was a second lieutenant and I was painting even some of those on direct civilians, direct commissions to major a lieutenant colonel, and then I had to tell them how they wore the uniform and how to salute them, and then I had to start saluting them. I hope I can remember that. Quiet, Mr. President. Thank you. Thank you. Thank you, sir. Sorry to see you go over. Yes, sir. Go ahead. Thank you, sir. Oh, my God. For the... Oh, my God. For the... You know, it goes in great jars filled with jelly beans. Oh, my goodness. It would not have been opened before you were in... Thank you, sir. For the families of what arena. For us, for the women. Thank you. The great joy of being sorry. You'll also be. It's okay to do. Good luck to you. Thank you so much. I'm so glad to see you. It's good to see you. It's nice to see you. Thank you, sir.


My name is Jackson Dale. I work for Ernest and Young. I'm the digital experience team lead in Sydney. Absolutely stoked to be here, so obviously just the quick spiel of our EY. We are putting a large amount of investment into Drupal at the moment and you can see that through our acquisition of Adelphi Digital, which is where I came from last year. That was around about November, so we're celebrating our one year anniversary at the moment. Through the acquisition, we can now say we've delivered over 100 GovCMS projects and Drupal projects. We have 40 plus developers all across the east coast of Australia and I think just last week we went live with the Department of Foreign Affairs Smart Traveler site. It's awesome. It shows the capability of the GovCMS platform and how you can do some cool things, integrating with Amazon's Pinpoint, I think it's called. Pinpoint? I've got the right to have my pinpoint, yeah. Doing some awesome subscription services in that sense and I think just over a week now it's got about 15,000 subscribers, so pretty cool things happening there. I have the pleasure of introducing Jess, who has taken eight flights from Wisconsin to be here. So, Jess boasts a pretty impressive resume in Drupal. She's been at the forefront of the community for many, many years now and she's one of two core Drupal release managers and I think I speak for a lot of us when I say that her work and the security team has made us sleep a little bit more soundly at night. So, in this talk, Jess is going to explore how Drupal 8 core has made its way off the island by leveraging industry standards like semantic versioning, package management, third party libraries and other external tools and how these changes will affect Drupal 9 and even Drupal 10. So, without further ado, I'd like to welcome to the stage Jess. So, just a note before I get started, I ask that people not take photos of me for privacy reasons. If I see a camera pointed toward me, I have an automatic response where I'll sort of flinch and duck out of the way, maybe hide behind the furniture, maybe hide behind the nearest person. So, don't do that, it's distracting. So, yeah, as you said, my name is Jess and I'm XJM on Drupal.org. I'm part of a team of about a dozen Drupal core committers who review everyone's core patches. The 12 of us are the 12, 13, something like that. We're the only ones who can actually accept changes into the core project. Now, within that committer team, I'm one of the two active release managers. The release managers are responsible for creating the Drupal releases that you can actually install on your sites each month, as well as setting schedules, evaluating the potential disruption of changes, managing scope, and so on. I've helped coordinate all of the releases we've had for Drupal 8 to date and I've personally, as he said, rolled the majority of the security releases myself. So when your Drupal site says security update required, you can probably think about me saying hi. I work for Acquia and I'm part of the awesome Drupal acceleration team there. Our team works mostly full-time on Drupal core. So the title of my session is Security, Drupal 9, and Navigating the Changing Web Landscape. The internet is a very different place than it was when Drupal 7 was being developed back in 2009 and 2010. And I'm not talking about multi-channel or machine learning, personalization, or headless setups. I mean a fundamental shift in the way that Web Software is developed, packaged, and released. I'm talking about the widespread adoption of GitHub. I'm talking about modern package managers like Composer, NPM, and Yarn. These shifts have affected how we develop Drupal and they affect what we need to do to keep Drupal site secure, now and in the future. So I'll first briefly introduce what we changed in Drupal 8 and what we're changing in Drupal 9. I'll go over how our dependencies affect our security process. We'll take a look at Drupal 8's specific PHP and JavaScript dependencies, along with a peek at the future of JavaScript in Drupal. And finally, I'll close with some lessons for secure package management that are applicable both to your sites or applications and to Drupal core. So let's first take a look at what we already changed in Drupal 8. One of the most important changes in Drupal 8 is that we actually schedule our releases now, yay! And we follow semantic versioning to add new features in minor releases without breaking backwards compatibility. Now back in Drupal 7 days, Drupal was ready when it was ready with no new features available until an entire major release was ready to ship and no major release shipping until those features were done. Starting with the release of Drupal 8 though, releases are scheduled and announced in advance and we ship whatever features are ready by those minor release dates. Now one of my responsibilities as a release manager is setting the schedule and making sure that nothing puts a release date at risk. Each minor release of Drupal core receives six months of active bugfix support, followed by six months of security coverage only. Another important change with Drupal 8 is that we've adopted modern best practices and tooling. You may have heard that Drupal 8 depends on symphony and twig, for example. Overall, there's a lot more third-party code in and around Drupal 8 compared to previous Drupal versions. Now we manage and package these third-party PHP dependencies with Composer, which is basically the industry standard at this point. Also, during the Drupal 8 release cycle, we refactored or we wrote basically everything in Drupal core. There's code maybe in the batch API that hasn't changed in more than a decade and hook system's still around, but other than that, Drupal 8 is pretty drastically different from previous Drupal releases. We also released Drupal 8.0.0 before the data migration path from Drupal 7 was ready, because we wanted to give new sites a chance to build on Drupal 8 while we were still finishing that migration path. And while the data migration path for monolingual sites has been stable for a few releases now, we're actually still working on the last few issues to stabilize the multilingual path. Public service announcement, if you have a Drupal 6 or 7 multilingual site, we would love, love, love, love, love you to try help us test the multilingual migration path. You can ping me in Slack or quiet one in Slack is actually the person who's probably most interested in that right now. She's one of the migrate maintainers. So even given all that with the migration path, despite the fact that there are a lot of improvements in Drupal 8, even as of 8.0 and much more now as of 8.8, which is going to be released next week, it's still been a slow process for existing sites to adopt it. That's snarling tazzy devil. So with all that in mind, let's take a look at what we're going to change in Drupal 9. And the answer is not much. Happy quacka. We want to keep innovating, but we don't want another difficult upgrade. So following the release of Drupal 8.0, we've adopted a continuous upgrade path, which is a concept we got from Symphony. When we want to improve something now, instead of rewriting things wholesale, we add the new code in minor releases while leaving the old code in place. And then the old code is simultaneously marked deprecated with a link to the replacement. This means that essentially we're building Drupal 9 in Drupal 8. It also means that module developers don't need to wait around for Drupal 9.0 to be stable to make their code compatible with it. They can just move away from the deprecated code on the schedule that works for them, and then their code base will actually work with both Drupal 8.0 and 9.0 at the same time, which is something that Drupal Core supports for the first time ever now. Now, our target release date for Drupal 9.0 is June of 2020, about six months from now. We have fallback dates in August and December in case we don't make that schedule. A long-term support version of Drupal 8.0 will also be released at the same time, and that'll probably be 8.9. So Drupal 9.0 will be exactly the same as 8.9, except for two things. The deprecated code that we've accumulated since Drupal 8.0 will be removed, and our dependencies will be updated to new major versions. Upgrading from Drupal 8.9 or 9.0 shouldn't be much more difficult than upgrading between minor releases is now, so long as you keep up to date with deprecations. Now, about two-thirds of Drupal sites are still running Drupal 7, partly because of the difficult upgrade path I mentioned, and partly just because Drupal experienced its steepest growth during the early years of Drupal 7.0's production support. We took all this into account and decided we needed to support Drupal 7.0 much longer after Drupal 9.0's release, so it'll be supported until November of 2021. Even if you're on Drupal 7.0 now, the best thing you can do is update your site's latest version of Drupal 8.0. That's going to become Drupal 8.0 this next week, which I will be tagging from here in Tasmania, by the way, first minor release from the Southern Hemisphere, so you can work on updating your sites to that, and that'll prepare you for Drupal 9.0. Just keep away from deprecated code. So take a nap, relax, Drupal 7.0, you've still got several years to finish that upgrade. So the deprecation process and continuous upgrade path actually mean that this upgrade, this Drupal 7.0 to 8.0 upgrade, should be the last difficult upgrade you have. If we do it right, the continuous upgrade path should make it so that in the future, major updates are much easier. Now, since Drupal 9.0 is just essentially a continuation of the Drupal 8.0 series, we're actually ending up lifeing Drupal 8.0 at the same time as Drupal 7.0. In November of 2021, in this case, because that's when Symphony 3, which is the major version of Symphony currently used by Drupal 8.0, will also reach its end of life. So I've promised you that we schedule our releases now, and that releases are predictable. So fast forward to November of 2021. Drupal 7.0 will have received almost 11 years of support. Drupal 8.0 will have had about six years. The end of life for Drupal 7.0 is a pragmatic decision we're making based on trends in the ecosystem. But the end of life for Drupal 8.0 is directly in response to the end of life for Symphony 3.0. And that's going to become the new normal with our dependencies influencing our major release schedule. So when will Drupal 10.0 be released, and when will Drupal 9.0 be end of life? It's a complicated puzzle to solve, and it depends on our dependencies. So now we're going to take a closer look at Drupal's dependencies, package management, and dependency security, and think about how these things affect both your sites or applications and Drupal's future. At the end of the day, the reason we have dependencies is to save work. We reduce the amount of code we have to maintain ourselves, with the goal of increasing the overall code quality and maintainability of Drupal as a project. People use Drupal to build powerful websites with robust data modeling. That's what we're good at. So why should we also spend our time and energy writing code to interpret HTTP requests or run automated tests? Other projects have already done those things better, so let's use their code instead. That said, though, using third-party dependencies also adds new challenges to maintain Drupal and keep it secure. To explore the question of how our dependencies support and security affect us, I'll first give some brief background information on Drupal's own security policies. Drupal practices coordinated disclosure, which is defined as a security model in which a vulnerability is disclosed only after a period of time that allows for the vulnerability to be patched. The goal of coordinated disclosure is to prepare fixes and allow sites a chance to update before giving potential attackers information that could be used to exploit the vulnerability. To facilitate coordinated disclosure, Drupal security issues are reported in a private issue tracker. We release each fix with a security advisory during predefined security windows on Wednesdays, or actually, I'm sorry, very, very early Thursday morning here. And we make the security fixes themselves as non-disruptive as possible. The goal of all of this is to allow people to apply security updates immediately at a predictable time without worrying that their sites are going to break. Now, an important part of coordinated disclosure is actually coordinating with other open source projects. For example, back in May, we coordinated a release with typo3 and Joomla for a library all three projects share. We released the fixes on the same day with those two other projects because we don't want one project to disclose a vulnerability that could be exploited in another before the fixes are available for both. And this coordination with other open source projects has actually become a significant part of the work that the Drupal security team does. Among all the Drupal 8 security releases to date, one in three have involved our upstream dependencies, one in three. Now, this doesn't mean our dependencies are any less secure than Drupal core. Theoretically, all their things be equal. If we were maintaining the code ourselves, we'd have the same number of vulnerabilities. But it does have an impact on how we schedule and ship releases. When we have a vulnerability in our own code, we can review and test the fix ourselves in advance of disclosure. We can bundle multiple security fixes in a single release so that site owners don't have to apply so many security updates. When making a release for an upstream dependency, though, all that goes out the window. Hopefully, we'll find out in advance that a security release is going to happen for one of our dependencies, but sometimes we don't. Sometimes, we can work with the upstream project to set a coordinated disclosure date that works for us, but it depends on the project and it doesn't always work out. Sometimes, we get patches ahead of time, but even then, testing a private, unreleased patch against a composer dependency is complicated. We also can't stage the core release in advance for the upstream release. We have to wait until the upstream release is published, then retest it, tag it, package it, publish it all the day of the release. And finally, an upstream fix is more overhead both for us and for sites because we have to make more releases for fewer vulnerabilities rather than bundling multiple vulnerabilities on release dates that work for us. Another challenge we face with security vulnerabilities in our dependencies is how to ensure that triple sites are secure when dependency support cycles don't match our own. And I have an example to illustrate this. Back in 2015, when we released Drupal 8.0.0, PHP 7 hadn't even had a stable release yet, so we supported PHP 5.5 and 5.6 with our best effort to be compatible with PHP 7. In July of 2016, PHP ended its own official security coverage for 5.5. However, throughout 2016 and 2017, nearly 20% of all PHP sites on the Internet were still using PHP 5.5. Now, keep in mind some Linux distributions provide their own security patches for versions of PHP used by their long-term support releases. And in this case, PHP 5.5 was used by Ubuntu's trusty tar. Trusty tar had security coverage all the way until April of 2019 this past spring. So you can understand why a developer using that stack might reasonably expect their PHP 5.5 applications to keep working. At the same time, though, many releases of Composer packages around that time were starting to also require PHP 7. PHP 5.5 had no security coverage, and even PHP 5.6 was going to be out of security coverage soon. So in early 2018, we announced that we would require PHP 7, starting with Drupal 8.7.0, which came out in the spring of this past year in May. There was a risk in supporting PHP 5.5 for Solom because it meant we had an increasing number of dependencies on old versions. We were weighing that against the risk of denying 20% of all sites any security updates at all because you can't install an update if it adds system requirements that your host doesn't meet. Then, in the summer of 2018, months after we made that announcement about 8.7, we received a report of a URL rewrite and cache poisoning vulnerability that the researcher planned to disclose in August of that year. Now, my colleague Wim, no pictures, please. My colleague Wim researched the vulnerability, do you see how quick that was? Wim found that Drupal was vulnerable because the vulnerability was present in both Symphony and a couple of Zen framework libraries, including Zenfeed and Diatros, which are actually used by Core itself. So we collaborated with the security teams of all three of those projects, as well as the researcher who'd reported it, and came up with a disclosure date that would work for everyone, which was August 1st. We planned to release it as SA Core 2018.05. But then there was a problem. You can probably anticipate that there was a problem, otherwise I wouldn't be talking about this. Very late in the process, I discovered that Zen framework had also already dropped support for PHP 5.5 a year earlier in minor releases of their packages, despite that 20% of PHP sites were still using PHP 5.5 at that time. So we couldn't update Drupal to use the security release we'd helped coordinate because we didn't meet the PHP version requirements for it. Fortunately, it turned out that Drupal Core itself was only vulnerable because of Symphony. We weren't actually exercising the vulnerable code in the Zen libraries themselves. It was a near mess. What if Drupal had actually been using the vulnerable code in the Zen framework? We couldn't just drop support for PHP 5.5 during a security window that would have caused mass chaos and panic. When we have tried at the last minute to convince the maintainers of these upstream projects that have lots more audience than just Drupal, we have said, hey, you need to make a release contrary to your own release policies just for us because we're a special snowflake. Would we have forked or overridden the library's code and tried to backport a fix to the release that we were using? And then what if backporting had taken weeks or months? What would you have done then? The reporter was going to disclose that at a conference a week later. And then what about updating those packages if we had hacked them? So all this shows how important it is to keep dependencies up to date, but also the complications we have for doing so. So let's take a look at the specific composer dependencies that Drupal 8 has. What they're for, why they're there, and what managing them with composer means. I have some illustrations that my colleague and fellow security team member Cash Williams made at Drupal Con Seattle. This shows Drupal 8's composer dependencies as of our initial release back in 2015. The biggest segment here is the purple, which as I've said is symphony, our most important dependency. The green is Guzzle, our HTTP client. Guzzle replaced a single Drupal 7 function that had, this is true, an N-path complexity of over 25 billion. Arguably a good choice for our maintainability to adopt a third-party library for that. The yellow is a small library for validating email addresses. The orange is Doctrine, our annotation parser for plugins and such. Gray is Us, Drupal Core. The pink is the Zen framework stuff I mentioned earlier, stuff for parsing RSS feeds, plus Diaturals, which is our PSR7 implementation. And then squeezed in between that and symphony is Twig, which powers our theme layer. Now, fast forward to 8.7, which as I said was released back in May, and we have maybe a 30 to 50% increase in the number of dependencies in Core. The new salmon-colored stuff here is StackCores, which is the cross-origin resource-sharing library useful for headless setups. The typo3 far stream wrapper next to Twig is a library we added in a January security advisory to mitigate a remote code execution vulnerability in native PHP functionality. Finally, the blue stuff here being new is actually a little misleading. We have a dependency we've had since Drupal 7. It's just that before it was in a weird stale and slightly forked version. We had to do a security update for that back in January for that remote code execution in native PHP functionality. So in 8.7, we fixed it to be an actual compulsive dependency, so we could manage it more easily in the future. Now, of course, your typical Drupal site runs a lot more than just Core. And every could trim module is another dependency on the site and might bring its own dependencies with it. Even a simple distribution can add a lot. So this is the diagram for Lightning, which I don't feel bad showing you because it's an Aquia product and I know it's well maintained. Lightning is a starter kit for a basic Drupal site with some Aquia integration support baked in. And even this starter kit is already quite the tangle of dependencies with over 100 things there. This is even without any advanced features like commerce or anything. And when you start building a site on top of this with additional modules and packages, it's easy to get to many hundreds of dependencies. By the way, Lightning had the fewest of the distros that Cache presented to us in Seattle, so just keep that in mind. So few organizations could audit this much manually. Oops, wrong way. So this brings me to some of the drawbacks of using Composer. Some of these are general problems with any package manager, others are specific to Composer itself or Drupal's implementation of it. The point of a package manager is to not have to worry about upstream dependencies or version conflicts. When you install a package, the package manager will helpful pull in the project's dependencies and its dependencies, dependencies, dependencies, dependencies, and so on. So you might not actually know what you're installing or who owns it. This can cause some of the release management challenges I've already described, where there's difficulty balancing stability and security. But it also makes it that much easier for you to install something you never intended to install in the first place that might break your site or even contain malicious code. Information about the Composer dependencies also isn't surfaced anywhere in the Drupal user interface that way the module information is. Our related problem is that there's a disconnect between the security services that Drupal provides and the security of Composer packages that contributed modules or site owners install. Something you might not have thought about is that Drupal.org is actually a package registry specifically for Drupal projects, and it provides robust security features. Rich metadata about releases, built-in security reporting, push notifications, and coordinated disclosure across thousands of projects, all centrally facilitated by a volunteer security team. Think about that for a second. For core, we update our Composer dependencies when they have a security vulnerability if core itself is vulnerable. But that doesn't help you with vulnerabilities exercised by your own code or in modules you've installed. Unfortunately, Composer also lacks any form of built-in security auditing or monitoring. In fact, it lacks any concept of security releases whatsoever. There are some third-party tools in libraries that try to work around this by tracking CVEs or declaring dependency conflicts with insecure versions, but it's all opt-in, not always up to date, and really no substitute for native functionality. Also, the vast majority of Composer packages are maintained on GitHub, which so far has no public mechanism for private-issue reporting. This means that vulnerabilities often get discussed in public before they're fixed, which prevents coordinated disclosure. Although I will say that just recently, GitHub did introduce beta features for a place to add your security policies and a way to create security advisories, which are helpful that will influence the Composer ecosystem in the long term. So those of you in the room are JavaScript developers. Might think that it's kind of adorable that I just spent multiple slides for, like, 10-plus minutes talking about the perils of having a few dozen Composer dependencies. The modern JavaScript ecosystem is different in a way that terrifies me. And not just because my JavaScript coding skills peaked in about 2003, although I will admit that is also a factor. Before we talk about the future of JavaScript in Drupal, let's talk about the past and present. These are Drupal 8's production JavaScript dependencies as of 8.8. Several of them are deprecated in 8.8. Those are the ones that have a strike-through on the slide. And then the two highlighted in pink are new in 8.8, and I'll talk about them more in a little bit. I can't show you any fancy illustrations of this because right now, Drupal Core doesn't use a package manager for our JavaScript dependencies. They're just committed to Core straight up in an Assets folder. So 13 years ago, jQuery was committed to Drupal 5, our first-ever JavaScript dependency. JavaScript in 2005, how innovative. Later that year, Farbtastic was added to allow the Garland theme's colors to be customized. I need a quick show of hands here. Who all remembers the Garland theme? A lot of Drupal old-timers in the room. Go team! Now, 10 years ago, jQuery UI was added to support accessible modal dialogues in Drupal 7. This is when Drupal starts to look more like the Drupal we recognize today. Now, all three of these JavaScript dependencies are still a part of Drupal 8 Core today, even after more than a decade. Then the rest of the JavaScript dependencies here, like Backbone, CK Editor, and Match Media, were all new in Drupal 8. Now, these 18 or 20 total packages doesn't seem that bad, right? Like we were talking about 50 composer dependencies before. The trick here is that without a package manager or proper test coverage, updating these libraries is both tedious and risky. And frankly, a lot of the JavaScript both in these libraries and in Core itself is pretty legacy, which adds to the maintenance burden. The list here is also a teensy bit misleading, because jQuery UI there with the yellow asterisk accounts by itself for 38 separate libraries that Core exposes. So, let's take a closer look at our history with jQuery and jQuery UI, the most tightly coupled JavaScript dependencies we have. We'd really hoped to upgrade Drupal 8 to jQuery 3 before Drupal 8.00, but it was still only alpha at the time of our initial release. In fact, a stable version of it wasn't released until June of 2016, the next year. By May of 2017, jQuery was no longer providing any security coverage for anything below jQuery 3 at all, and they were publicly disclosed security vulnerabilities with jQuery 2 that they said they would not fix. While Drupal Core itself wasn't vulnerable to these issues, at least one contrib module was. Plus, there was some kind of problematic documentation on Drupal.org that made a suspect custom code out there was probably vulnerable as well. And we were at least as concerned about other possible vulnerabilities in the future. Exploits in the wild, public disclosure with no support from jQuery, sites hacked before we could mitigate it and so on. So given all of that, we decided we needed to do a major version upgrade for jQuery as soon as possible. Overall, because of compatibility issues with jQuery 3 and especially with jQuery UI, it was more than two years from when we first started making jQuery 3 compatible with Drupal Core at the time of its alpha release until we were actually successful in 2017. And even once complete, this update had downsides. All of the compatibility issues we had to deal with then went on to affect sites, themes, modules, custom code. Wrong way again. So this was one of a couple things that made Drupal 8.4.0 in particular a disruptive minor release. Actually breaking people's stuff and disincentivizing them from upgrading to a secure release of Drupal. Weighing that against the very real risk of sites being hacked while you're stuck on jQuery 2, it was a tough call. It's a common misconception that semantic versioning doesn't allow a major version update of a dependency in a minor release. Semantic versioning actually only covers your project's own API. But still, major version updates of dependencies in minor releases are not what people expect. Ideally, we'd only do such updates in major releases of Drupal. But on the other hand, as you can see, other projects release cycles and schedules don't always make that possible. And overall, if we do need to break sites, we'd rather do that in a regularly scheduled minor release when people can plan ahead for the disruption rather than in a security window when people can't plan ahead. Since that time-consuming dependency update two years ago, we've been using jQuery 3. And then in April of this year, it was announced that jQuery 3.4 was the last minor release of jQuery 3 and that jQuery 4 development was underway. It's 46% complete. I updated this screenshot today. So here we are in almost the same situation with a major release of Drupal coming up soon. On the other hand, jQuery UI hasn't seen any further development since the last time we updated it. In fact, it's officially considered end-of-life now, which means there's no security support for it whatsoever. And if jQuery 4 was released sometimes in the next couple of years, this puts us in a tough spot. jQuery 3 isn't guaranteed to have security coverage after jQuery 4 is released, and we know that jQuery UI isn't going to be compatible with it because there's no changes being made to it anymore. But it is- jQuery UI is an important part of Drupal's user interface. It's not about the model dialogs, it's about the R-complete fields, among a lot of other things. So what do we do? What do we replace it with?  We agreed to start by deprecating the jQuery UI libraries that Core doesn't use itself and then moving those to contrib for a temporary VC layer. Then we researched and prototyped potential replacements for the library Core itself does use, looking for libraries that met our standards for code quality, maintainability, and so on. Now, since we had to complete our deprecations by the beta deadline, which was a few weeks ago, the final step for us is to fork the remaining parts of jQuery UI into Core so that we can patch them ourselves in case of a security release. And then we'll work to continue this replacement during the Drupal 9 minor release cycle. The goal is to have it all done by Drupal 10. Several of my colleagues and I worked on this over the past three months, we have a couple of people on the slide here, and we found a few good React-friendly libraries that we've added to Drupal 8.8 Core. Those are the ones that were in pink on the earlier slide. The last big project for us is to replace the jQuery UI dialogue, which is a critical user interaction and a critical point for site's accessibility. Replacing that is going to be a bigger project, one that we need to complete in the next couple of years. The issue is still open for discussion, and we actually love your help with that, and we're willing to work on bad old JavaScript code and convert it into new shiny JavaScript code. We have a lot of work to do before Drupal 10 still. So now let's talk about Drupal's JavaScript in the future. I teased this a little bit by mentioning React-friendliness on that last slide. Back in 2016, Dries announced that Drupal was going to adopt a modern JavaScript framework, and the JavaScript framework that our JavaScript contributors picked was React. One of the advantages of React is that it's well-maintained in the process, and we can be fairly sure it'll be well-maintained in the future because it's used and backed by Facebook. Now some of you might have feelings about that. It's in both the advantages and risks column for a reason, but at a minimum it gives us some future proofing. React also has a strict backwards compatibility policy and a deprecation process similar to our own. However, their major releases are more frequent than Drupal's, breaking changes every 18 months or so. It's also surprisingly difficult to find any information about React's security policies you'd think that would be on their website somewhere, but it's not. Presumably Facebook has incentive to keep both React and its upstream dependency secure, but I couldn't actually find any information at all about how to report a security vulnerability or how security is managed. What I see as the biggest challenge that we'll be facing, though, is actually more about the modern JavaScript ecosystem itself. There's a tendency for JavaScript developers these days to create these very small libraries and open-source them independently, which in some ways is great instead of installing a monolithic thing you just pull in the one teeny-tiny piece that you need. And it's also cool that there's a thriving community of open-source development. Sometimes these packages can be as small as a single function, which brings me to the infamous LeftPad. For those who don't know the story, LeftPad was, is actually a little NPM library that adds padding to the left side of the string. Not the right side, mind you, only the left side. Back in 2016, for reasons I won't go into, the developer of LeftPad decided to unpublish all of his NPM packages. In doing so, he accidentally, single-handedly broke the builds of thousands upon thousands of packages, including React as well as Node and Babel. It was so disruptive that NPM themselves actually took a totally unprecedented step of republishing that package without the author's permission. Now most React app developers never deliberately installed this dependency and may not have even known it was there because it was at least four or five levels removed from their code. This incident highlighted the fragility and risk that's inherent in the large dependency trees that are common in the modern JavaScript ecosystem. Now there's a couple things to keep in mind about this story. First of all, the author of LeftPad wasn't acting maliciously. And secondly, while things broke, they broke in a clean way with a fatal error on build. So comparatively speaking, it was easy to discover, report and fix. But any NPM package might have security vulnerabilities or might even contain malicious code tucked away inside something that seems useful as a way of tricking you. And when your application has hundreds or thousands of dependencies, four steps removed from the dependencies you declare, your potential attack surface increases significantly. So according to the internet, if you use Create React app to start a new React project, you'll get 1,568 dependencies right off the bat before you've said hello world. Now, when people say this, React developers respond to point out that you don't have to use Create React app to build a new project. And obviously, since it's about creating an app, it includes dev dependencies. I couldn't tell if this was just fun. So then I looked at a project that's directly relevant to the future of Drupal. The Drupal admin UI project is a proof-of-concept that's being built by the JavaScript modernization initiative for a fully-decoupled Drupal front-end. It's built on React and uses JSON API to communicate with Drupal. As of June, I didn't check recently, but as of June, it had 1,732 production dependencies. So this problem of large dependency trees is a real thing, and we're going to have to deal with it in the future. Now, there are mitigating factors from a security perspective, thankfully. Unlike Composer, the popular JavaScript package managers like NPM and Yarn do include built-in functionality to audit all of the dependencies you have for security vulnerabilities. So one thing that's obvious to me is that this command is going to need to be a part of Drupal's regular workflow in the future. Keep in mind, though, that this is still only auditing known public vulnerabilities. I don't know how complete the list is. Probably depends on the project, and I don't know that there's any... Well, there certainly isn't any hope of coordinated disclosure windows and whatnot with, you know, 1,700 different projects. So something we're going to have to figure out is when and how or if we'll create security releases for vulnerabilities in Drupal's React app dependencies. Also, we have to figure out how we're going to balance stability and security with these dependency trees that change almost every day. So let's think about some of the lessons we can draw from all this, right? I think the most important lesson from our experience is just to be careful about external dependencies. They can add a lot of value, but they can also expose you to fragility, instability, and security complications outside your control. Every piece of software on your site is additional attack surface. The simplest thing you can do is to limit which dependencies you add in the first place. Only add them if you need them, and choose which you add carefully. Be sure to review your dependencies' dependencies, too, because those are also going to become a part of your application. Look not only at the functionality, but at the code quality, package policies, and release history. Another lesson is to keep your dependencies up to date and to address deprecations and breaking changes before a lack of security coverage becomes an issue. That said, you should also lock the versions that you're using so they only get updated when you specifically intend it. New versions can introduce breaking changes, as we've seen sometimes even in minor or patch releases. Plus, indiscriminately updating to new versions can also put you at added risk if one of the packages is compromised by a malicious actor. Think about which dependencies are needed in production, and limit the rest to your development environment. But keep in mind the development dependencies expose you to security risk, too. It's a common myth that dep dependencies don't need security process. They absolutely do. So keep them up to date, too, and consider a more secure development environment like a VM. Also remember that your dependencies mostly aren't covered by Drupal's security report, so be sure you're auditing their security. NPM and Yarn both have built-in commands to audit package security, but Composer, on the other hand, lacks any feature for checking security advisories. There are a few workarounds you can use. The folks behind Symphony have an open-source database of known vulnerabilities, as well as an automated checker that you can upload your Composer lock file to and audit it for vulnerabilities in that database. There's also a couple Composer packages that declare version conflicts with insecure versions of other packages, and that includes one that Webflow wrote for Drupal itself, which I definitely recommend using if you have a Composer site. Just remember that it's written and supported by Webflow, who's one Drupal contributor, it's not an official Drupal project. In closing, the last general lesson I'd draw, I made three words into one there, is that this is the new normal. Now, package managers in general aren't a new thing. Pear has existed since many of us could do singing impressions of our dial-up modems. What's changed is that we now have modern package managers that developers simply expect to use to build with projects with huge open-source ecosystems. I don't think we can or should put the genie back in the bottle. We still get a lot of advantage from third-party dependencies, and if we want to be sustainable as a project, we need to engage with other communities and meet contemporary developers' expectations. So we need to adapt and iterate on our best practices so that we can stay relevant and take advantage of the new normal, but also mitigate the risks therein. Before I wrap up, let me circle back to the question I posed at the beginning of the talk. Based on all this, how long will Drupal 9 be supported when will Drupal 10 be released, and what's the Drupal release schedule going to look like in the coming years? We want a major release cycle where each major version of Drupal is supported for as long as possible, because that's what site owners prefer. However, we also know site owners consider Drupal unstable if there are major version changes that break stuff in minor releases of Drupal. We've also learned during the Drupal 8 cycle that having external PHP dependencies adds pressure for us to use only the latest versions in support, only the latest versions of PHP. But at the same time, dropping support for PHP 5 and 5.5 and 5.6, there was a lot of work for us, and I imagine it was hugely disruptive for those site owners that were still using it. So we'd like to minimize how often we have to do that in the future. To figure out exactly what we needed to do before Drupal 9's release and how long we can support Drupal 9 afterward, we've spent a lot of time evaluating our dependencies, including talking to upstream maintainers to learn their plans. If we time our releases right and set each release's PHP version requirements high enough, we should be able to provide at least three years of support for each major version. It's a shorter period than Drupal site owners are used to today. And we're also still not sure what we're going to do about the end of life of PHP 7.4. For those who haven't heard, PHP 7.4 was just released as a stable version, I think, last night, and it's going to be the last version of PHP 7. The next release of PHP 7 is PHP 8.5. The next release of PHP is PHP 8. That'll be out next year, or so they say. And so far, PHP has not budged on extending the security coverage for 7.4 beyond three years, so it's currently scheduled to be end of life at the end of 2022. Other than that, if we can find a way to work around that problem, we think we'll be able to support Drupal 9 until probably the end of 2023, based on the other dependencies. And then based on that, my best guess right now is that we're going to want to release Drupal 10 as early as 2022, probably the middle of the year. That's soon, right? That's not that far away. Now, there's no guarantees about that date. But on the other hand, keep in mind, if we're successful with the continuous upgrade path, it shouldn't actually matter as much what the actual release date is. So that's all I have today. If you have questions, feel free to come up to me during the break or join the D9 readiness channel on one word in Drupal Slack. You can ask a question of the Drupal 9 contribution team there anytime. Thanks all for listening, and thanks to EY Digital and Drupal South for helping me get here. It's a real pleasure to finally be at this event. I've wanted to come to Tasmania for years. I've wanted to come to Drupal South for years. So I'm glad to be here. Thank you.


Hi, I'm Zor. Welcome to a new Zor education. We were talking about symmetry in three-dimensional space, basically two kinds of symmetry. One is central symmetry, which is symmetry relative to a point, and another was a reflection, which is symmetry relative to a plane. Now, what's important about symmetrical figures just in general? Well, they look alike. So, this lecture, which is a very, very short one, and actually trivial, is about what exactly is look-alike in the symmetrical figures. Well, obviously, we all know that symmetrical figures are almost equal. I mean, they are either completely equal in the terms of you can just put one on the top of another and they will coincide. Or they are, so to speak, symmetrical, like two different hands when you have to really, like, turn something around and then they will coincide. So, basically, that's what I'm going to prove right now, that in any kind of symmetry which we were talking about, we have this property of likeness. And in mathematical terms, it's called congruence. Well, in my young days, it was called basically quality. Nowadays, it's more customary to use the term congruence. So, two figures are congruent rather than equal, primarily because it's like two hands. They're not really equal, but they are congruent because you can do something like this. Alright, so a few mini theorems about congruence and symmetry. So, I have a few different kinds of proofs in this particular case. They're all about symmetrical objects and they're all very, very simple. So, let's just start with something simple. This simplest, actually. You have a central symmetry relative to a point and you have a segment. So, you reflect this segment and we know that the reflection, well, I should say symmetry relative to a point of a straight line is a straight line. So, a segment is transformed into a segment. So, these are equal and these two are equal. These angles are obviously vertical. Now, the thing is going on in three-dimensional space. However, if we are talking about a segment and a point, it's three points actually, two intersecting lines. So, everything can be considered as happening in the plane which contains a, b, a prime, b prime, and the center of symmetry. That's called p. So, in plane geometry, it's absolutely obvious that these two triangles are congruent because it's side-angle side, side-angle side. So, that's the end of the proof. Very simple, right? So, segments are, symmetrical segments are equal in lengths, basically. And as far as their position in the central symmetrical case, they are also parallel. So, that's my first theory. So, the central symmetry preserves the segment lengths. Okay, great. How about a symmetry relatively to a plane? So, let's say we have a reflection relative to a plane. And let me draw a plane, something like this. This is my plane of reflection. So, I drop a perpendicular from a onto this plane and extend it by the same lengths. Drop a perpendicular to b, from b to the plane. And this is my, and this is my image. And this is the result. Now, these are two perpendicular to the same plane. They are parallel, which means they align the same plane. So, again, I can consider the whole thing as happening in the plane, which contains a, b, b prime, and a prime. And incidentally, two bases of perpendicular, if you wish. And now, what we are talking about is a plane geometry theorem where I can just wipe out my plane of reflection, as if I don't have it. And I can consider the plane problem, which basically states that, by the way, these are perpendicular, because this is perpendicular to the whole plane, right? So, these are perpendicular, and these are equal to each other by construction. These are equal to each other by construction. And all I have to prove that a, b is equal to a prime, b prime, which is, again, a trivial task. I mean, how can we do it? Well, for instance, we can drop perpendicular here and here, which means now this is a rectangle. So, this is equal to this, and this is a difference between this and this. And it's exactly the same thing here. And these are also equal to each other, because these are equal to this one. So, we have two right triangles with two categories correspondingly equal to each other. So, obviously, the symmetry relative to a plane, the reflection relative to a plane, also preserves the lengths of the segment. Alright, two down. Next, we will have a little bit more complicated, but not by much case. Instead of a segment, we will use this transformation of symmetry with triangles. So, let's say we have a triangle, a, b, c, and let's say central symmetry p. So, we go with b to here, with c to here, and with a to here, something like this. Too much, I guess. No, that's not too much. Yeah, I think it's okay. This is a prime, b prime, and c prime. So, a, b, c goes into a prime, b prime, c prime. Now, these are equal, this is equal to this, and a, p is equal to p, a prime. Now, why are these triangles congruent? Well, because every triangle has three sides, every side is a segment, and we know that this segment is equal to this segment, this to this, and this to this, because of the previous theorem about segments. So, these two triangles are congruent by three sides. That's it. Now, the next theorem would be in exactly the same fashion proved about reflection of the triangle. So, if you have a triangle, a, b, c, and the plane of reflection, and we reflect it here, we will also have a congruent triangle because of three sides. Each side is a segment. So, side is equal to side, and we have congruent triangles. Next, so we can forth down. Next, too, will be about angles. Now, what I'm staging right now is that angles are also preserved by the symmetry. So, if you have an angle, which is actually like two rates, and you have a center of symmetry. Now, this ray is reflected into this one, and this is the vertex, and this ray is reflected into this one. So, if this is a, this is a prime, now this is line b, this is line c, this is line b prime, this is c prime. So, why angles are the same? Well, there are a couple of ways I can prove it. Well, first of all, we have already proven that lines are parallel in the central symmetry. So, in this particular case, we have two different angles with corresponding with parallel sides. So, that's one thing. The second thing is, I can just choose a couple of points here and here, have their symmetrical counterparts, and consider a triangle. Now, since triangles are preserved, the angles are also preserved, so this angle is equal to this angle. Now, this last approach with the triangle, I will use for reflection for symmetry relative to a plane. So, instead of this picture, I have again an angle and some kind of a plane, and I have a reflection of this angle, which is probably something like this. Now, it's all in three-dimensional space, right? So, again, what I will do, I will choose two points and make it a triangle, and this is my image triangle. And since triangles are congruent, the corresponding angles are congruent as well. Slightly more difficult is the last couple, which I would like to prove. This is more three-dimensional case. So, let's consider we have a dihedral angle, which means an angle between two half planes. So, we have some kind of a border. This is one, and how can I put it? Let me just do it slightly differently. I will use this. So, this is one plane, and this is another plane. This is my dihedral angle. Now, somewhere I have a plane relative to which I reflect this. Oh, no, first is a central symmetry. So, I have a point. Now, let's just think. We know that image of a plane is a plane. Image of a line is a line. The plane will be parallel, by the way, and the line will be parallel. So, in this particular case, this line would be reflected into this, this plane would be reflected into, I guess, this one, into this, and this one into something like this. Right? So, this is alpha, this is beta, this is beta, this is alpha prime. And this point is in between, center of symmetry. Okay. Now, how can I prove that these dihedral angles are the same? Well, here is what I can do in this particular case. Well, number one, obviously, I can refer to the parallelism. So, if you have two planes, two dihedral angles with correspondingly parallel planes, I can actually derive from this the quality of the dihedral angles. But probably I would choose something else, because I would like to use the same proof for reflection, where I will not have this parallelism. So, here is what I would do. So, here is the point, and obviously it's in here. Now, in one plane, I will do the perpendicular to the edge and in another. So, these lines are perpendicular to the edge, this line was in beta and this line was in alpha. Now, the flat angle between these two lines is actually a measure of the dihedral angle, right? Now, same thing here, perpendicular to this, perpendicular to this. Now, we know that plane angles are always preserved. So, the image of this right angle is this right angle, because it must belong to the plane, right? So, the angles must be equal, since it's just flat angles. So, this angle and this angle must be the same, since they are image of each other. Same thing with this one, also should be the right angle, right? So, they are also right angles here and there. Now, what I can do, I can use the triangle thing if you want to. Something like put a couple of points here, find their images here. So, triangles are preserved. So, all in all, what I'm saying is that all these elements, all these three points will be symmetrically transformed into these three points and everything about these three points supposed to be the same, including the angle between these two, which is a measure of the dihedral angle, right? So, let's do it again. So, I have this edge, I have the point here and this image, a couple of perpendicular here and there, here and there. And since angles are preserved, I can say that this angle between this line and this is the same as this one and this. And then, just again, two points in half triangles and equal to the triangles. Now, I can use exactly the same approach to have symmetry relative to a plane. So, if I have some kind of a plane, which is symmetrical, and now I have this, something like this. So, that would be my A, that would be my I alpha and beta. Same thing. So, first, so this alpha goes to alpha prime. So, this perpendicular should go to this perpendicular, this perpendicular to this. And now, I can choose a couple of points and the equality of the triangles will give me equality of the dihedral angles, exactly the same thing. So, I was trying to prove that basically all the elementary objects of 3D geometry, like segments, angles, dihedral angles, they are preserved. Now, as a consequence, you probably can think about that any complicated geometrical object, if symmetrically transformed, whether it's centrally symmetrical or reflection relative to the plane, it should produce something similar, well, congruent, actually, to the original. Now, why? The reason is very simple. Any complicated geometric object can be subdivided into more elementary pieces. So, all elementary pieces we have basically covered, like for instance, we have covered triangle, but we did not cover, let's say, pentagon. But, hey, pentagon can be divided into triangles, right? And therefore, the corresponding pieces of the corresponding pentagon will also be congruent piece by piece, and therefore the whole pentagon will be congruent. Now, if I have proven that dihedral angles, for instance, are the same, and all faces are basically the same, congruent in the symmetrical figure, then that actually means that the whole geometric figure, however complex it is, would be properly reflected, properly means congruently reflected into its image, whether it's a central symmetry or plane symmetry. Well, that was relatively short and relatively trivial subject of this lecture. I would suggest you to read all these proofs in the notes on theunisor.com. I think it's very helpful. Well, other than that, that's it. Thank you very much and good luck.


This research compares local changes in the extraction and non-extraction segments of first permanent molars that need to be extracted due to caries using radiographs taken before and one year after extraction. This article was authored by Asli Endertely and Sir Paladin.


Hi, everyone. Joe for jashby'scasewrakes.com coming at you with 2021 Panini Mosaic Choice Football. Two box picker team number four with the Patriots being given away. So if you follow the instructions here, if you buy at least two teams, you get one entry, four teams, two entries, et cetera, et cetera. And then we'll randomize those names and name on top gets the Pats. So that's our giveaway spot right here. Big thanks to Kevin for grabbing up the last handful of teams. Let's alphabetize by column A by your first names. Aaron bought two teams. That's an entry. Brandon H two teams, one entry. Brian C two teams, one entry. Dusty got four teams. That's two entries. Gail got two. That's an entry. Jeremy got two. That's an entry. Kevin got six. That's three entries. Patrick Evans two teams, one entry. Ryan two teams, one entry. Sean Matic two teams, one entry. Serenity two teams, one entry. I think Tim, Scott and Russell only bought one. Let me just spot check this really quick. So we've got Aaron, Brandon, Brian, Dusty, Gail, Jeremy, Kevin, Patrick, Ryan, Sean, Serenity. All right. Good luck. This is for the Patriots. So there's a one in 14 chance, one spot out of the 14. We'll get the Pats after three and a two five times. One, two, three, four. And good luck. Fifth and final time name on top, Ryan Cason. There you go. After five, the Patriots are yours. So we'll keep that little rooftop next to your name. Realphabetized by team and let's print and rip. All right. So one autograph per box on average. A lot of special parallels here. Looking for those those peacock parallels are really cool too. All right. So once again, final print out hot off the presses here on Monday the 28th. Thanks, everyone. All right. We've got Cinefeoco. Got Kyler Murray. Oh, and there's the autograph. There's Carson Wentz to 80. Minka Fitzpatrick to 80. And that's a Miles Sanders. Oh, Jason Jaspy might like this one. Miles Sanders peacock parallel. I really love these. Eagles. That's going to be for Scott. These look really sharp. Cinefeoco rookie silver for Dallas. That's going to go to Kevin. The Minka Fitzpatrick to 80 for Kevin and the Steelers. Carson Wentz. Blue horseshoes. That's going to be for Patrick Evans. We've got Javante Williams for the Broncos. That's for Jeremy Port and Cadarius Tony. Rookie card for Kevin and the Giants. Let's see if the new Giants coach 40 out of 80 can unlock his abilities. All right. So behind Kyler Murray, who I guess everything's okay with Kyler Murray and everybody else, it's Tredavious White Buffalo. So that is for Brandon Hall, the Buffalo Bills. I guess we might as well sleeve up everything. There's only eight cards for Box and Choice. All right. But wait, there's more. It's two box break. I've got Tyrell Davis, Silver. Michael Thomas to 80. Mark Andrews, 70 out of 80. Michael Thomas will go to the Saints. That'll be for Ryan. The Mark Andrews for the Raven that's going to go to Aaron. There's Brandon Iac, two out of 80 for Dusty and the Niners. We've got Arondale Moore for Brandon and the Cardinals, not numbered. And another rookie Peacock, Nashon Wright, Dallas Cowboys, Kevin Benedict, last spot Mojo. Is there a Peacock in each box? I don't think so. All right. There you go. And now behind Quinton Nelson for the Colts for Patrick is the autograph and it's going to be Tony Bacelli. I remember Tony Bacelli, nice offensive lineman for Dusty and the Jaguars. I want to say he was one of the first sort of, is he one of those first sort of modern day? Kind of ushered in the modern day offensive lineman. Big dudes who could like run like a 540 or something like that. All right. There you go gang. A nice two box break. We got more in the store so check it out on jazzy'scasebrakes.com and I will see you next time for the next two box mosaic choice break from jazzy's casebrakes.com. I'm Joe. I'll see you next time for the next one. Bye bye.


Hi everyone, Joe for jaspyscasebrakes.com coming at you with 2020 Panini Chronicles draft picks football, collegiate football. Eight box, random team break number three. You see all the big selection of teams right there. A lot of combos and whatnot. All card, you know I said all card ship and this as well, just too many inserts, all sorts of things going on in there. So big thanks to these folks for getting into the action. We'll assign you a team. I know it looks kind of jumbled but you'll see 21 items right there. So don't worry. Let's roll random, five and a one, six times. One, two, three, four, five, and a one. Six and final time. After six times we got David down to Wes. Five and a one, six times. One, two, three, four, five, and six. There you go, after six times we got Minnesota down to Alabama. All right, so David you got that group of teams right there. Thomas, Matthew, Shira, there you go. Cooper, Matt, Wes, Matt, Ben, Glenn, Steven, Wes, James, Wes, Rich, Rory with Ohio State, nice. He hasn't for trade by the way. Will with LSU, Rich with Notre Dame, Group, Wes with that group right there as well. There you go, Matthew, that's the rest of your teams right there. I know it's a little small on your screen but there's, I just wanna get that on camera. All right, so now while you're considering trades, let's pop this case open and let's see which half we're gonna do. James Johnson, what's going on? How are you?  One, two, three for the left side, four, five, six for the right side. Two, left side right here. Right side we will save for, I'm sure you guys, I'm sure Jason, guys and Jason will do this over the next couple of days, next day or two. So we'll put those Wolverine slash marks right there so we all know it's from the same case. All right, we'll flip back to the team screen. I'm gonna pause the video just for a couple seconds when we come back, we're gonna see if there's any trades and then we'll have the break when we come back, bye-bye. Let's pop it back, stick around. All right, welcome back, folks. There was a worry offered a trade, but no one wanted it, no one wanted Ohio State. There's the official printout right there, folks. I alphabetized by that first list of teams right there so maybe I can kind of spot it a little more easily during the break. All right, let's roll. Looking for these guys. Remember all card ships. So if I missed like a numbered card or something like that, I think they put all the numbers in different spots sometimes. Don't worry, you'll see it, it'll ship. Shipping team will catch it, it'll be sleeve and top loaded. I'll try to separate as much out as possible. I'm gonna separate out the bigger names though like Burrow, Tua, and Herbert. LaMichael P. Rine leads us off. Prism going with relics. Prism, three color patch and autograph. 77 out of 99, Florida will be for James Cook. I'm sorry, there's Tua right there. I'm gonna set these aside. Joe Burrow. Tua will go to Thomas who has Oklahoma. LSU is Will who has, he'll get the Joe Burrows, all the Joe Burrows that you see in here. Justin Herbert, Oregon, that'll go to Wes Thomas. All of those will go to Wes. And T. Higgins, 167 out of 299. Clemson Relic for Matthew Sheerah. And we've got from Florida Athletic, Atlantic, athletic, five out of 99, Atlantic. Is it Florida Atlantic? Let's see it on my list here. Yeah, Florida Atlantic Owls, there it is, Ben Butler. With the Harrison Bryant autograph. And we've got Van Jefferson, Florida Gators. That's gonna go to James Cook in Florida. A lot of college conferences figuring out when or if they can start. I think Ivy League backed out, right? I don't follow college sports too closely, but what's the temperature, folks? I mean, is college football gonna happen in the fall or not? I know, I wanna say that Pac-10, it's out here, it's just gonna go in or conference games only? I feel like everyone's trying to figure it out. There's Kishon Vaughn to 49. It's a cool look there, not Phoenix. I think Ivy League's just straight up said no, we're done, we're not doing it. SEC maybe is kind of marching along as if they're gonna start on time, but people on the inside maybe not thinking it'll happen. It's just USC's Michael Pittman Jr. at 299. I don't know what's gonna happen with college stuff.  So it's a little bit different from these pro players here. All right, there's John Hightower, Boise State. Seven out of 10, nice low number for Ben Butler and Boise State. These Joe Burroughs are numbered, yeah, they're not. And we've got J.K. Dobbins, Ohio State, that's Ferrari. Is that out of 10 gold? Look at this, four out of 10 on that one. Next box, and I know the boxes are off camera right here, but you can still see them in the top camera up there. This is Steve Trout of the Cubs. Does he make the all-fish team? Does he make the starting rotation of an all-fish team? Justin Herbert and Brandon Nyak. Fabric of the game, Relic to 299, going to Arizona State. That will be, that's Arizona Wildcats. That's, oh, that's paired with the Oregon States. That's for Wes Thomas, there you go Wes. That goes to you, and speaking of Oregon State, there it is, Isaiah Hodgkins, 95 out of 99. Conroyal die-cut autograph, there he is again. Tua, and Denzel Minves, Baylor. It's 18 out of 30 on that one. Baylor Bear, Wes Thomas, Joe Burrough, and we've got Zach Moss, three-color jersey, and autograph, a Yute, a Utah Yute. There's Utah on my list here. That goes to Cooper, Cooper with that one. Jake Greenland Hyper to 49, Justin Herbert for Oregon, and Jake from State Farm. All right, next box. Who do you think will have the most long-term success of these quarterbacks right here? For the sake of the hobby, I hope all of them. Even the ones drafted late too. Joe Burrough seems to have the classic composition of a good quarterback. Tua's a little more dynamic, but does he not protect himself enough? Oh no. We'll see. Benny LeMay. Okay, Ronnie's saying Joe might get hurt just due to a no offensive line, so okay, so. So both Tua and Joe Burrough may may have some injury concerns to be mindful of. Out of 299, LaVisca Chinalt Jr., Colorado. Buffalo. That'll be for Wes. And we've got John Hightower, die-cut autograph from Crown Royale Design. Boise State, that'll be for Ben Butler. Size and style concerns for Kyler Murray last year too. There's AJ Dillon, die-cut autograph to 99. But Kyler Murray seemed to protect himself fairly well last season. But people, from what little I know about college football, I think people are saying, he's got Boston College. Ben Butler is Boston College. People are saying, eh, Tua may not protect himself as well as Kyler would or does. And with his injury history already, that could be a concern. There's Albert Okwe Bonham. Three-color jersey and autographs, nailed it. Missouri, Missouri. That will be, his teams are all jumbled up. There they are, Missouri Tigers, Wes Thomas. There you go.  You think he comes back? Or what's the feeling out there? Or is he just done, done? I wonder if, I think he might come back 2021 next year. You know, when he can maybe do a workout, you know, post-pandemic, see how teams are shaking out. Daniel says, hard to choose, but I think it's going to be Burrow and Tua. Yeah, I guess the highest drafted ones will be the best ones. I don't know. I mean, say what you want about Dak Prescott, but there's some great value there. Dak Prescott being drafted so late. You know, could there be a surprise there? That could be interesting. And that's a out of five Deandre Swift for Georgia. That is for James Cook with a Georgia Bulldog. That's a great name for a running back. All aboard the Big Head Express. Woo-hoo. And we got Michael Pittman Jr. rookie silhouette. So some nice texture there to 25 USC. That will be for Matthew Shearer. Jilo says, Oklahoma, maybe sneaky good tight end. Not there. Went to school with Drew Locke and then got drafted by the Broncos. Interesting. All right, so maybe there'll be a relationship there already. Maybe good for the fantasy. Sending to a 99 Colby Parkinson for the XR design for Stanford. That will be for Matthew Shearer. I think luck just got frustrated with the injuries and his recovery. And I think he just kind of seemed like he was mentally frustrated. But if he could come back, couldn't he? I could see it. His card's all backwards here. There we go. Barrington Evans, 75 out of 99 for the Appalachian State and Mountaineers, Matthew Shearer. Yeah, Denver Broncos, my rivals, definitely, definitely, I guess Jilo's rivals too, but definitely upgraded and really got a lot of weapons for Drew Locke. Kind of put him in the best possible situation to succeed. Ooh, and a three out of four, wow. Lynn Bowden, Jr. Hopefully will be a big playmaker for my Raiders. He went to Kentucky. Where's Kentucky on my list? That is nice. Glenn Campbell, three out of four. By the time I get to Kentucky, she'll be rising. Glenn, all aboard the Big Hit Express. Woo-hoo! Excellent patch right here. Love that select look in the background. Good autograph. He can throw the ball, he can catch the ball, he can run the ball. I think John Gruden's excited about getting him into the mix. And then the Raiders got Henry Ruggs too, so Raiders also got some weapons. Chase Young, no, just a Chase Young card. James Proche, Joe Reed, 99, all right. Hi, Greg. Oh, did I not? If you didn't see, shoot us an email about that. Jaspy's casebreak.gmail.com so we can see that video. And then if we didn't do it, we can do a randomizer. Maybe Jason will do one tomorrow. But yeah, just shoot us a link to that video. Jaspy's casebreak at gmail.com. All right folks, almost done. Kind of running out of steam, but I think we just have a few easy breaks to do before I can call it a weekend. Thanks everybody for keeping the crew and I so busy all week long. Appreciate it. I think we've been having some fun. Hopefully we've been able to send you some stuff. It's Kishan Vaughn, rookie silhouettes to 199. Vanderbilt, that'll be for Cooper. Remember all card ships, so you'll be getting everything that you see here folks if they're on your team. Isaiah Coulter, that prestige design. I think Isaiah Coulter does not have a college associate he's from, he's Rhode Island. We looked this up a few times. Apparently, Panini got everybody's license except for the Rhode Island license. There you go. Yeah, that must be a typo. I think whatever's in the title is correct. It's a diamond icons giveaway. The Michael Pirine, 59 out of 99. Another Florida gator for James Cook. And AJ Dillon. Wow, that's a cool looking card right there. It's flashing. Nice specter design. Two color jersey and autograph for this Eagle. Seven out of 15. Ben Butler. Now, Boston College, they don't say War Eagle, right? That's just an Auburn thing. All right, two boxes to go.  Joe Burrow, I don't think any of these have been numbered. I think Will has them right now. I don't think any of these have been numbered, Will, but they'll all ship. K.J. Hamler, Penn State. I'll go to Rich. Darnell Mooney. For the Tulane Green Wave. Who's got Tulane? Tulane will be for Cooper. Cooper with the Green Wave. Darnell Mooney. And Zach Moss. Another Utah U for Cooper. Another Zach Moss. And a redemption. Who are the redemptions in this? It's gonna be Justin Jefferson. Spectra, draft picks, patch autographs, neon green. Justin Jefferson, Florida? Or is that Van Jefferson? Justin Jefferson, who is with the Vikings now, went to LSU. There you go. So I think that's Will Comstock on the board. There you go, Bulldog Van. Getting this tiger. He's a Mississippi State Bulldog. Just in case the viewers at home are wondering. All right, last box. How did people watch baseball back in the day? I'm watching a game from 1984. There's no score on the TV. The sides are blurry. The left and right sides are blurry. I don't know what the exit VELOS are. Just, yeah, score cards. That's probably what you need. You probably have to keep score. I guess this was a day when you were probably just paying attention to the game on TV and not checking your Instagram while you're watching a baseball game. Tyler Johnson to 199. Imagine just, imagine even back in the day, just waiting for the box score, the newspaper the next day. Come on. Minnesota with that one. That'll go to David. Primitive, the viewing experience is much better today.   They did it for like a Sunday game or something like that. There's Jacob Eason, maybe a Sunday day game, four out of 15. Die cut for Washington. I think they were trying to be clever and they'd be like, hey, the broadcast was like, that goes to West Thomas. Something, I think it was something like that. They wanted to show like the different, you know, eras. And I get what they were trying to do, which I thought was interesting, but I didn't want that during the whole game. All right. And the last one is for Rory. Two color patch and autograph, JK, just kidding, Dobbins. There you go, Rory. That is number to 25. So that neon green redemption probably to 25 as well. And there you go, ladies and gentlemen, a nice break, Chronicles collegiate or Chronicles graphics football is pretty solid actually. So check it out. There should be more in the store on jashbscasebreaks.com. I'm Joe and I'll see you next time. Bye bye.


So I have my first script done. I nearly finished with the second script. There's the train just as I start my voiceover. The second script is a little bit more difficult because I think it's a little bit more complicated. It's just going to be not sure a longer story but I'm trying to figure out how to cut it down a lot. Here are my thumbnails for this first section, first comic. I'm just going to do this even though you probably can't even understand my thumbnails. But what I've done is I've gone through and just laid down really roughly. Thanks Mochi, thanks for that. I've just laid down really roughly all the panels and I've been realising that maybe we just need maybe a couple more pages to help explain the story because it kind of goes from 0 to 10 really quickly. So I'm going to be working on that trying to figure out what I can put in between these sections to bring the story and make it more round. So these are the thumbnails and they don't make sense to you probably but you can probably see where I've just written notes and where I think some panels should maybe be exchanged because it makes more sense sequentially. Can you walk off Mochi? Yeah, so that's that done. Now I'm thinking what do I want to do developmental like creative concept art wise and I'm just doing some character designs here. And also I've been doing some like images of antiques and things like that because obviously in this first comic a picture of my is the name of the comic. I think although I'm not sure if it sounds a little bit too like innuendo because it's going to be a picture of my and then like my crossed out because she thinks it looks like a relative of hers but maybe it is maybe isn't. But yeah, I'm just doing some like design work at the moment. I'm really happy with this image. So what I did here is it's like watercolor and then my favorite Polychromos pencils on top but also alcohol markers. So it's a mix of like everything mixed media which is something I enjoy using. I really like the idea of playing with like the character a little bit more this time because I feel like my previous comics my previous comics. I think the design I like the design but I didn't really focus too much on the characters designs. I did like a little bit but I think I need to like just try a little bit more this time so these are the two women from these stories. And I feel like her design changed a lot throughout like the comic a little bit like I try to keep it consistent but maybe she doesn't I don't know. I think it's okay but I think I want to something I want to improve on definitely. So yeah, something really interesting that I was thinking about doing is because this is going to take place in an antique store. The beginning of this new comic is what I was saying so I've been looking at like designing antiques and stuff. And I always like to do like an end paper. So this one was like the house and then I liked having these two portraits. Maybe I have a portrait of the characters, the main characters of these ones as well to like kind of continue on with these designs. One second in Emily is burning. I did these like end pages of this pattern, which I really liked. So I was thinking what I could do is have a pattern or an end paper of antiques or like bits and bobs. So there's this, like there's loads obviously online on Pinterest and stuff with grifting objects and things. But I was thinking maybe I could do something like this where they have like just you know when you have a flat lay of like different items. And I thought this would be really cute for like the beginning page or something even though it doesn't the book isn't really you know focused on antiquing or anything like that. But it's mentioned in the beginning and that's what she does to find this picture. So I thought it could be really nice. I don't know what you guys think. I'm also like working on style. I think what I like to do at the moment is work with, well it's not watercolor, it's gouache, but I'm using it kind of like watercolor because I'm just like watering it down. And then going over the top with pencils and alcohol markers. And just yeah I think this is kind of the vibe that I'm feeling for these ones because in the other comics I obviously just did all alcohol markers with pencils and I feel like it does. I really do like that style like I'm like the way the colors pop but I'm kind of feeling using this style maybe for this one. I don't know I'm kind of you know expanding my style a little bit because these ones are like more pencil like Emily is burning is definitely more I can definitely see more texture like more pencil work. I don't know maybe that's a lie because in wishing on a star there's loads of pencils and stuff. So it's always been I've always worked with media so as long as I keep the style kind of consistent with these ones it could work as like a set of comics that you could get from me. I don't know it's just my idea at the moment and I'm really enjoying it and really enjoying the process and trying to take it slow like I said a little bit slower than I did with these ones. But I don't know I'm working obviously as well so I get a little bit burnt out so I'm trying to take it easy because burnout is real and obviously I have to just if I can feel that like burnout phase coming I have to really take it slow and I don't know if it's the same with you guys. I haven't finished just one but this is kind of like just I did a whole base of watercolours and I was going to draw like a whole town and just do pencils on top. And I kind of like the way it looked it's like really texturised and it's just a rough like a rough example of something that I might look into doing but I'm not sure I'm not sure I do really like the way that the alcohol markers look with the pencil so it's tough to like make a decision. Here's some preliminary work that you probably saw in the last vlog but I'll just show you again this was just like ideation for me I when I first have an idea for a comic. I don't know I just drew this out and I was like oh what if like a girl goes into an antique store and sees a picture of someone who looks like a family member who could look like your mother or her grandmother or something. And what if she like then goes and shows her mum on the phone who maybe lives somewhere else so she couldn't come in contact and it just it's blurry on the phone and then what happens if she leaves the frame and things like that so that's kind of what this progression was. I started out just drawing like different houses on Pinterest. And then I drew like a girl and I was like oh that's kind of nice and yeah and then I drew an antique store because I was always thinking I want to do a story involving antique somehow and I also have a picture of. I think the original idea came from I have a picture of my parents at their wedding and it's a really old frame and it like broke a little bit so I put it back together. And it's just like having that idea because obviously I think even my mother put this frame together or my granny so it's like the idea of somebody doing that and like putting the papers in I don't know spark something in me. But yeah that's kind of where the idea came from and then I wrote out everything roughly like story beats and then I typed it all up on the laptop and like I said if you went here for the last blog or any of my stuff. I write out the pages so I write page one and then I write each panel that's going to show up on the page and then it gives me a clear picture of how roughly like how thick the comic is going to be and how much work I have ahead of myself. And then it also helps me to kind of figure out the layout of the pages when it comes to the thumbnails which are here like I said. So yeah it's coming along. This one is definitely coming along the water park one which I'm so excited about. I do need to work on that a little bit more. I need to come up with kind of how it's going to end and finalise. Sometimes I have the ending really clear in my head of where I want to go and sometimes it just happens so I need to think about it a little bit more. But to be honest I haven't really spent that much time focusing on it so I'll be more focused on this one but I'm going to. I'm going to so we'll have like maybe a collection. I'm thinking about doing a Kickstarter for them this time so yeah that's me. That's basically it and I hope that you guys enjoyed this video. Super casual super just showing the process. Maybe you guys are making your own comics. Also people always say that these kind of help them to make comics. So that's always like a really cool outcome for me doing these videos. So I hope that you like this more relaxed version of these videos and well hope to see you next time. Bye.


I thought I told you to send me an email of the Spring Sale! What in my desk? I want to leave my email, my eyes, and feel technologically advanced for paper! Full suits! What is our margin on these things? 20% out for boots. Gloves! And wetsuit hoods. Sunglasses are not on sale! The shoes aren't either! But something better is! Surfboards! Used ones! You buy one! And you get one! Half off. You buy one and get a whole one? You select ones.