And now the moment you've all been waiting for, the presentation of class of 2021. I'm pleased to introduce my colleague, Professor Shobita Parthasarathi, who when she's not test-defined before Congress, is writing and teaching about ethics, equity, science and technology. And she's gonna read the names of our 2021 graduates. Shobita, take it away. Thanks, Luke. Good afternoon, everyone. To begin, I'll call graduates earning doctoral degrees. Kiara Ferreiro is receiving a Doctor of Philosophy in Public Policy and Economics. She'd like to thank her dissertation chair, Jim Hines and her committee, Yusuf Negers, Joel Slamrod and Ashley Craig. Her dissertation title is Essays in Public Finance and Political Economy. Michael Lerner is receiving a Doctor of Philosophy in Public Policy and Political Science. He would like to thank his dissertation chair, Chuck Shippen and Barry Rape. The title of his dissertation is Does Transnational Advocacy Catalyze Environmental Policy Leadership? And finally, Stephanie Owen is receiving a Doctor of Philosophy in Public Policy and Economics. Her dissertation chair is Sue Danarski and the title of her dissertation is Essays in the Economics of Education. And now we'll celebrate our graduates receiving a Master's Degree in Public Affairs. Dominic Ariano, Ethan David Baker. Anna Balser. Carly Bolware. Ann Colonisi. Tom Cruise. Lindsay Dowswell. Stephanie Ioven. Haley Juris. Raymond Kahn. Jamie Lyons-Eddie. Christopher Bryan McLean. Rebecca Ostash. Julia Rhodes. Anuj Sahay. William Scott Sileski. LaMieh Sherftzanova. Jamaica L. Thomas. And William Whelan. Next, we'll recognize our graduates receiving a Master's Degree in Public Policy. Rebecca Ackerman. Rukia Emelid. Malik Ali Anani. Monica Anderson. Jonathan Ashken. Leonime Amantado. Capri Bacchus. Maggie Barnard. Adithya Benjamin. Ali M. Berry. Sharon Brown. Chris Campbell. Linnea Carver. Christian Casanova Velarde. C.D. Cheng. Allison Christensen. Samuel Thomas Conturat. Rebecca Copeland. Osha Cowley-Shireman. Kellan Dotta. Carolina Dominguez. Chad Dowding. Jerome Durden II. Nishat Farzana. Kevin Finnegan. Yanjing Fu. Omeya Ganpule. Steven Garcia. Eli Gold. Sarah Gruen. Shiyu Guo. Sophia Hart. Wendy Hawkins. Balthazar Hernandez. Samuel Ainsworth Herd. Sung-Wook He. Cassania Husak. Kyle Douglas Jarrett. Jacqueline Khan. Maxwell Kaufman. Emma Kern. Jae-Yun Kim. Sun Hong Kim. Heather Kinningham. Andrew Krantz. Jocelyn Kuo. Chris Laflore. Barton Linderman. Tori Lowy. Diedrich McCord. Safiya Merchant. Eric Muliawan. Landon Myers. Ikra Nasser. Kevin Nodd. Megan Schroeder O'Leary. Nathan Ojo. Akinlolua Olumarati. Tanya Omolo. Guy Packard. Sharanya Pai. Edwin Pert. Lauren Alexandra Pesach. Sasha Rose Phillips. Avril Erika Prakash. Carolina Ana Ramos. Yvonne Riz. Victor O'Chieng Ruten. Kristen Jade Richardson. Sarah Richardson. Matthew Rigdon. Jonathan J. Rodriguez. Danny Rosa. Hannah E. Rosenfeld. Julie Rubin. Orlando Sanchez Zavala. Anna Santiago. Mariam Saeed. Matt Cersuini. Alex Surware. Risky Odie Putro Sitompo. Mariana Smith. Thomas Staines. Kai Su. Eleanor M. Sullivan. Yaya Sun. Nitha Sayod. Jessica Takeda. Kalena Tomhave. Sarah Treseter. Sarah Truax. Amy C. Turner. Maize Yang. James Van Steele. Connor Wakayama. Alex Weaver. Miquel Hunts Weiss. Kelly Wilcox. Lisa Wilder. Wanzuo Yang. Triana Jensen. Toro. Mohamed Akbar Zadran. Jingwen Zheng. And finally, we will celebrate the students receiving a Bachelor of Arts in Public Policy. Baha Abazid. Leah Adelman. Cameron L. Banks. Hilaal Bazi. Mariana Buji Perez. Bennett Bramson. Mary Bryce Brannon. Anthony Bowie. Sabrina Butcher. Connor Kane. David Carpenter. Damian Cesare. Miriam Chang. Julia Cohn. Jordan Jane Cole. Meredith Winston Daze. Samantha Delafera. Brady Diller. Lena Dreeves. Jack Eichner. Jackie Erlan Berjan. Riston Escher. Sydney Gardner Brown. Molly Gariantes. Michael Elizabeth Gothrup. Benjamin Gerstein. Leah Graham. Maximilian Grail. Erin Crawford Grant. Aroshi Gupta. Grace Herman. Nora Kate Hilgart Griff. Dylan Horwitz. Jonah Dylan Jacobs. Lauren Jarisla. Molly Edersheim Cowell. Amanda Kaplan. Grace Kent. Daniel Kim. Daphne Krieger. Alex Kramer. Marita Key. Tal Lipkin. Caroline Loog. Lucia Lopez Allys. Michael Elliott Lovegrove. Matthew McPhail. Camille Liliana Mancuso. Kelly Martin. Julia Esther Mati. Kerrigan McKay. Madeline Teresa McLaughlin. Erin May. Mandelena Mihailova. Katherine T. Miner. Jason Munka. Karuna Nandkumar. Bennett Newhoff. Summer O'Sullivan. Devin O'Toole. Michael Antonio Ocasio. Eric Pearley. Angelica Priest. Allison Marie Pujol. Connor William Wohen Ries. Alexandra Shadkosh. Sarah Sarnak. Julia Skavnicki. Julia Siegel. Nicholas Silk. Maeve Ann Skelly. Lauren Michelle Solomiani. Trevor Stratz. Zaina Syed. Eliza Sykes. Martin Taksay. Mikaela Udvok. Claire Vapnek. Jacob Viviano. Matthew Weiner. Ryan Wook. And Brett Daniel Soslawski. BA graduates, at this time, please move the tassel on your mortarboard from the right to the left. And now I'm so, so proud to present to you the Gerald R. Ford School of Public Policies Classes of 2021.


