 40 seconds. No, because the recording starts exactly... So, this is something experimental. Yeah, that's sort of a talk. It's not for you at all. Yeah, it's not for you at all. It's a thing. But anyway, welcome everyone. Thank you for attending this thing. So, my name is Antoine Jacoteau. I've been an open BSD developer for 11 years or so. And yeah, I think that's pretty much SunZill. I'm Baptiste Daroussin. I'm a free BSD developer, member of the core team. And I've been in the project since almost eight years now. And we're here to speak about things. Yeah. So, just a quick disclaimer before we start. We're going to talk about a lot of different topics. But of course, first we're not experts at everything. And second, each topic that we're going to talk about could have their own one-hour talk. So, there are a lot of stuff we're not going to go deep into. So, sorry about that. And, well, first let's start with how we came up with the idea of this talk. Because it was pretty funny actually. It was like, I don't know, it was summertime. It was afternoon. We were having herbal teas, sponge cakes, something like that. Yeah, exactly. We're having attractions, talking about something like the ponies, unicorns. We're the first stars. Booking first, blah, blah, blah. The usual meeting you can have. Yeah, exactly. We have a lot of physiological discussion with Baptiste. So, that was it. So, quite a summer afternoon. And... Well, no, you can tell them. We'll make it in. It was like 2 a.m. It was in a pub somewhere, I don't remember where. We were having our 10th pint of... What was it, like crappy beer? I don't know, duvet or something? No, no, no. Sorry, sorry. So, I was... What was it? It was crappy beer. So, we're having our 10th pint of Heineken. And I was like, Baptiste, this beer doesn't have any flavor anymore. It's like, I can't feel the taste. And that's where he hit me. My God, you guys, you don't have flavor packages. So, talking about flavor. Flavor in packages on OpenBSD is actually a very interesting concept. I'm not aware of any other UNIX package manager that actually implemented. That doesn't mean they aren't. I'm sure that I don't know any. What the Flavor package does is that it allows you to provide packages compiled with a different set of options. So, that's very convenient from a dependency point of view. Since, according to the options that you want to compile the package with, the final binary will change since you will end up linking to different libraries, et cetera. So, to give you an example, let's say you want to compile a send mail and you want to give it support for SASL or LDAP and things like that. So, of course, if you compile against LDAP, your package will link against LDAP. Maybe it's something you want. Maybe it's something you don't want. And the thing is that on OpenBSD, we really want the user to use packages and not compile things. So, Flavor lets you basically create a package with a pretty fine set of options. So, we actually have several send mail packages that you can choose from when you install it, that they all conflict with each other, of course. And that's actually pretty convenient from a dependency point of view. It's different from what sub-packages, sub-package is when you build one big package that's too split. So, that's typically used for things like PHP, for example. On OpenBSD, we build PHP with support for all modules. And at the end of the packaging, we actually speed the package so you have PHP iMap, PHP MySQL, PHP, blah, blah, blah, stuff like that. Yeah, on FreeBSD, it's true that we don't have the favors. Actually, we have kind of, I would say, shitty sub-package system where you just hack things so that you get, actually, a sub-package. So, for the case of PHP, it's basically the same as OpenBSD and then you get PHP-iMap, whatever. But it's true that some situations like for LibelDAP, where you probably want to enable or disable sales depending on what you need. Right now, we have two packages, say both conflict together, but imagine someone is depending on LDAP and doesn't care if it's Sassel or not. What we have defined as a default is a default. So, if you install, I don't know, LibelDAP, Sassel, and you, some may depend on LibelDAP, then it will remove some mail, which is probably a good idea to remove some mail anyway. But we have work in progress in that direction. We are working a lot on that. The problem is we have a lot of old tools that deals with the port street, port master, port upgrade, and things like that. That depends on having a unique origin per package. And if you go to flavors, if you go to sub-packages, then you break that paradigm. So, that's why it took so long to come now. But we have decided that, okay, fix those tools. Let's make this happen and see if someone cares about those tools. They will have to fix it. And we'll be happy to keep those tools if it's fixed. Okay. So, like I said, I need Sassel support in OpenLAP on previous deal. Yeah. So, I assume it to be done myself, right? No. Actually, we have a package for it. Oh, okay. But then what happens if I run, like, package update and package upgrade? It will remove everything that depends on your... So, that's nice. Yeah. Yeah. So, one of the things we do support, and I don't know what to do, is we do support upgrading packages on the given release. I mean, binary. I got security issue. I got an inversion and I have packages in place. We actually do support binary package upgrade on the given release. But we do not provide pre-compiled packages. So... Yeah. So, yeah. It's true that you need some kind of a build box where you can distribute your packages of data from. There's actually work in progress in this area, and I'm pretty confident that within this year, we'll be able to provide binary upgrade for packages on all our supportive releases. Oh, nice. Yeah. So, keeping your box up to date will just be a matter of package... Package add minus you and... Talking about distributing packages, actually, it's important to note that there are a lot of operations on OpenBSD when using package add. All done using a no privilege user. The fetching of the packages, extracting, verifying the signature, et cetera, is all done as a separate user. We don't go online as a route or nor as the build user. We actually prevent the build user to go online. And if I remember correctly, you guys tried to do that in Libfetch, tripping privilege, something like that. That was reverted. Well, actually, yeah. What we do is, since day one almost... Well, since Capsicom's day one, the package is Capsicomized. So, every single dangerous area are running in the sandbox. We also added some privilege drop recently. Actually, just before you did it in a few weeks before. Well, actually, it's three days, exactly. Before OpenBSD did, I had to revert the fetching part because it wasn't able to you ready to read the net dot net or see something that people were using. So, for the next three days, I will add it again and add the mechanisms that I can fit this net or see file. But anyway, we are some bugs almost everywhere. So, we'll save even if a route. But, of course, it's better to have privilege separation. And most things in package now, if they don't need root requirements, switch into a non-privileged user. Well, I guess we're pretty much done with the package side. Yeah, well, no, I just wanted to add that there is a big difference in the way we see things in OpenBSD and PreBSD when we go to packaging is that since day one, our primary goal was always to provide binary packages. So, it is a little bit shameful that we're not actually providing a grade for these packages on a given release. As I said, this is going to change. But it's really a different vision that we have compared to you where you actually do build a lot of stuff. Historically, you used to build a lot of stuff. Thank you. I'm a bit late. Yeah, we used to build a lot of stuff. Well, I'm lost. Okay. Yeah, but one thing about the boss tree is that it works on every single supported version of PreBSD because we have kind of long-term support in PreBSD. And so, it's hard to make large modifications that may break all versions. But yeah, that's something you don't really know as you do support only something for six months. Well, you're correct that for packages we only support the current release, which today is six to no. The OS itself is supported for two releases. And aside from current snapshots, our ports tree is actually tied to a specific release. So, we don't follow a rolling release model on the ports tree. And we don't want our user to be forced to upgrade to a new major release of the software on a given release. So, if you have a major update of some ports in your tree, maybe you don't want to have to be forced and update it until you actually upgrade your operating system as well. It's against a different way of seeing the packaging, I guess. Also, considering the fact that we do have regular six-month releases, our packages don't have really time to get very cold anyway. So, I don't really see that as a problem personally. But that's it. As I mentioned, there's an ongoing discussion about supporting previous releases, not just the current one. And, yeah, that's it. When I say support, what I mean is that we actually provide a CVF patch, or diff, and for the package, we're not providing the binary packages, but for days, we're only providing a diff as well. We're not providing any binary update or whatever. This is actually going to change. There is a little work in progress tool, which allows you to patch a given release of OpenBSD without the need to recompile anything, which I guess will make a huge difference in the way people put OpenBSD in production. Other than that, yeah, I do understand the need for LTS release. I do, but I just don't want to be the one who actually administers those kind of releases. Thank you. Talking about support, I see that you guys have, like, some long-term support, extended support, normal support. I mean, what the fuck is your policy? How come FreeBSD 10.1 was still supported and 10.2 wasn't? Come on, that's easy. No. In our model, what do we have? We have the normal releases. A release you take out of the stable branch and say, okay, this is FreeBSD 10.0. And then you support that for a minimum of 12 months. And so to quote the policy on the website, and for sufficient additional time if needed to ensure that the newer release, that there is a newer release at least three months before the older normal release expires. So that's a normal one, easy. And then you got the extended. And so the extended is basically you select a release. Usually it's a second release each time. And you keep it for 24 more months. And that's it. And also the latest release of a given branch is extended support. So you have 24 more months on the latest one. So that's easy. It is? No. Really not. That's the reason why on FreeBSD 11, we have decided to change that to a model that everyone will understand. So basically right now, a given branch, like FreeBSD 11 will be supported for five years. And we can make release whenever we want out of that branch. As soon as the release is there, people will have, I don't remember, something like two months, three months. They have three months to upgrade to the new release. And given we provide stable ABI, just let's say a newer revision of the same release. And then people can exactly know where they are and how long it's supported. And you won't have any more 11.1 supported while 11.2 is not supported anymore. And you can understand what you're doing. Well, it looks like FreeBSD support model keeps newer feature out of the hands of the user. In fact, I understand a bit what you mentioned about how releases are supported. In my opinion, I mean, our model makes a bit more sense. And it keeps the code stable, but still pretty fresh. We have a new release every six months, whatever is in current will be in the next release in a few weeks or in the worst case in five, six months. How does it work? Well, I think you misunderstood the way we are developing. Like the FreeBSD 11 branches will not only receive bug fixes, but also new features as long as it don't break the ABI and compatibility. Let's say we have a new Clang version, and we need a new Clang version for anything, for a new compiler. Then we can just merge the compiler, and 11.2 will be released with a new compiler. So all the new feature will add up anyway in the releases that the user have. So that's not that different. It's just that we do guarantee that we don't break the ABI. So if you build a binary on FreeBSD11.0, then on 11.3 it will run out of bugs. Okay. Well, you did say that you had to wait for the very least two years before being able to use more than two availability? Before. In the fourth three. Why? Because with the previous model, we had to support a release, and we don't release a new version, because if you release a new version, let's say we release 10.4, then the support gets extended for two years, and then we can't bring new tools. So because the post three works on 11 and 10, then I need to get the compiler I got in my 10.4 working for the post three anyway, or the feature that I added, which are in FreeBSD11, and not yet in 10, I would have to wait two years in the post three to be able to use them, which is not the case anymore, because with a new model, what I do is just merge that to 10, release a new version of 10, and then in that case, I don't extend the support, but still the user benefits from the new tool and the post three can just straight away use it. So we fix that with the new release model. Okay. Anyone got it? I'm still a bit confused, but okay, trust you. Yeah. Okay, let's talk about binary updates. Yeah. Let's talk about binary updates. Okay. Given with the support binary upgrade, it's very easy to upgrade from a new version to a new version. Let's say I release FreeBSD11.1, I just do FreeBSD updates, FreeBSD, sorry, FreeBSD upgrade, and I'm going to the new version in place, and that's fairly nice. But I'm also able to go from, from a micro-release to another release and do a nice upgrade. So it's very simple. It helps us to do a lot of things, and seriously, how tedious it should be for me to update openBSD boxes where you're breaking ABI, you can't upgrade in place and... Well, well, well, well, well. I see what you're going with. Actually, it's not entirely true, as I mentioned earlier. Binary upgrades between releases are perfectly supported, obviously. What is not supported, indeed, are in-place upgrades of the base system, at least. Well, I don't see it as an issue. Usually, supporting in-place upgrade is nice when the actual upgrade process takes a long time, so that you don't want to have your machine offline for like 30 minutes. But when you have a machine in production, you have redundancy anyway, right? So I don't see it as a big, big issue. Also, the upgrade process of openBSD itself is one of the easiest and fastest that I've worked with. That's actually an objective review. It is, it is. I mean, just review it on the BSD-RD RANDIS kernel, and it will do the rest for you in like three minutes, seriously. And with support for auto-install and auto-upgrade in openBSD, you really have absolutely nothing to do. It's completely automatic. I mean, you can upgrade like thousands of blocks by just rebooting on the proper kernel. Everything will be automatically upgraded. Packages included. And when you first boot after your upgrade, we have SeesMerge, which is like a merge master tool in freeBSD, is run automatically very early during the boot process. So even your configuration file will have a good chance to be automatically updated as well. The thing is that, the thing is that if you tweak your configuration file a lot, then obviously it will require manual intervention. It will not try to force a greater file. It's a merge, I think so. It's complicated anyway. I'm telling you that this and this and this by this conversion. There is no configuration file that will prevent you from booting. Because the tool is run after. Don't try and trick me here. Okay, so that's not that bad. So you're able to go from a release to a release seems that it's pretty okay. But what you do to update in your, I mean, you've got security issues and you need to get a date from your system. It's running, what do I do? Seriously, I take the patch, I apply it to your CVS and I build? Yes. Welcome to the 80s. Well, yeah, I mentioned it a bit earlier as well. It's true that the dates within a particular release are not supported. They are supported using a CVS patch. So you have to build a new release yourself or I mentioned CVS patch earlier. Hopefully it will be enabled for our next release, 6.1 in a couple of months. It will be a technological preview meaning that the tool will be there hopefully. The weight work may change for 6.2 or 6.3. You can learn how people use it and the usage that they're doing with the tool. So what we did is that we tried to create something really stupid and simple, something that would just fetch precompiled tarble, same kind of tarble that we for the base system set. So fetching, verifying, with signify, and then installing the new binaries, libraries, etc. While creating a rollback tarble in case something bad happened or if you need to rollback a patch for whatever reason. So we're trying to have a very, very, very simple tool and hopefully people will like it and that will become permanent. Cool. Yeah. Hopefully. Well, on FreeBSD we do support right now already binary upgrade in place which are very nice. I mean, you get the issue that FreeBSD that fetch filter that's installed and then everything has been replaced, modified. So the way the tool works is basically it works based on binaries. So the security officer will just rebuild the system, make a binary of the binaries that has changed between the two builds and then you fetch it and you install it. It works very nicely. It's very convenient for security fixes. It's very simple for the user. It's safe. FreeBSD does a bit more things like I said earlier a way to inform a release to a release. So the way it does is the same way you do fetch. All your new binaries will actually patches between the old release and the new release. And then it's installed a new, well, patch your kernel and prepare the kernel. You reboot the new kernel. You're on the old user learn but the new kernel then you install the new user and that's to prevent having new user learn that might have Cisco that doesn't exist yet in your old kernel. And then it met all the configuration file and hopefully everything works. This is nice. It works fairly well. The problem is it can be very long. I mean by very long is try to fetch something like 100,000 of binary patches until they get it. Try to wait for your shell script to figure out which one it should patch how it verifies checks some signatures, blah, blah, blah. So it can take a very long time to be able to upgrade from a release to another one. So we are now trying to experiment with replacing that package itself. So if we package the base system so it will remain the base system but split into multiple packages then it depends. I don't know yet to be honest but a lot. And then when you get security update you get a new version of your package and then you package upgrade it's installed like every single thing we have in the directory on the packages already. That might be way faster than what we have right now. One of the issue to be honest with there is some drawback with in place upgrades is we depend on some technologies that we don't develop initially by ourselves or we depend on another stream which we work with, like ZFS and that upstream for them the upgrades are a bit like on OpenBSD like you get a release and a release try to go to the new release and so the kernel and the user has to be the same in sync. While in FreeBSD there is a moment you are on a new kernel and you still have the old user. Some function from ZFS has changed then your user won't work with that and we had a couple of time to re-implement the backward compatibility into ZFS to make sure that we can support our ZFS upgrade so it's extra work sometimes but I think it's well-surprised. Do try to be very, very clever here. We have way much to improve in that. But anyway, I can play some great that's nice, but you still need to reboot it. If you had in place of great that you don't need to reboot then you have my vote but other than that I don't really see the point. Yeah, well anyway another interesting thing we have in the FreeBSD model is what we call Paula it's principle of least astonishment so basically it means that don't try to perk up the user system. So if something was working new, make sure that you don't break everything on the system and that your upgrade goes out of the box. Yeah, and you know we're not afraid of breaking backward compatibility when we think it makes sense and can help us push ideas forward. But that's it, I can understand the need for Paula obviously. Except when it goes against basic security. Like for example, reading your upgrading files somewhere in the source tree, SSH or something I see that just to satisfy third party clients, you guys get DSA encryption, AES, CBC SSH1 support like month and month after upstream actually removed it. Yeah, because on the release we didn't want the guy to be able to upgrade and having their key not working but on the next major release we removed that. So yeah, given our model it's month later for sure. But that's not exactly also does not really prevent every such thing. We could have removed that if we wanted. That's the drawback of Paula. People don't like to do something they scream at Paula and say hey, don't touch my system. While Paula says we should not fuck up the system of the user but sometimes we need to and so we need to tell them how they will have to upgrade and have warning long enough in advance and things like that. So yeah, we have to be very careful about Paula. It's a very nice principle. It's just not an excuse to not do anything. Yeah, yeah. Speaking of a great delivery it would be interesting to know how you guys build and ship packages. On OpenBSD we use a tool it's called the DPV the distributed package builder. It's a pearl demon that orchestrates multi-node setup for building the entire port street or a handful of packages. It allows us to build the entire set of packages in less than 24 hours which is convenient so we can have a new set every day. As most of our demon it comes with privilege separation. It runs at a different build user as I mentioned earlier. It uses short sandbox to build packages. The actual package build will have its own sandbox. So there's work in progress for that. And as I mentioned, the only process that goes on now is the affection BTS 5.0. Well on FreeBSD historically we were using a tool which had a design besides being the total crap which was particularly to DPV it was called tinderbox. And it works quite okay back in the time but we changed that to a new tool which actually I wrote. Stop showing off. Yeah. It's crap as well. And so basically what it does instead of distributing the build which can bring a lot of complexity to the always communication about blah blah blah with this idea to build everything in one single box distributing one build per core so we end up with something like if you have a 24 core box you have 24 packages that are built at the same time. And doing that by surprise we discovered that we got faster builds. We ended up with something like a single day to build the entire port 3 back in the time when it was only 24,000 packages. Now it's way more and now Chrome exists. So aside from that what we have is the packages are signed on a box with the internet access the main difference with the way you are doing is probably because we don't sign per package. We sign the entire repository which has hashes of what package is so we have only one signature to check instead of taking per package. Yeah that's the difference. We don't want to rely on the repository method data for anything so indeed we do sign each and every package which make them also easier to share. But yeah. Since we said to put the year we are now able to provide updates and binary packages almost every day well before it was whenever that cluster was happy to build things and to build things properly. So while working on that that new tool to have a lot of well to have faster builds whatever we use every single functionality that we have obviously like we use gels to separate the builds to make sure that they don't have access to the network when they don't need access to the network we can use ZFS to have a fast population of the various gels so it's building a single jail on a single core. We use the MPFS if we want fast IO and of course we do use SMB because yeah we can run on more than 24 cores Speaking of multiple cores are you guys still having the giant look somewhere about everywhere? Yes, yes we do. Ok there's working progress obviously but honestly for regular desktop usage or big log SMB implementation model so the kernel log is good enough. The reason is that most time on the workstation you only have two cores two and eight and only one socket and our actual scheduler isn't bad either it's just that it's a bit old it was written for real SMB machines meaning that it does not consider the cache distance between the cores and that's one of the main reasons why the machine with several sockets often have lower performance than the one with only one socket We do a lot of ping pong so we can use 24 cores but in the context of bug build it's way way better for us in terms of performance to actually split this 24 cores into six different machines but yeah hopefully performance will improve. Yeah well I wonder how you will handle this kind of change in the model of OpenBSD because I mean when PreBSD took that road and changed the model to go to something more SMB it took a lot of time it also ended up with some fabulous release like PreBSD 5.0 and so I'm not saying that the road we took well we have to change almost everything in one big release it's the only one to go but I don't see how you can do with very incremental simple way getting rid of this tank lock Okay well there's a few things that need to be incremental because they're not related to the schedule itself like for example some performance issue that we have on OpenBSD actually come from speed lock in our P thread implementation so that's being actually really worked on we do expect a huge improvement in that regard for the next release or the one after and contrary to the myth I mean we scale very nicely on a big user land of course is our road performance on par with FreeBSD's but we have different priorities and we're okay if we lose a bit of performance if that gains more security or more simplicity or something that's closer to the goal that we have To tell the truth anyway SMB support is something that should be done all the time because things change it's okay to multiple course and whatever and on FreeBSD's next challenge it's really to get something like better NUMA aware support in the kernel we need to improve a lot of looking mechanism to get into if we can direction of lockless things so we are experimenting right now with concurrently to kernel what is the current status right now after moving to a fast way our entire SCSI stack and kernel providing already fully SMB for example recently there's been some huge work and progress on making our network stack SMB friendly the goal being to be able to forward traffic over multiple threads I don't think you will argue that modern scheduling is hard as you mentioned it most operating system actually had to do it several times some even rolled back and then when you see what happened in Linux land for example it's completely scheduling they have like 10 different scheduler so yeah that scaling is hard so as usual on OpenBSD we lag a bit behind in that regard that we are also learning from the other operating system mistakes so hopefully we will come there slowly but and hopefully with a simple implementation because that's how we lag when as I said earlier you guys are waiting there right so while you're here can you explain me something I never understand on OpenBSD and the way you involved the project it seems like you keep rewriting all the tools even if there is already BSD license counterparts SNTPD VMM well you're not suffering some kind of NIH syndrome that's actually a very good question I'm glad that you ask it because in my opinion there are very objective reasons to do that the first one would be trust and control we have a coding style, practice and process that makes us confident in what we develop we know someone will not decide to change the software license for example one day to the next or start adding options and knobs for each and every crazy corner case that no one would be using and looking at how many CVEs impacted like NTPD or OpenSSL in the last couple of years should be a good hint as to why it was necessary to actually create NTPD implantation for us or fork and become LibreSSL so I don't think it's really NIH syndrome to write secure implantation even if a BSD counterpart does exist right but there's no BSD quality good enough but not good enough BSD alternatives but what about BHIVE working because of the design it's very easy to add security requirements that you may want and so why started the new implantation well because we had to basically a few years ago an effort was started to report BHIVE but after just a week trying to do that and not even being able to compile like two CVEs we say that if it's that much work to port this software then we just should write our own from scratch I mean the situation may have changed since now BHIVE has been ported to macOS so maybe it evolved but at the time it was really complicated but there was an effort that started so it's not that we said okay let's trade BMM and not look into BHIVE but but on and on I guess having control and rewriting some part of the software ecosystem gives us a base system that in our definition just works and works the way we want it to work like if you ever feel the need to tune or harden something on OpenBSD or tweak billions of options then you're clearly on the wrong operating system that's why also we're rewriting things to be really simple right right but I mean what about the case of sandboxing we have capsicum it works it was there way before OpenBSD so why no there's also a very good reason for that but before we talk about capsicum and our sandboxing implementation since you brought up the subject of security we can talk about it a bit let's go on it so I maybe start with something which is not directly related to security but helps a lot when you develop to get secure applications to not get flows let's talk a bit about our malloc implementation which is the GE malloc yeah so that's always very nice that malloc is very nice because it helps us to you have a lot of tuning you can do on it to malloc.conf or the malloc.conf variable where you can for example prefleek, brothleek which allows you through malloc to detect memory leaks a bit like deep ref tool are doing that we can do heap profiling we can do a lot of things like that we can also put some garbage in the memory when you malloc so that to make sure that you don't occurrence things yeah I think we're pretty similar in that regard our memory allocator has a lot of counter measures as well some are not enabled by default because they're very costly in terms of performance but we developers do run with them because it allows us to catch a lot of different issues beforehand we have a lot of very convenient options in our malloc the capital C option is a good example it enables all the security related options in malloc for security auditing we have part pages that can be enabled so just to provide you with an overrun version a bunch of different different content measures like that yeah it's like both malloc are quite in the same chain regarding debugging and memory related potential security issues in a different way almost the same on a side topic related but different from malloc the way we develop our demons in BSD are always pretty much the same we do privilege separation most of the code is run through it as a non-privileged user and open SSH kind of led the way for the way we're doing things now it was the first to actually implement all of this before anything else in BSD so we use also privilege revocation to draw privilege as soon as possible I mentioned NTPG earlier which is a good example it's a really traditional if you look at the code it's a good example because it's a traditional open BSD written demon it was written with principle of the least privilege in mind so not only does it work set and pre-drop but it also has complete privilege separation TLS speaker for the constraint feature is actually a pretty cool one it allows you to mitigate the man in the middle attack basically when you ask the time from a remote time server you will also connect using HTTPS to a well-known website Google, Apple, whatever and get the time from the web server as well so you can actually compare what the time server and one well-known web server on the internet gives you and if the constraint is too hard then probably there is probably a problem somewhere yeah, the thing is you did that but I have a lot of part in the case of NTP for example you don't support half of the feature that are supposed to be supported like authenticating the peers which are giving you as a time or supporting proper lives account in that case you actually just described exactly the strength of openLTPD it is simple, it doesn't need to authenticate because we use constraints, that's good enough it doesn't need to implement the kitchen scene because no one cares and no one uses most NTPD feature and if there is a need for it then we have the NTPD package that people can install and use instead it's just by default we want something simple and secure and on a really good topic we are well known for our numerous exploit mitigation techniques it's important to note that all of these have been enabled by default for years and they are very hard to actually disable we don't want to encourage people to activate them we actually activate them by default and they are very hard to disable them I won't go into a lot of details but we have ASLR or to know perhaps people here can say ASLR WXORX the stack matching protection from police by executable for static binaries as well the way we approach the OS development is that we assume that we are running in a hostile environment so everything we do is actually on freebies well, we don't have yet ASLR but we have probably a couple of mitigation techniques but we also have something like the MAP which is very nice to be able to compartmentize what an application is supposed to access to as a resource network, fire systems or to view on a system preventing seeing that or other users or the process and way more we also have a very nice auditing framework through OpenDSM which allows you to report everything that happened on your system and even report that on a remote machine if you need to through distributed mechanism we adjusted to a rebound on what you said earlier regarding capsicum so we do have a sandbox implementation, it's called Pledge so now the reason why we did not report capsicum is that capsicum is too complicated I'm not saying it's bad it's a very good capability system it's just too complex and as such we think it doesn't get as much use as it should be the Pledge Cisco is actually very simple and describe exactly how we envision security, we want to provide affordable security by affordable and simple, easy to use and make it easy for the actual developer programmer to add Pledge Cisco into his code when Pledge was implemented 30% of our base system was Pledge after only about two months and today we have between 85 and 90% of the entire user and base that use Pledge and even some big ports like Chromium is Pledge it's actually pretty easy to use and as such people actually use them also has a nice side effect I guess that's also true with capsicum but it encouraged actually re-auditing your code to know exactly where you're going to get so yeah another feature we have on 3D that you don't have is the JLs which are a container secured by design, by default and which allows you to run the process in a prison that cannot do anything if you want to like reducing you can just limit the number of CPU you can limit the memory, the resource the access to the network or no and things like that that is very important to be able to add security on the system yeah, yeah, yeah, in that regard I do agree that we suck we have no container like technology there's been an initial effort a few years ago in the CIS jail but it was using CIS trace which had a big security flow it would that rendered basically the sandbox completely completely new but anyway I think given the time we'll probably skip the project explanation on how the different project works and that's around two which will last for only a few minutes, sorry wait, so it's a two track yeah, it's supposed to be a two track though but right, so let's think about the BSD application I mean, you claim a lot about your license purity, everything should be BSD and we do almost the same but I'm very surprised by the fact that there's a lot of product we're working on to bring BSD license tools in the BSD system and we don't see you in that area in particular when we speak about the toolchain for example we're very close to get the first release without GPL in BSD for Char-1 for what? for Char-1 Char-1 and BSD means the main supported release not in terms of supporting the code so basically right now it's MD64 and IS386 but it means that the one we're providing binary security patches well security, binary security patches because security patches will provide for everything and so that's the most common one, we don't provide for MAPS for even more well see, we support the platform or we don't support it so there is no tier one, two, three on open days together yeah so basically the status right now is on tier one we removed GCC, Leaston.C++ we have a full, almost full compiler chain BSD license we also removed half of the BNUTIL using our home-backed infotainment project which removes everything but the linker we're pretty close to add LLD right now which will be the next linker totally and so the only left thing we removed take info because who reads take info files I mean no one we removed CVS because we're not on CVS anymore we removed ours and GDB is slowly being removed replaced by LLDB so what is left is we still have GNDIV well ASDIV has been replaced by an open BSD and a BSD mix plus some free BSD patches on top of it you might want the patches by the way send them over yeah I need to graph is still there because a couple of main pages are not rendering and because we have a lot of papers that were written back in the old time by free BSD developers that are in the base system that are written in rough so we're still looking at what we do with that the graph is still there because there is too many bugs in BSD graph for now the BSD12 we're pretty sure that will be fully with any GPL license stuff what is the situation for you well okay I will not talk about the license itself because not the religious guy besides a few exceptions most of the user land is BSD license on open BSD obviously still have some kind of a fork of GNU CVS that we cannot remove right now RCS is actually a rewrite BSD rewrite implementation so that's under a BSD license mandoc takes care of all our man needs so we actually don't need a rough rough in the base system at all so it's gone since a while regarding the tool shell tool chain sorry you guys are feeling ahead I agree but we finally did jump on the thanks to the ARM64 architecture so now we do have a lot of VMs laying an older gang in base I don't want to go too much into detail because this effort is somewhat recent so there's probably a lot of things that are going to change in the upcoming month but we're doing pretty much we're going pretty much into the same directions as you guys are LLD C++ etc etc but as I mentioned earlier we have no tier 1, 2, 3 so we still have to support some architecture that will most probably never be supported by LLVM and the gang so we'll have to keep GCC and such in base yeah so I'm pretty sure that it took that long because you wanted to skip one of the subjects which is this one we don't want to talk about that yeah I think we will have to well it will be very quick so basically we have a lot of system support including very modern one we have journalization, soft update seeing that we have very nice SCSI support, very low level system for storage multi pass, encryption whatever, what is the situation I don't think people are really interested well I guess well I will summarize it by saying that we still have bugs in soft updates yeah but I mean you guys have curve yeah true but yeah no we don't have ZFS obviously so I guess licensing but not just that I use ZFS daily on different operating systems it's really great it's just super scary what scares me the most is that it requires ECC memory and when a fight system requires ECC memory it doesn't really well it's highly recommended it works without it so that's kind of scary it's big, it's not just a fight system it's actually an entire volume maintenance whatever but it's a feature wise it's great it's awesome we don't have time to compare our desktop situation well we're actually pretty much the same on the desktop I guess yeah we sucks I think it's getting there it's not that they're true we have all the packages and everything but I mean the drivers are still lagging behind and the Wi-Fi anyway so what's the thing considered experience that might be as these sucks less than yours I'm not really sure I pretty found that mine sucks very well less than yours anyway I'm really happy that OpenBSD that's more than FreeBSD is around as they push a lot of BSD license tool and they are very pushing also security security coding principle and widespreading that so I'm very happy that you were there guys thank you well I think FreeBSD is very important as well first of all it's a real enterprise operating system and it's for me the way I see it I'm slowly filling up the spot left by Solaris I found some amazing piece of technology and what is great about it is that it's actually our emblem to the external ecosystem that is people know about FreeBSD huge company like Netflix so it's not just like some weird fringe operating system thank you so we both organized the next EuroBSD code in Paris in September so we hope to see you everyone there save the dates and you can have the long version of the talk yeah so actually we know now that it will be two hours well in French anyway thank you very much