 Thank you very much. I'm Casey Schaufler. I'm going to be talking just a little bit about our smack update. Smack update isn't nearly so comprehensive as the SC Linux update was going to be. First thing I want to talk about is who's using smack. Usually the first question people ask is, is anybody using it? It turns out that if you have a Samsung TV from the past three years, you've got smack. They're also sneaking into a whole lot of the other Tizen-based devices. So that's coming from Samsung, also some other vendors. Automotive Grade Linux, which is a Linux Foundation project to do software for automotive use, is also using smack. So if you have a new Toyota, it's probably got smack in it. The other thing that we're finding, there's a project called the Yachto project, which has been described as a Linux Otron. So if you don't want to use an existing distribution, you can use Yachto project to define what you want having in a Linux system and create your own. And it has actually fairly extensive support for smack as well. So in addition to the Tizen and the Automotive Grade Linux, we're seeing a bunch of 1Z, 2Z kinds of things coming out where people are doing a board support project or they're doing a special purpose thing. And they like having smack because it's somewhat easier to work with from a policy standpoint than some of the other systems that are available. So what's new in smack? Not really a whole lot this year. We've finally got support for overlay AFS, which turned out to be painfully trivial. So that was kind of embarrassing. The other one was it turned out we had never implemented a mechanism whereby a privileged process could change information about keys. So if it was your own key with your own smack label, you could change the key just fine, but if you had privilege, you couldn't. So that was a simple change to make so that now you have a little bit more control on your system over your key set. So what's fixed? There have been about four or five places within the code where people have using clever and modern tools discovered memory leaks. Generally, they've been trivial. In a couple of places, they actually weren't memory leaks. They were just system information that was being allocated for future use. But there have been a couple of things that people have found. One of the other things that's been really interesting is that we've been finding that in the early RCs, occasionally well intended changes break smack without anybody detecting it. And this got to be enough of a problem that we actually had to start doing every RC testing on a fairly regular basis. Now, the good news there is that meant we actually had to finally write a test suite, which is going to be available real soon now, internal corporate politics allowing. But we even had one from Al Viro where Al made a significant change. It's like, excuse me, but this doesn't work anymore. It's like, oh, I didn't know that should work. Well, Al, you're supposed to know everything. Okay, so he actually convinced me to make a change that fixed the problem. But that kind of thing happens. It's happening enough now again that we're actually being more proactive about checking those and detecting those. We had some minor issues with IPv4 over IPv6. We got some patches from them from Samsung as well as UDP Lite and DCCP, which I don't even know what it stands for. But it's fixed to their satisfaction now. So I'm happy. It's nice to have other people who are actually active and know what they want, who are willing to contribute. So the real thing that I want to talk about, and I can spend just a little while, is things we've got that we love to have people work on. And I think that the projects SPAC has to work on are going to be much more fun than the projects that some other systems have that they would like you to work on. So for example, we don't have support for Calypso. And I do spell it right this time. Every other time I've put up a slide with Calypso, I spelled it the way the word is spelled, not the way the acronym is spelled. And Paul has come and wailed on me because he's a networking guy. Well, excuse me. Yeah. OK, fine. He is a networking guy, I see. I told him. OK, so we love the support for that. Should be a slam dunk. We also have a lot of cases where the net label code is used in a way that's different from the way the net label code really is intended to be used. That causes real issues, not with the SMAC code. SMAC works just fine with it. But if you try to run it in SC Linux at the same time, they seem to have a rather tough time coming to agreement on anything. So we have a lot of cleanup that could be done there. And if deafening in that code is horrendous and will make your eyes bleed. So you'll definitely need to use some cleanup there. We have a couple other projects as well. SMAC namespacing. Our friends at Samsung actually implemented namespacing for SMAC a couple of years ago. Their particular use case went away. And so they've dropped it. But we could definitely pull that back up. That would be a fun thing for somebody to do. Infiniband support, Libvert, EBPF controls. The hooks are all there. We have a worked example on how one might do it in another system. So these should be really easy things for somebody who wanted to get involved in security module development to pick up. And here's the big one. It's about time somebody fixed Fedora so it could use SMAC properly. And what we really need there is a rule set definition. We have rule set definitions again. From Tizen, from Automative Grade Linux that you can use as templates. This is a way to get started. But it would be really nice. Really handy if we had that for Fedora. We had that for Ubuntu. We had that for Debian. We had that for Suzy. We had that for any of the other, what you might call, mainstream distributions. Those would be just great to have those because we don't yet and think that would really be a helpful thing for the community to have. Let's see. What else do I have to say? I think that's about it because I'm going to let you guys off the hook early unless there are questions. Excellent. Thank you.