Awards! Pride of the Yankees! Pride of the Yankees! Pride of the Yankees! Yeah! Standout performances. Standout performance. I'm going with Aaron Judge. Um. Smart. Some weekends. Some weekends. What? Some pods, it's not worth slap-dicking around on it. Yeah. Let's do it, people. Buckle in. It's Aaron Judge. Wow. Bias much? So bias. He's now leading Major League Baseball in home runs. He is hitting mammoth 468 tonight, very casually, hanging curveball, worst pitch in baseball. 455 in the second game, only 376 in the first, so that one almost doesn't count at this point. Second games with a homer, six in his last five. This has been my speech. If you don't watch Yankees baseball, I kind of get it.  That's probably what you think he does. It's not. He's five-tool. He's a star of this game. He could become the face if he stays healthy. Look at his stats. Like it's not just home runs. It's on base percentage. His batting average is pretty nice for a dude his side. His defense. If you like some defensive analytics, go check out Judgy and Jim. It's been a lot of OPS on this show so far. I need to get into the baseball reference new stat head thing or whatever. I think Aaron Judge has the second highest active career OPS in baseball right now. Of guys that have played two, three plus seasons. It's Mike Trout. Then I looked after that. I mean, Votto was kind of up there.  Poulos. Yellich. Bats. They kind of had slower starts to their career so that brings their number down. Aaron Judge has been nothing but special since he's come up. With a couple weird injuries while he's played, he is really good. Since the start of last season, 17 of his 30 home runs have given Yankees a lead. It's 57 percent and it's gone up now with this game. Right. No, no. Yeah, they were tied. Tied. MLB average rate is 31 percent. Like, there's a lot of people that still say he's not clutching stuff in and I actually don't believe clutch exists in the regular season. But he does in the postseason too. Yeah. So. He's really good.  And right now he's doing it. He made a nice little shoestring catch today and the double up. The double up. He's, he truly is five tools and obviously small sample. He's played eight games, but he currently leads the league in runs with 10 home runs with six RBI's with 14 slugging at nine or three OPS one dot two seven five and two 49 OPS plus and 28 total bases. Yeah. All those lead the league right now. And the Yankees had, however many games canceled. So I guess it's deservedly so. He is the pride of the Yankees for me. Thank you. That's clapping for Judge, but I'll clap for you as well. Oops. Houston Yankee stuff. Do whatever you want with this. Knowing what we know now, Aaron Judge would have an MVP award under his belt in 2017. Yes. Think about how that would change the perception of him. You know? Yeah.


Appalachian Wireless is transforming the way you upgrade your smart phone. Trade in, trade up and experience the benefits of Appalachian Wireless's trade-in program. Get your estimate on AppalachianWireless.com now. Better service and bigger savings, that's today's Appalachian Wireless. It's getting us ready for those circumstances where we may have to respond in tactical situations where there may be a hazard or a threat to us or the public. There's multiple agencies represented here. Not only the City of Papua, but there's City of Painsville of American National University. They have their paramedic program here and there's also people here from West Virginia and all over the state to take this class today. It's always a possibility. We hope that it never happens here, but any event that it does, we can always be ready.


