I think we need to fund regular audits of FreeBSD that use this type mindset.
* https://www.viva64.com/en/b/0496/ (https://news.ycombinator.com/item?id=14057568)
* https://www.viva64.com/en/b/0377/ (https://news.ycombinator.com/item?id=11131532)
* https://www.viva64.com/en/b/0487/ (https://news.ycombinator.com/item?id=13894115)
If he had spent three times more time on freebsd than on openbsd I would agree with you.
In statistical analysis you need to have a clear definition for your "unit of observation". Is it individual lines? Is it individual methods? Is there some way to break down code intofunctional units? Is it entire code paths?
Without having a well-defined unit of analaysis and a consistent sampling scheme, extrapolation is difficult or impossible using conventional statistical tools, without making some very big assumptions.
But Page 6 of this pdf has OpenBSD developers going on about Linux and its 20 localhost kernel security holes in 2005. Seems a bit dishonest.
I get it, preventing local privilege escalation on *NIX is hard, and I appreciate OpenBSD's focus and stance on security, v.s. say Linus's more laid-back attitude. And having arguably fewest of them is an achievement, even if it's not zero. Let's focus on making OpenBSD better and not belittling other's shortcomings.
I have an OS I coded my self that no one has ever found a vulnerability on.
The answer is a bit of both.
Side note: I'm hugely grateful for all your work on OpenBSD.
www.tedunangst.com uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported.
Error code: SEC_ERROR_UNKNOWN_ISSUER
And in Chrome:
Attackers might be trying to steal your information from www.tedunangst.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
> Yesterday, reading this page in plaintext was perfectly fine, but today, add some AES to the mix, and it’s a terrible menace, unfit for even casual viewing.
LetsEncrypt isn't perfect either. You've got to be cognizant of what details you are sharing over the connection, regardless of who signs the certificate.
> You've got to be cognizant of what details you are sharing over the connection, regardless of who signs the certificate.
So why not cut out the browser errors, for free? Somehow this vaguely feels like Don Quixote straining hard to hold onto the original definition of the term "hacker".
Props to this guy for sticking to his beliefs; I don't mean for this to be interpreted as saying anything should be changed.
- protected from alteration of the data in transit without either end's knowledge
and, IF you have a means to authenticate the owner of the certificate outside of the regular certificate signing process
- protection from impersonation of the other end of the connection
It's just a blog; I'm not submitting anything, but still it's an indicator that something fishy might be going on.
Welcome to *BSD
expired pointers, Double frees, Underflows, overflows, signedness, NULL deref, Division by zero, Memory leaks
There have been operating systems written in mostly safe systems programming languages since the 60s, 10 years before C was born.
Burroughs created ESPOL and NEWP, IBM did their RISC research with PL/8, Xerox had Mesa/Cedar, UK Royal Navy Algol-68RS, and many many others with Midori's System C# being the latest example.
If there isn't political will, there isn't the motivation to overcome any technical hurdles that might appear.
Now even with Microsoft adopting a Linux compatibility layer we are reaching the age of UNIX mono-culture, and its dependency to C for kernel development.
So the question is who will have the political will to break this reality, and drive the technical adoption regardless of the hurdles that might appear along the way.
However, now that OpenBSD is continuing to switch from GCC to LLVM/clang as the default C compiler for an increasing number of targets and as an increasing number of non-LLVM-supported targets are discontinued, I reckon the idea of some or all of OpenBSD being incrementally reimplemented in Rust is - bit by bit - becoming a little less far-fetched. It also helps that Rust is liberally-licensed.
That all said, I'm not really holding my breath for that happening anytime soon. Until then, Redox continues to look interesting.
That being said, I still think the best strategy will be to start porting different portions of the Kernels to Rust. Perhaps starting with drivers. There have been a few examples of Rust drivers for the various OSes out there.
First, the maintainers have to believe that this is better than continuing with C. That doesn't seem to be something everyone believes.
Although I doubt we'll see a big one, there's already smaller projects that do useful stuff with safer languages. ExpressOS comes to mind given the kernel is C# and Dafny running Android apps that are Java. The L4 kernel and Linux remain in the system with L4 replaceable by safe stuff like Muen in SPARK language. Replacing Linux will be a lot harder. ;) However, if wanting mobile or other apps that aren't Android compatible, one might be able to use work like Redox, JX, or Oberon to eliminate unsafe language entirely.
Another in alternative OS's is A2 Bluebottle from Wirth's people at ETH written in an Oberon dialect. Main Oberon OS is designed for simplicity and teaching. A2 is a batteries-included OS with a GUI designed to be useful. When I tried it, it ran snappy fast with networking, editor, compiler, and so on. Very minimal given only a few students worked on it but it is usable and extendable. Below was first link I found in Google so I haven't vetted it.
Redox OS in Rust can do a lot currently. They plan to expand it more. Already has a GUI, shell, networking, and the standard library of Rust.
If I had to place bets, therefore, I'd say that Android is best placed to get closest to the ideal of a fully safe OS within 10 years. I have no idea if Google would do it, but they have the funds, the security commitment and there's a clear path opening up for them to make nearly all userland code in Android safe. But it doesn't look like "rewrite everything in Rust". It looks like this:
Continue to improve ART's JIT and AOT compilers, possibly teaming up with the Graal project. The Java guys are doing a lot of work right now on adding support for value types and subsequent large upgrades to support for vectorisation (as with value types you can represent 256-bit wide primitives and things like that). This unlocks the potential to port parts of the most security-vulnerable and performance sensitive components like the media server and media codecs into Java or Kotlin, without much performance slowdown (bulk of the most important h264 decoding is done in hardware anyway).
But there will still be lots of C/C++ code in Android and rewriting it would be very expensive. So a feasible next step is to swallow the bitter political pill and team up with Oracle Labs to get access to SubstrateVM + Managed Sulong (or wait and see if they are open sourced). This rather magical combination of tools appears to offer the potential to run anything LLVM can compile in a way that eliminates all forms of memory unsafety including buffer overflows, out of range reads/writes, double frees etc at a nearly trivial cost (around 10-20% at most):
If this technology lives up to its potential, and it seems like it is in with a very good chance based on progress so far, I suspect we'll see a loss of interest in Rust over time ... at least for the "make existing software secure" use case. Managed Sulong + SubstrateVM can run C/C++ code that is strictly standards compliant (it struggles with code that makes spec-violating assumptions as it exploits UB very aggressively), but it's much easier to fix compliance issues in an existing codebase than rewrite it from scratch.
The Android team have already switched to OpenJDK and abandoned their plans to rewrite the Java compiler, so with the resolution of the Oracle lawsuits they do seem to be technically moving closer to the Java platform rather than away from it. Collaboration between Google and Oracle on this doesn't seem as unthinkable as it once did.