 Okay. Hello. Thanks for being here so early. So I'm going to talk about GNUTILAS. I'm the GNUTILAS maintainer. Let's see if this works. So GNUTILAS is a TLS or SSL library. TLS and SSL are mutual. It's the acronyms for the same protocol. SSL was invented by Netscape long time ago and standardized within the ITF as TLS. There has been some changes in the protocol, but not very large changes. So TLS is the security protocol used in HTTPS, which you may be familiar with. So GNUTILAS is like OpenSSL, but the philosophy is to strip away all the non-TLS-related stuff like SMIME, like low-level crypto. GNUTILAS doesn't provide AS encryption or similar. It's just a TLS library. So hopefully GNUTILAS will be less bloated than OpenSSL. Still, it would be nice to make things more modular, but at least it's smaller than OpenSSL. The X519 stuff like OCSP is not supported either. I'll talk about this later. So GNUTILAS is part of the GNU project protected by Stolman's GPL shield. The copyright is assigned to the FSF, so they can protect us if there are some problems. Some company takes GNUTILAS and puts in some product and doesn't follow the license. So the core library is the lesser GPL version 2.1. We have been thinking about moving to LGPL version 3, but there are a lot of reverse dependencies on GNUTILAS that still are using LGPLV version 2.1. So it will probably take some time before we can upgrade it. The core library or the tools and the surrounding utilities are under the GPLV3, like the GNUTILAS-CLI command line interface. There is also an extra library in GNUTILAS called libgnutilas-extra, which contains some minor things like LZO compression. It used to contain more things, but we have remote things from it. It used to contain the OpenPGP authentication, but that has moved into the LGPL part. So the majority of the library is LGPL version 2.1. So GNUTILAS depends on Verne Koch's libgcrypt for low-level encryption. In the latest stable branch, it's possible to replace libgcrypt on a per-encryption algorithm basis. So if you want to plug in your favorite implementation of AS, that's possible. Or if you want to use hardware-assisted encryption, that's also possible. We're using lib-tasen-tasen1 for ASN1 parsing. It's a very small library written for GNUTILAS. I believe it's below 10,000 lines of code, which is fairly small for ASN1 library. That's required for the X59 parsing. It's not used for any TLS protocol parsing. For compression, we support libz and liblso. Actually, the LZO compression is not standardized for TLS, so it's a non-standard extension. But we support it for experimentation anyway. That's part of the GPL version 3 extra library. There are bindings for guile, the GNU-Lisp extension programming language, and C++. The C++ libraries or wrappers are not heavily used. I haven't seen any large plug that used them yet. Hopefully, it will take up. There are some unofficial wrappers like Python as well. I haven't used them myself, but they are out there. As far as I know, there are no Perl bindings, so if anyone here is a Perl hacker, there's a nice project for you. There's also Windows installer, built using the Ming-Wi cross compiler and the MSIS installer, which are very nice tools to create Windows programs from the Linux environment. Some history about Knutules. It's an eight-year-old project. Nikos wrote it initially and was the maintainer for several years. I maintain it since I think 2005 or something like that, because Knutules didn't have enough time to work on it. Nikos is still around and is the largest contributor today besides myself. There's a fairly small development team. Over the time, 15 people have been contributing patches to Knutules' large patches, so they had to sign copyright papers for the FSF. That's a fairly small number of people, so if you're interested to work on a security project, it's a good chance to join the team. This graph is from Olo on the code size. It's a fairly stable increase of code. I'd like to reduce that code at some point, but it's still this inevitable curve to just increase. Another way to increase the code would be to modelize things further. That's something we'll do in the next branches. Another goal with Knutules is to have good documentation. I talk with a lot of open SSL users that are frustrated with lack of documentation. Knutules has a text info manual, which can be read like just a user manual or a programming manual. There's also the GTK doc interface used by GNOME for documenting libraries, used by GTK and Glib. We put a lot of energy in making things documented. If it's not documented, it's not supported officially. Everything that is in Knutules has good documentation. Some of the features in Knutules, which you might not be familiar with, if you are familiar with HLS, Knutules supports OpenPGP authentication. You can use your OpenPGP or GNU-PG key to authenticate yourselves to a server. And vice versa, the server can use a GNU-PG key to authenticate the server to you as a user. It's an interesting feature that I hope will be used more. There's an Apache module that supports it. So all the features, there's support for SRP authentication, which is, if you are not using certificates but want to use a password instead, you can use SRP. It's a good way to authenticate TLS sessions with a password. Another TLS extension that has been published or standardized relatively recently is PSK. It's TLS authentication with pre-shared keys. Like if you have a static AS key or DESK key, you can authenticate the channel using that key. Another feature in Knutules has been the server name extension, which allows you to use multiple TLS servers on the same IP address, which has been a problem in Apache with ModSSL for a long time, that you have to use a unique IP per SSL site. It's still, of course, you need the support in the browsers, but recent Firefox and Internet Explorer supports it. Knutules also includes X-File 9 tools, so you can create certificates, CA, sign them, and parse certificate requests and so on. So also working with Knutules is challenging from a patent point of view. First of all, the entire TLS protocol is patented. It's patented by Netscape a long time ago. Fortunately, they are not doing anything with their patents, so it's possible to make a free implementation of it. The RSA, of course, has been the stark problem with the RSA patent, but there's always been free implementation of RSA available. The RSA patent has expired, so it's no longer a problem. The SRP patent is patented by Stanford. They have actually released it as a free patent and encouraged free implementation of it. There are also some rumors about other EEC and speak patents that may apply to the SRP technology. So some organizations are concerned with using SRP. I know that the Red Hat's Knutules builds, disables all the SRP stuff in it. And there's also an authorization extension for TLS being defined. Actually, it's been through four last calls in the ITF, and it hasn't passed so far. There's a last call for it right now, and it might pass this time. There's a patent on the technology by the draft authors, and it's not clear whether that license is free enough to be useful. Okay, I have some time left, so I can take some questions if there are any. I think the library isn't growing like this. It's mostly tools and examples and self-tests. It's a very large self-test part of Knutules, and I think that's a big part of it. I believe the library itself is below 100,000, so auxiliary code. Yep, more questions? I don't have the license from Stanford ready or clear in my head, but they have been encouraging free implementation and have been supplying the community with an implementation of SRP under a BST license as well. So it looks like Stanford is not going to sue anyone, but of course this is a patent area, so you never know what happens to patents. The SRP patents that's more problematic is probably the speak or ick patents, because they are owned by Lucent or some other companies. But then it's a problem of thinking of whether that patent applies to this SRP technology or not. And that's lawyer territory, so it's difficult to answer. But I believe the Stanford patent grant is fine. That's the best we can hope for. Any more questions? Yeah, so we have had, I think, five or six security announcements for Nutella's. And some have been, okay. I can answer that in the break. Thank you very much. Thank you.