Yn gyfan, wrth adored yn cyfnodd, mae'n ffais edrych o ran amwINE I'm in the Nova team at Red Hat, and Red Hat has an upstream first policy, and Tristan is in the Upstream security team and, it's the first time we've worked together on a few security bugs ago, but the first time we worked together Felly y ferson wedi bod gyda'r bobl, nid eich bod dri ni wedi gweithio cydyntgaid ar gyfer y rhwng. Diolch yn ddiddordebau byddwn yn metodol. Rwy'n fail o'r schyffr hwn. Byddwn yn ysgrif iawn o'r llwyffaeth, mae'n golygu i'r hollol i'r hollol. Rwy'n credu hollol o'r hollol, ond y llwyffaeth yn hollol i'r hollol i'r hollol i'r hollol i'r hollol. Mynd y hollol â'r hollol i'r hollol, rydyn ni'n golygu'n gwahanol sy'n mynd i chi'n gwahanol. If you would like a full copy of the presentation, then by all means email myself or Tristan at the end will send you a copy. The other thing is at other conferences I've been to there has been somewhere to upload slides to. Does anybody happen to know where we're supposed to upload slides to? No. OK. Well, as soon as I get a nagging email that would be fantastic. As soon as I find out where it is I will upload the slides there. But I couldn't find it when I was looking at it before. The other thing is the detail of this talk is really in a couple of external URLs which we will give clearly on the board. So you can go look at those. The first one is this one which is nice and phone friendly for you. This talk is about the vulnerability management team process which we're going to call the VMT process for short. As I was saying before everything in this talk could really be inferred from the documentation. Go to that website. It documents the whole process really well. All we're really going to do is talk through a specific instance where we followed this process with a specific security bug. In doing that we hope to add a practical flavour to what is by design a very nice boring reliable process. We'd like to introduce you to some roles and responsibilities that you're going to encounter whilst going through that process and maybe introduce some design decisions that were involved in constructing the VMT process. So this presentation will talk about vulnerabilities. Vulnerability is a weakness which allows an attacker to reduce a system information assurance. It's commonly referred to as a security bug or a CVE bug and indeed it's a special type of bug that needs extra attention because of its potential negative impact. Vulnerability management, it's about assessing the impact and severity of a bug report. It's about designing security patch following a process and respect the role of lesser disclosure. Lesser disclosure, it's about disclosing the vulnerability details to an increasing number of people over time but only to the people required to reach the next step. So we're going to be using this diagram throughout the talk and this is the VMT process and you'll find the original version of this diagram on the link I gave you earlier and this is exactly the same diagram just reformatted slightly. But to summarise, way at the top somebody reports a bug and then we've got two streams. Over on the right we've got what an engineer does. So an engineer works on a fix. Over on the left we've got what the VMT does. The VMT ensures everything is properly documented and coordinates with all relevant parties. And then we get to embargo disclosure. So at embargo disclosure we provide the fix early to certain critical users. And then we get to public disclosure where we open the bug to everybody and the fixes are released. So why do we follow this process? Now you are very obviously not legally obliged to follow this process. The process is designed to serve the community. So we've got a couple of interests here. The disclosure of unpatched vulnerabilities is not in the community's best interests. But at the same time it's not in the best interests of the community to keep known vulnerabilities secret for a long time because they tend to leak. So the process is designed to enable you to disclose your vulnerability as quickly as is responsibly possible. And the reason we follow it is because we're good citizens. There's no stick. The process is designed to help you make those responsible disclosure decisions. And Tristan earlier referred to lesser disclosure. The first step in that disclosure was when you reported the bug to the VMT. And after that the VMT will guide you through further disclosures until the bug is released. For this talk I will be talking about everything done by the vulnerability management team or VMT. And Matt will be talking about everything that is done by Red Hat Engineering. But you should know that it's not a two-man show and we are going to talk on behalf of many other users, part of those. So step one, discovering the bug. So the bug was originally reported by me on the 22nd of February 2016. And it was just from code inspection. So I was working on something else and I noticed something that didn't quite look right. And I decided to look into it a little bit closer. And specifically I noticed that NOVA would do format inspection on a disc if a certain metadata file was missing. And I also knew that there was a way that a user could engineer that metadata file to be missing. Specifically by doing a resize operation and a couple of other ways. So for anybody who's not familiar with it, a format inspection. So KVM, which is the hypervisor which is most used by NOVA's Libvert driver. And I think the most used hypervisor in OpenStack. It can store data on disc in a number of different formats. But NOVA uses raw and QCAL2. A raw file is exactly what it sounds like. So if we're storing information on the file system what we've got is a file. It contains the exact bits that a user wrote to their virtual disc. If we're using QCAL2 then QCAL2 has some additional features. And those additional features are described by a header which goes at the start of the file. And one of the additional features QCAL2 provides is backing files. And backing files allow that QCAL2 to say this disc refers to this other file on the host compute. And NOVA uses them for base images. So when we've got a glance image and we're using that as a template for a number of different guests then we've got a base image over here and then we've got a QCAL2 which says this disc is everything that's in that template over there plus some changes. And they're really useful. Now NOVA file system storage uses QCAL2 by default but you can also configure it to use raw. Now remember that a raw file is whatever the user wrote to their disc. So the user, if you're using raw on a file system, can control completely what's in that file. And that's okay as long as we know it's raw. But if we can force it to do format inspection then the user has an opportunity to do something underhand. If the user writes to their raw backed file a fake QCAL2 header and then engineers it so that we're going to have to inspect that to work out what's in that file then when we inspect it, if the user has written a fake QCAL2 header then we're going to inspect it and we're going to think it's QCAL2. And if the malicious user writes a fake QCAL2 header that says this disc refers to this other file on the host then when they start their instance up they're not going to see their own data. They're going to see that other file on the host. And even worse than that if they say this other file on the host is the compute's root disc then we can see everything on the compute host including the data of other users and other tenants. So with that in mind the bug I thought I saw was that a user could create an instance within a femoral disc and they could write a fake QCAL2 header to that disc and say this disc refers to this other file which I'm guessing is present on the host. And then they do a resize operation which causes that metadata file to get deleted or to get missing. And then they restart and then they can see whatever was on the host. And when I initially saw that I actually thought it would be mitigated by SE Linux but I will touch on a little bit later it turned out I was wrong and it is not. And more generally we're looking into that. So I think I found a bug what do I do? Now as you probably know bugs in Nova are quite exceptionally rare so the chances are that nobody in the room has ever encountered the NovaBug reporting system but if you had then you would know that we use Launchpad and security bugs go in exactly the same place. So we go to the security bug reporting processes exactly the same as reporting any other bug right up to the last step. So we go to Launchpad, we add a summary, we add some further information and then we scroll down to the bottom of that long blurb. Has anybody ever read that? Not me. And we see the bit at the bottom that says this contains information that is public with a little pencil next to it. And if we expand that then we can see this is where our visibility options are and the one we want to choose is private security. And if we do that then it gives us a nice reassuring bar at the top which tells us that when we click submit we're not going to be making it public. And when you do that as a member of the vulnerability management team I am notified of a new bug report against OpenStack project. And the first task for the VMT will be to confirm whenever the report described a vulnerability or not. To do that I subscribe the project liaison, in this case it will be the Nova Corsac and we engage the discussion to check if it's considered as a vulnerability. Because most of the time new bug reports turns out to be banning. So it's better to be safe than sorry. The VMT is using a taxonomy to rank bug reports. Only the bug that can be fixed in the master version and all stable release will be handled by the VMT. We call them class A. Class B will indicate the bug that can't be fully fixed such as one affecting a poor architecture or bad designs. Those are handled by a security note instead of an advisory. Class C report indicates one that are not really practical. For example, when it depends on guessing a random value such as a UID then we don't consider it as a practical vulnerability and it does not deserve an advisory. And of course we have extra classes for bugs only affecting the development branch like that have not been released yet. Security hardening opportunities when the default settings are not bad but not great either. And regular bug that sometimes got reported as a security bug for some reason. In this case, Matthew clearly described the bug in the report and thus it was easy to confirm. At that point, the VMT coordinator will start writing an impact description that will be communicated to downstream stakeholders and it will also serve as a basis for the upcoming advisory. So it's important to get it at the very beginning. The purpose is to describe the impact from a stakeholder point of view. Indeed, technical quirks from the report does not necessarily matter and it needs to be converted into formats that articulate. Who is the actor, for example is it a remote or is it an authenticated user? Who is the action triggering the bug? What is the impact and what are the consequences? And finally, which deployments are actually affected and does it need special options or something non-default? Lastly, the impact description will also include reporter credits as well as the affected version that needs to be narrowed down. So, to answer Tristan's questions, the bug in this case can be exploited by a remote authenticated user. The bug is triggered when the user does a resize operation. The impact is read-only access to all storage connected to the compute host including the data of other users. And it only affects deployments which use raw file system storage which fortunately is not the default. But to help answer these questions with certainty, I didn't do that myself. I pulled in some colleagues for additional input and a reproducer. And this presents as an immediate problem because we do all of our disclosure management through Launchpad, through the bug, to centralise it. And by default, the bug is visible only to me and to the VMT. So, I can point my colleagues to it but they can't see it. So, as the bug reporter, I can open it to whoever I want, which is what I did. So, here's the bug and this is Launchpad and to open it up to a new person, if you have a look in very small up at the top right, you'll see other bug subscribers and a link saying, subscribe someone else. That is the bit you're looking for. So, you click subscribe somebody else and that person is added. So, in the first instance, I added my colleague Dan Berenge who looked at the bug and he pointed out that SC Linux was not going to be the defence that I thought it was going to be, which was confirmed by my colleague Lee Yarwood who actually set up the issue, set up a system to reproduce it properly and confirmed that we could actually exploit the host in the way described. But note that at this point in the process, I still haven't opened up the bug to many people or in fact even my own team. So, with a better understanding of the severity of the bug prompted by Tristan's questions, Lee then started working on it immediately because we realised it was quite severe. This presents us with some practical problems though because we can't use public infrastructure as that would disclose the bug. So, specifically, we can't use upstream Garrett and we can't use upstream CI. And the same goes for the unpacked description. After having produced a draft and having it validated by Matthew, we also go only on the launchpad where all the information I gathered at a single point of coordination. And another VMT coordinator will review and double check the details to make sure it's accurate and there is no grammar error and stuff like that. Then comes the review process. Now, I said we can't use Garrett, but we still have to go through a review process, but obviously it's slightly complicated. So, what we do instead is we still develop patches, but instead of posting to Garrett, we format them as Diff files and post them to the launchpad. And then we get other people who are also subscribed to the bug to review them on there. Something else we need to think about at this stage is that when the bug eventually does become public, when it eventually is going to go to Garrett, it is still going to have to go through the same review process that every other patch to Nova goes through. But because of the severity of the impact of the bug, we want it to clear that hurdle very quickly. So, a good idea is at this stage to get a core reviewer on board to give it a provisional plus two. So, what I did was I added Dan Smith to the bug and he reviewed it. And we had a little bit of back and forth on that with Dan. And when he said he was provisionally happy, we decided we were good to go. Well, it's actually not a good thing to do. It's mandatory for the VMT to have approval on the launchpad bug report because otherwise there is no guarantee it will get a merge once public. To ensure the full traceability, we have a severe number assigned before the issue is communicated to a larger public. So, we use the common vulnerability and exposure, in short, CVE number, which is a system that provides a reference-based method for non-vulnerability. And once the patch and the impact description are approved, the VMT coordinator will request a CVA number to something called a CNA. It's the CVA number authority. For public issue, we request the Mitre Corporation because they handle all the public vulnerabilities. And for private issue, we are going to request them from the Red Hat CNA, which is the historical one that does Linux vulnerabilities number assignment. So, once we receive the number, it gets attached to the bug report. So that, again, it's the single point of coordination for open stack issues. And we now have everything to move on to the next step. So, when the issue is still private, we may do an embargo disclosure. Otherwise, we jump directly to publishing the advisory at that point. In the spirit of a responsible disclosure, the ecosystem collectively known as downstream stakeholders needs to be warned in advance so that they can roll out patch in a coordinated fashion on disclosure day. The first step is then to propose a disclosure day. We use a very short embargo period, which is from three to five days, excluding Mondays and Friday. So it can be very short. So, as the bug reporter, the BMT actually asked me when I want to disclose, because it's my bug, but they will help me pick. As I said before, we've got these competing desires in the process. So we want to disclose as quickly as possible to minimise the risk of leaks whilst giving ourselves enough time to complete the process. So, on this occasion, I took advice from both the BMT and Red Hat's internal security team. And this time, it was fairly simple to pick a date. It was, as soon as we were done, plus a couple of days. However, it's not always quite that simple. So, for example, there was a previous CVE that we worked on at the end of last year. And the initial disclosure date that I proposed, I think it was the 22nd of December, and that I proposed this and the BMT gave me a problem and said, perhaps that might not be terribly nice to a bunch of cis admins. So maybe you could move that by a couple of weeks. So we moved that to just after the new year. But it was still my call. Once this is agreed upon, I'm in charge of sending the pre-OSSA, which is the Advanced Notification Document, which includes basically the impact description, the CV number, the pre-approved patch, and the disclosure date, so that everyone is on board with the same bits of information. So, as Red Hat is an open stack distributor, we have customers that are running this stuff in production. We are actually one of the people on that embargo disclosure list. We're aimed to have a fix ready for our customers, along with everybody else who's in a similar situation, ready to go when the bug becomes public. And we firewall ourselves internally on this. So the Red Hat, we disclose to ourselves internally at exactly the same time as we disclose to everybody else. So our internal infrastructure team, even though on this occasion the bug came from inside Red Hat, we didn't have a head start on anybody else. So on this embargo disclosure date, we're then good to go to start the process of getting this out to our customers. So when Lee originally developed the patch, he developed it against upstream, and then he backported it to the supported upstream stable branches. And then he further backported the patch to all supported Red Hat releases. At this embargo disclosure date, he can then push those backported patches into our downstream gerrit, which allows us to review them formally within the team, and then push them out to our build infrastructure and into our own CI. And once we've done that, once we've got builds ready, once we've cu-aid them, we then need to prepare an internal aratham. We need to package this stuff up so we can give it out to our customers. And we have to do all of this in a three to five day window. So as soon as we push go on the embargo disclosure, Red Hat release engineering is very, very busy, as I expect are a number of other release engineering teams. On this disclosure date, I open the bug report and coordinate with a Nova developer to submit the patch to Gerrit, just in case the patch does not apply because the master may have changed during the embargo period. We also be very worried of test result by the upstream CI system because if the gate is failing and the patch needs alteration because there was a regression on the test side effect, we have to quickly contact the stakeholders to tell them that the patch needs to be modified. And if this happens after the patch has been merged and the advisories send out, we also need to take care about the fact it's missing something or it needs to be changed. So we call this anerata. So at this point, Lee pushed the fix to upstream master and to the supported stable branches. And we started the regular review process. And in this case, it turns out that we had actually introduced a regression, which was unfortunate, as it wasn't caught in review. So we very quickly developed a fix for that and we pushed that out in a day or so, I think. It was expedited. And as Tristan mentioned, he then had to go back to the OSSA and update it with aneratum to say and there was an additional fix. So once the patch looks good on the gate system and that core developer have approved or at least test our succeeding, we proceed to produce the final advisory document. One should know that we are using also code review to validate the document with peer review. And it's based on the Yamel description of all the details that we have been presenting so far. And plus the bug report URL and the patch number that we didn't have until we opened the bug. So when this review is approved, the website security.openstack.org get updated with the latest information. And it also under a nice restructure text output that we can send to a couple of mailing lists such as the open-stack, open-source security mailing list as well as the open-stack annul. So that when it's public, it's really public. So the timeline of this bug. It was originally reported by me on the 22nd of February 2016. And we released the fix on the 9th of March 2016. So that was pretty quick. And we did this during the metaca cycle. We also backported it to upstream, Kilo and Liberty, which were the supported upstream stable branches at the time. Which is a key point, by the way, because there are no branches, there are no other stable branches to backport to. So is anybody in the room still running Juno? No? Good. Because if you were, then that would still be vulnerable. But distributors obviously, including Red Hat, we support much older releases than that. So we backported this to OSP5, certainly and possibly even OSP4, I can't remember. But that would be at least Ice House. So, yeah. If you're running upstream stable, it is important to stay on top of patches. Otherwise, you're going to be vulnerable to these things. And at this point, the bug is now open. So we gave the URL earlier. You can go and have a look at that. And you can read all the comments, including everything that was embargoed at the time. You can see the patch review process and everything. And at this point, you are, of course, also expected to create a logo for your security vulnerability and to publish it on a website and to create a GitHub repo where you can share things about it. Here are a couple of other examples that illustrates the VMT process pretty well. The first one was involved a tricky 10 steps exploitation process that got a long time to figure out and a lot of iteration to fix properly. And the second one was a critical network bug that was handled swiftly across old stable branch. I think about two weeks it was set. So that was a great example. However, things does not work out that well all the time. In particular, the process may fail when, for example, a stakeholder does not understand the embargo list and push the patch to get it before the disclosure day or when the bug report simply gets open by accident. So the short version of that talk about what happens when there is a security issue summarised like, so we need to create a bug and check the private security option if it's relevant. Then the VMT will add an advisory task to the bug. So if it's not vulnerable, it's fine. The task will be closed and we move on. And otherwise the real process starts. So there is a discussion and patch development that happens on the bug report. There will be a CV number assigned. A stakeholder will be notified in advance. The report is then disclosed and the issue is fixed as well as the OSA is published. And I think that's it. Do you have questions? Can I ask you to grab the microphone? Thank you. They're recording. They won't be able to hear you if you don't use the microphone. Yeah, so just a quick comment on that actually. The CV number triggers a one-clock kind of running as well because as soon as it's assigned, that information that which project it's assigned to gets public, even the details don't. So from Mitra, you can go now and look at CVEs that has been assigned but has not been... The information has not been released yet. So that's something like if you are a Novagmin, for example, it's a good idea to scan through and basically add those CVEs on your follow list. So when the information becomes public, you get that information right away. That depends because first of all, the process is changing actually and Mitra is providing ways to request CVN number privately because it used to be through a mailing list. So indeed it was public and that's why the open stack is relying on another CNA for private issues and turns out as much as for embargo bug, Red Hat Engineer won't use the Red Hat internal system. The security team that assigns number for external project will do the same. Like Nova developer won't be aware of a CV request until we go down to the embargo disclosure. So requesting a CV does not necessarily expose that much of a new vulnerability if that was the question. No, it tells that... I can repeat it. It tells that there is a CVE requested for Nova. I'm not so sure about that. I think the registry are not necessarily public. Is there a CNA? It's a register of it. You don't know what have been registered. I thought it was the opposite actually. The Mit website used to not update their web page as soon as the disclosure happened. So you wouldn't even know the affected project. Go ahead. So I'll just follow up on the CVE stuff. I can guarantee you now there is at least one vulnerability in every single open stack service that exists today, whether or not there's a waiting CVE for it. So I don't think it really creates a problem with exposure. My actual question is slightly different. So what happens when you have a vulnerability reported and you acknowledge that it is a security defect, but let's say it's a design issue or something like that, something you can't easily change or backport? So, well, again, the VMT will only take care of class A type of bug. So when it's not something we can fix, we won't request ourselves a CVE. However, for those kind of bugs, we suggest a security note that will be written then by the security project. And one should know that anyone can actually request a CVE. It's not something we have a privilege of. It's just that we happen to do it for coordination purposes. I guess in that case we'd be looking to make sure everybody knows what the vulnerability is and can at least know that they're vulnerable to it and mitigate it if possible. Go ahead. So given the size of the project, have you tried to become yourself a CNE? That I've been in discussion, actually, it's not that worthy because we don't issue that many advisory in the end. What is your opinion of embargo? Is it something useful? Is it something good? Do you want to just get rid of embargo and just publish everything to get more people reviewing the patch and maybe get more attention on vulnerability and security? So from a practical engineering point of view as a redhatter with customers, I do actually appreciate the three-day window to try and get a fix in the hands of people who are running this who might be vulnerable at the same time that it becomes public. It's a tough one. It's probably a philosophical question, but I think it probably does the most good to the most users to get that out there. Red Hat is not the only entity that gets this information early. Public Clouds would also be on that list. All the distributors, so anybody who can justify themselves as being a source of real fixes for real users in the wild is going to be on that list. Pragmatically, I think embargo is a good thing, but we need to keep it short. What matters is really the period. Okay, thank you. More than a month, it goes more harm than benefits. You're going to have to be quicker because we've just gone over time. Okay, so in this particular case, the actual discovery was driven by developers' curiosity and diligence and so on. So I'm wondering, do we ever see cases where these exploits are actually used in the wild? Is that a thing in open stack? To our knowledge. Only as a vulnerability management team member, we only discuss about bug reports and there is no case in the wild exploitation. I guess that would be more of a question for ops. Does anybody ever see their cloud being exploited? Really? Cool. We should go check that out. At that point, I think we're going to have to wrap up. If you'd like to contact myself or Tristan, details are there. The helpful gentleman over there said that I'll get an e-mail to upload the slides somewhere at some point, which I will do. If that doesn't happen, as I say, feel free to e-mail myself and Tristan and we'll send you a copy of the presentation that has all the speakers' notes in it. Thank you very much.


