 So, status update for the TSS2 user space. This is kind of a milestone for us. In past, well, conferences like this, LSS and a few others, we've done some talks about this, but they've always been focused on the large architecture, what the APIs are, how the plumbing works, how everything fits together. And of course then, the evolution of the project from a really rough prototype to our goals and aspirations to having a real stable piece of infrastructure that people just rely on and use like it's part of the ecosystem. And so today, doing this as an update, it's kind of mission accomplished. I'm doing a lot less work these days. The presentations are shorter. They're much less complicated. And I'm fighting through far, far fewer bugs than we used to. Plus, our community has grown quite a bit, which is really nice. So today I'm doing a status update and I'll cover just this past year our progress on the core libraries, things that I think of as just the plumbing. And then we'll move on to work to enable the use of the TPM through plugins to existing kind of cryptographic frameworks and well-used programming APIs and such. Then finally, we're just going to close on a little bit of what you would expect, which is kind of forward-looking. Things we'll be doing in the future. And things we'll be looking for some input from you all on. Things you may actually want to contribute to if you're interested in getting going. But first, the plumbing. So our goals have always been for this to really improve the maturity of the project, get a real good release cadence down, add new features without destabilizing APIs, really what you would expect from a mature project. We've got a new GitHub.io page now. So we're working on improving our documentation, which is not as much fun as doing the coding, but it's kind of just part of the business. We've got our code coverage metrics that we're collecting through all of our CI loops. We've reached 80% average for the project. Some are a bit above, some are a bit below, but 80% on average. We've also started doing some work with the Linux Foundation's the core infrastructure initiative. So we've gone through the self-certification process for these core libraries through the CI, which is nice to get a little badge on your readme file on GitHub, and I don't know, everyone thinks you're special for it. So the core libraries themselves, the TPM2-TSS repository, that houses the real guts of the project. So we've done three minor releases this year, no major releases, which is nice. The APIs are stable, and we're hitting a good release cadence of every four or five months. We've added a couple or we've added a new library to help with user experience. One of the biggest problems that we had all along is that when errors happen, you basically have a hex number that tells you what the response code means, and you have to go and manually pull it apart. One of the first things that I did for the project was to write a tool that did this on the command line, but still no one ever uses it. We still get people to just send us, you know, the hex digits over the mailing list and ask us to decode them for them. But we turned it into a library and we're starting to integrate this library into the project, so you should be getting much, much more understandable messages out of there. That's already done and out there. The TCTi loader got a little stuck. The TCG does all the documents or all the specifications in Word files. I'm not particularly great with Microsoft Word, so I kind of screwed it up. It was supposed to be in public review now, but it got held up for a week because I don't know Word all that well. But it's under review now. That should be out hopefully for public review next week. And, you know, the next major thing we're pushing towards here is the feature API. This is something that we had a, you know, there's been a public review version of this out for almost five years now, but there's been a lot of churn since and we should have another version of this out, hopefully with an implementation following it. This is something that our friends and collaborators at Infineon and Frownhofer have been working on with us. So that's not out just yet, but you should be seeing that sometime in the fall. The tools, the command line tools, probably the things that people use the most and has seen a whole lot of churn this year. We've done two minor releases since the last LSS and just yesterday, Bill Roberts who has been pushing a lot of this forward, actually has been the main driving force behind it, put out the first release candidate for our 4.0 release of the tools. This is a big improvement in that it aligns all of our command line parameters that were unfortunately a bit scattered in the past. So Bill sunk a lot of time into cleaning this up and we're very grateful for that stuff. Also, this 4.0 release has been a port with the tools. Previously they had used one of the very low level APIs, the system API, which really wasn't intended for use at this level, but it was the only thing we had available when we started the project. Now that we have an implementation of the enhanced system API that wraps up a lot of the details that the tools used to do themselves, the tools now gets things like auth session support and much better, hopefully, support of the long run too. So all of the session support means we can do things like sessions with the TPM, so HMAX, and stuff like that. The resource manager, the user space resource manager is kind of being used less and less as the one in the kernel gets more features and distros pick up newer kernels. So we've only had two minor releases since the last LSS. In those releases, I've added context gap handling, fixed some bugs in our partial read support of the TCTI layer. That's the transport layer. And largely, I've just been focusing on stability there. So in enabling some of the existing use cases that we're trying to go for, we've developed an open SSL engine that plugs into the existing engine API and we have support in the 1.0 release that happened, I think, back in the spring. The open SSL command works so you can get random digits or you can get random data from the TPM. RSA, ECDSA commands work. Some of the X509, like request, the certificate request, will also work as well, so you could sign certificate requests with the key that's in the TPM. We did a presentation in a demo at FOSSTEM in the spring and there's a great demo of the S server using a doing an SSL connection to a client where the server has its key in the TPM. This is the work of Andreas Fuchs, one of our collaborators from Germany in Fraunhofer. The PKCS11 work got a little bit slowed down on account of a couple people in a little bit of attrition. It's hard to hold on to good help and that got held up a bit while Bill was focusing on the tools release. So it's usable now for authentication and we have that link there as to a commit where to adding some documentation for using the PKCS11 plug-in with OpenSSL for authentication. The nice thing about this though is that we're able... We're going to align it now with the feature API work because a PKCS11 library or plug-in rather needs to have some kind of storage so that it can basically be the token that you would expect to be on a smart card. This means you had to implement a database, a key database, which is something that's going to be in the feature API anyways. And so holding up that work wasn't a bad thing because it means that we can just rebase it on this API that we were hoping to have out by the end of the year and then we get the key database for free, which is really nice. Finally, myself, I've been focusing a bit on enabling some UEFI use cases. This last year was a prototype but it's moved into the proper project now and I've set up a whole pile of automated testing using the software TPM, OVMF firmware, QMU, UEFI shell. I've got a whole bunch of example code that's up there now and all of those things run in CI. So when we do a build of this, it kicks off a Travis build that actually will set up a full virtual environment to run the UEFI under, which is pretty interesting to set up. It's really useful. I've got a little bit of a blog post down there describing it. Now, finally, things that we're heading towards in the next year is actually some stuff that's kind of going to happen pretty quickly, I hope. We've had an RFC out there from Fraunhofer for some bindings to Python since about January. They used the FFI interface and it wasn't particularly object-oriented, so we went back and took a look and decided to go the route of using Swig, SetupPy, and it uses much more of what you'd expect from Python objects. That's imminent. It's right now under review inside of Intel before public release, so Intel is getting pretty rigid about reviewing stuff before it goes out the door. It's open source and it's got cotton in it and it's going to get a pretty good look before it gets out the door, so I can't say exactly when it's going to be there, but we're hoping it's going to be soon and we're hoping to go the same route for additional languages. More bindings, more support, just makes it more usable for everyone else. Crypt Setup and support for LUX has been a pull request against the Crypt Setup repo for about eight months now. They're finally starting to make some progress on it. They didn't want to implement or use the TPM APIs directly. They want to have kind of a layer in between them so that they can support generic tokens, and so it looks like we're going to be the first use case for this token interface in Crypt Setup, and that's a link right there to the merge request that Andreas put up a while back, and you can see some of the notes from the folks at Crypt Setup that are working on it. Finally, myself, I've been looking like I was saying at some of the firmware stuff and so I've been parsing some of that event log information and as more and more of these kind of disparate formats come together and folks probably heard Monty talking about this unified format for these things, it might be useful for us to have some kind of standard API there. There's no work on that just yet. I've got a pile of code that does it, but I think eventually we're going to have to make a library so that folks that are implementing attestation responders and verifiers will have some help and won't have to write it all themselves from scratch. That's it. So if anyone has any questions, we've got, you can go to any of the project sites. You can go to the github.io page. You'll find our readme's there. We have a link to our IRC channel, mailing list, instructions for submitting contributions through github and that's a great resource to get started. Any questions? Okay, thanks, Philip.