The most common learning techniques as observed by an ESL teacher. My biggest takeaway from my TEFL certification course with IDTT is the topic of learning techniques. Learning techniques vary depending on race, gender, age, cultural background, past experiences and several other variables of the students involved. I will describe my personal past experiences in regards to the subject at hand. I would like to take a moment to thank the IDTT staff for putting together this highly informative and enlightening TEFL program. It is well written, easy to understand and well organized for new and experienced ESL teachers alike. Visual vs. Auditory Learners One of the first things I learned during my 60 hour TEFL course was that children are divided into two basic learning groups. Some kids are visual learners and others are primarily auditory learners. On occasion, there are also children that are a combination of both learning styles. The Auditory Learner Auditory learners are easily detected in the A classroom setting. This can be done by tapping the blackboard a couple times with a ruler or other hard object to create a small sound. You will then instantly see a reaction from the Auditory Learners. They will instantly zero in on you and usually give you their undivided attention focusing and anticipating your next move. They will at this point stop interacting with other students and listen carefully. What I have found out that works with these particular students is chanting and repetition of words or phrases. These children also love to hear stories and will listen carefully. However, it is sometimes necessary to elicit a response from these children at the end of the story as they often are eager to listen to another story.  The key to keeping that the visual learners engaged is to keep them visually stimulated. I usually utilize the chat box in the online classroom showing them images of what I am trying to get them to learn. For example, I have found that the word chase is a little challenging to teach to Chinese students. To get them to understand the meaning, I show them a picture of a puppy chasing a ball or photo of two children chasing each other. With visual learners, it is usually best to have props ready to keep the lesson flowing smoothly as I notice that sometimes the children can lose their focus on you if there is a break in the visual stimulation stream of events. Gender This is a big one. My first observation on the subject is that girls usually speak a lot more than boys and usually start at a younger age. They also learn much faster and superior linguistic abilities come naturally to them. Boys, on the hand, usually need encouragement to speak about a particular subject or experience that interests them. This trend I have come to see continues on to a later stage in life as well. Culture I have worked with Spanish speaking students located in close proximity to the American border and these students will pick up words and phrases that can be described, for lack of better words as Spanglish, a combination of both languages retaining a heavy Mexican accent. Chinese students, on the other hand, have very limited access to English speakers and will usually take on either an American or British accent depending on their teachers. They also very rarely use slang, even though there is a growing trend towards shinglish. Age I have found that new students are much easier to teach and I often have a better learning experience. However, older students or students that were taught by local Chinese teachers tend to be the hardest to teach. They very often have a heavy Chinese accent that is in most cases impossible to break. As an example, I usually will ask what grade are you in? And the response which has been ingrained in them from a very young age will be I am in grade 2. This is what has been drilled into them and again it is very hard to undo I have come to find. Willing vs. Unwilling students We have all heard the phrase you can lead a horse to water but you cannot make him drink it. This certainly applies in the classroom setting as well. There are some children who try to soak up as much English as they possibly can while some children both learning. Some have started out being active participants but have been burned out by demanding parents or teachers to the point that they lose the drive to participate in the classroom. Are you ready to teach English abroad? Speak with an ITTT advisor today to put together your personal plan for teaching English abroad. Send us an email or call us toll free at 1-800-490-0531 to speak with an ITTT advisor today.


In today's video we are going to go over the evolution methods for Tandemouse, Dunsparse, Giraffe Rig and Phinizen in Pokemon Scarlet and Violet. But before we get into today's video please subscribe to the channel remember you can always unsubscribe later if you would like to. We're going to start off with Tandemouse it is the new normal type of mouse Pokemon in Scarlet and Violet. It can be found in the east province area 1, 2 and 3 of the region as well as in the west province areas 2 and 3. Tandemouse evolves into Mousehold at level 25 but it's a strange Pokemon who will skip its evolution screen if you level it up without earning the experience it needs to level up from a battle. To make sure you don't miss its evolution have it battle and earn enough experience from that battle to level up from level 24 to level 25 and when you do this your Tandemouse will evolve in full show to Mousehold at level 25. Mousehold can have two forms a family of three and a family of four. Every time Tandemouse evolves it will have a one in four chance of becoming a family of four rather than the more common family of three mice that you normally see. Mousehold can also be found in Terrorids the five and six star Mousehold Terrorids will always offer the chance of catching a four member family. Next up is Dunsparse. Dunsparse can be found all over the Piledare region and when you have your Dunsparse and level it up to level 32 it will learn the new move Hyperdrill. If you learn this move right after leveling up to 32 then Dunsparse will automatically evolve after this into the Dunsparse. If it learns this move after leveling up you will just need to level it up one more time to evolve it from Dunsparse into the Dunsparse. The Dunsparse is another Pokémon that has two forms the two segment form and the three segment form. The evolution and the segments you receive is completely random but you will have about a one in 100 chance of your Dunsparse evolving into the three segment form. You can also catch Wild the Dunsparse in the later stages of your playthrough although I have never personally come across a three segment form as of yet. Up next is Girafferig. In these games this Gen 2 Pokémon is another to receive a new evolution this time into Ferrigaraff. At level 32 Girafferig learns the move Twinbeam. Teach it to your Girafferig and then level it up by one level and it will then evolve into Ferrigaraff. Finishing in is the new Dolphin type water Pokémon and has to have one of the most obscure evolution methods out of every Pokémon in the history of these games. To evolve Finisin into Palofin you will need to connect with friends online either locally or via the internet using the union circle feature to form a co-op group. Once you and your friends are in the game together you will need to get your Finisin to level 38 and once you are with your friends and do this level up Finisin will evolve into Palofin in front of all. It doesn't look like the evolution changes it much other than the heart that appears on its chest but once in battle Palofin has the zero to hero ability which activates upon switching out making it transform into a much stronger alternative form as you can see here. And that's everything that we are covering in today's video I hope you have found this useful if you have please drop a like and if you're new to the channel do subscribe so you don't miss any more of our skull and violet coverage on the channel. Thanks for tuning in and until next time bye bye


I'm extremely honored and humbled to be a recipient of the Leadership Person of the Year Award. And I'm deeply grateful to the Chairperson and Management of the Leadership Group for deeming me worthy of this recognition. I'm also very privileged to share this award of Leadership Person of the Year with Dr. Ngozi Okonjo-Weller, a globally affirmed finance and development expert and a true Nigerian patriot who is now Director General of the WTO. Every glass ceiling that she has broken, and there are many, has inspired girls and women all over the world to reach for the highest heights in all fields of human endeavor. The late Sam Nda Azar was a dogered achiever who stood for integrity in public life and embodied the finest traditions of Nigerian journalism. He believed fervently in the role of the media as an empire of public discourse and in his mission of elevating the quality of public debate. I'm gratified that the values he lived by continue to be ardently represented by this organization. And I'd like to commend the Leadership Management Team very ably led by Mrs. Zaynab Nda Azar for forging ahead in the wake of Sam's transition to glory 60 years from years ago and today we celebrate his 60th posthumous birthday. Those of us who, like Sam Nda Azar, belong in that same political tendency, the one that is loosely described as the progressive tendency, agree on certain principles. We agree that we must create a country that works for us all, a peaceful and secure society founded on law and order and the rule of law, a society that enables commerce and values productivity so that large and small businesses can grow and provide jobs and opportunities for the millions of young people, a society where no one is left behind, providing by means of an effective social welfare scheme, a safety net for the very poor and the vulnerable, a united and tolerant nation where all irrespective of ethnicity, of religion or political persuasion are respected, treated fairly unjustly and have equal access to all opportunities. We agree that we must build a Nigerian where a boy or girl does not say that I am from the south west or I am from the north west or the south south or the north east or the north central or the south east or that I am a Nigerian, a citizen of one of the greatest and most prosperous nations on earth. This is the kind of Nigeria that those of us in this political tendency to which Sam and I belong, all attest to and all believe. I therefore dedicate this award to the millions of Nigerians who believe in this new Nigeria and who retain faith in our possibilities as a people and are doing their best every day in their various corners to build this nation through honest endeavor dedicated to these people of goodwill who are working hard to promote peace and tolerance and to build a country that truly represents all of our dreams, a country, those who are working hard to build bridges, those who have refused to be frustrated or even worried by the trials of our country as it grows and continues to the fullness of its manifest destiny. I think that it is because of certain Nigerians that despite the great challenges that we're passing through on our march of progress that I'm certain that we will build this great Nigerian nation that we all yearn for. Once again, I thank the management of leadership for this award and I congratulate all our deers for the very well-deserved recognition. Thank you very much.


Good morning everyone and welcome to Kubernetes on edge day here in the heart of Europe. It's a pleasure to see such a diverse and vibrant crowd ready to engage with the future of technology at the edge. Today we stand on the brink of a paradigm shift with Kubernetes leading the charge into a world where the edge is not the final frontier, but a gateway to uncharted innovation. I'm Tina Joe and I will be guiding you through today's events. Let's begin by grounding ourselves in our code of conduct rooted in the golden rule cheat others with the same respect and kindness you will expect. This principle supports our collaborative environments. So please take a moment to scan the QR code and familiarize to yourself with the full code of conduct. It's how we ensure today is productive and positive for everyone. Inclusivity is at the heart of our community to ensure everyone can follow along. We are offering captioning and translation services accessible right from your device. Please scan the QR code display here to select your preferred language. Your session ID will fill in automatically. Just hit attend. This way we can all share in the knowledge regardless of our language. As we start, I want to share my excitement and gratitude for being here with you all. Or serving as TSE member of CNCF could be edge and engaging with elf edge has been a profound journey. These experiences have shown me the power of collaboration and innovation at the edge. Today, we are here to not just talk about the future, but to create it. So let's embark on this day of learning and exploration together with open minds and share the goal of advancing Kubernetes at edge. In a few short years by 2025 edge computing will revolutionize the data generation accounting for 75% of the global data. It's an arrow where hardware and software are not confined to data centers, but distributed across thousands of locations. The paradigms of observability, the flexibility of loosely coupled systems and the agility brought by declarative APIs and automation. These are the pillows that Kubernetes brings to manage this complexity. Today, we're not just discussing the future. We're actively creating it. Kubernetes is a critical part of this distributed systems infrastructure already shaping our word. And together during Kubernetes on edge day, we are going to explore and define the role we all play in this new chapter of innovation. Here is the trajectory we all a curve that starts as we approach 2025, a testament to the explosive growth of edge computing. As we charge this pass, it becomes clear that Kubernetes is not merely following chains, but setting them. The future is promising and the potential is vast. It's a future where data and devices are omnipresent and our infrastructure must adapt accordingly. Kubernetes is the key to this scalability, ensuring that we can meet and exceed the demands of tomorrow. As we witness this curve ascending, let's challenge ourselves to push beyond its limits, joining innovation in edge computing to new heights. Our agenda is crafty to provide insights and provoke thought from securing software in unchested environments to bring in IoT devices with cloud native systems. Each session is designed to push the envelope of what's possible. We'll see how Kubernetes performs under various distributions and witness firsthand the power of Kubernetes for AR model deployments. We will explore the transformation of traditional IT infrastructure in revolutionizing rayways. Then dive into the competitive world of Kubernetes distributions with the Kubernetes hunger games. We will also discuss extending the reach of cloud native technologies onto Android OS, a testament to the versatility and availability of Kubernetes in every environment. Don't miss our demo of Kubernetes at edge for AR model deployment where theory meets practice and we get to see the tangible results of our discussion. Before we delve into our sessions, a moment of gratitude for our diamond responses, Spectra cloud and SUSE. Your unwavering support and commitment to excellence make days like today possible. Your foresight in the realm of edge computing and open source solutions empowers us all to reach new heights. As we prepare to launch into today's journey. Thank you once again for being here. The energy, expertise and institutions you bring create the rich tapestry that is our Kubernetes community. Let's make today a day of meaningful connections, engaging discussions and transformative ideas. Let's get started.