> Food for thought: Is it even remotely possible that the very act of removing those 50K lines will, in and of itself, unknowingly and unintentionally expose additional bugs?
The largest removals were strictly dead code. I.e. code that has not been and never will be compiled on OpenBSD. Removing that cannot introduce bugs.
Other removals include very obviously broken re-implementations of library functions like calloc, to be replaced with calls to the real function.
The crappy pseudo rng was removed, and replaced with calls to arc4random which is hard to misuse. Along with this change went some rather questionable tricks ("hey, let's feed rsa keys and our private exponent to the rng if it runs out of entropy"). Some APIs became no-ops, so they can no longer be abused.
There are other changes which are more refactoring than removal. These did (and do) include the occassional mistake, but they get spotted pretty quick.
Someone up the thread asked who is reviewing these changes? Well, I can assure you that many people are. But it can not hurt to have an extra pair of eyeballs so anyone reading this -- please join the effort and watch the diffs. If you see a mistake, you can email the developer or tech@.
Do you know how many of the interop code paths are untested, totally irrelevant on any modern system, and probably broken? Do you understand that when the OpenBSD developers review, clean up, and change the surrounding code, the ifdeffed code parts that cannot be tested on OpenBSD will detoriate further and break even more than they are broken already?
Do you know that there is a better way to port software to crappy OSen than making critical sections a ghastly jungle of #ifdef? That code really needed to go. It would only get in the way otherwise. Once the code base is cleaned up, it shouldn't be too difficult to take it make a -portable version to run it on other OSes. Believe it or not, they do not need or have that many nonportable OS-specific things in crypto code.
At least one bug discovered on OpenBSD (after heartbleed) has already made it to other systems with OpenSSL. So quit spreading bullshit about the OpenSSL ecosystem not becoming any safer.
Only on i386. AFAICT Linux emulation isn't horribly accurate or complete anyway. It might be good for some applications and not for others.
Getting nonfree binary only software to run on the OS isn't a priority. At all. As Theo says, we live in a source world, and compiling software is the only way to get some of the security features on OpenBSD. Besides, binary compatibility leads to Windows & x86-esque horrible backwards compatibility bloat, with support for obsolete and outright broken interfaces...
As for your understanding about ISC, MIT, etc: can you point where exactly any of these licenses grants anyone the permission to change the license or sublicense or whatever? The copyright holder holds the right to do that. Where do the licenses grant the right to change the license? Last time I looked, they only granted rights to modify, distribute and sell the work the license covers. Not the license itself. In fact they explicitly ask you to retain the license.
And why the gripe about Linux using BSD code? Well I have a gripe with them claiming to be "free" and then change the license of free code to a non-free one, making it impossible for any useful modifications to flow back to the original free code. That is hypocrisy, and it is in my opinion extremely rude and disrespectful towards the original authors.
Much of "Linux people" are such hypocrites all the time, not just during this one incident. And there are many other incidents with "Linux people" switching over to more restrictive licenses. All the while still claiming to be free.
The implementation of ASLR is not secret. It's not security through obscurity.
Compare with with cryptography: if someone makes his homebrew crypto algorithm and keeps it secret, hoping it is more secure because others don't know how it (the implementation) works, that is security through obscurity.
But if you use known, documented, public crypto primitives, you're not using a secret design or implementation. You still use random data in keys, nonces, etc. But that randomness is not secrecy of design or implementation. It is not security through obscurity, just as ASLR isn't.
In the past OpenBSD has been pushing hard for things like priv sep, stack layout changes and smashing protection, address randomness, guard pages, minimum permissions everywhere, more randomness everywhere, etc. The result is a system where sloppy code is very likely to just crash before causing any harm. It helps towards making the system secure, and it also makes software development on the OS oh-so-nice.
I realize OpenBSD's security isn't all about features like the ones listed above, but can we look forward to some new exciting techniques that push the idea further?
Thank you for a superb free operating system. And thank you for pushing the software ecosystem towards better quality standards!
Slashdot Mirror
Why don't you do it. See how you far you can make it.
You severely underestimate the amount of work a clean reimplementation would require.
And what is wrong with fixing crappy code?
> Food for thought: Is it even remotely possible that the very act of removing those 50K lines will, in and of itself, unknowingly and unintentionally expose additional bugs?
The largest removals were strictly dead code. I.e. code that has not been and never will be compiled on OpenBSD. Removing that cannot introduce bugs.
Other removals include very obviously broken re-implementations of library functions like calloc, to be replaced with calls to the real function.
The crappy pseudo rng was removed, and replaced with calls to arc4random which is hard to misuse. Along with this change went some rather questionable tricks ("hey, let's feed rsa keys and our private exponent to the rng if it runs out of entropy"). Some APIs became no-ops, so they can no longer be abused.
There are other changes which are more refactoring than removal. These did (and do) include the occassional mistake, but they get spotted pretty quick.
Someone up the thread asked who is reviewing these changes? Well, I can assure you that many people are. But it can not hurt to have an extra pair of eyeballs so anyone reading this -- please join the effort and watch the diffs. If you see a mistake, you can email the developer or tech@.
Do you know how many of the interop code paths are untested, totally irrelevant on any modern system, and probably broken? Do you understand that when the OpenBSD developers review, clean up, and change the surrounding code, the ifdeffed code parts that cannot be tested on OpenBSD will detoriate further and break even more than they are broken already? Do you know that there is a better way to port software to crappy OSen than making critical sections a ghastly jungle of #ifdef? That code really needed to go. It would only get in the way otherwise. Once the code base is cleaned up, it shouldn't be too difficult to take it make a -portable version to run it on other OSes. Believe it or not, they do not need or have that many nonportable OS-specific things in crypto code. At least one bug discovered on OpenBSD (after heartbleed) has already made it to other systems with OpenSSL. So quit spreading bullshit about the OpenSSL ecosystem not becoming any safer.
Only on i386. AFAICT Linux emulation isn't horribly accurate or complete anyway. It might be good for some applications and not for others.
Getting nonfree binary only software to run on the OS isn't a priority. At all. As Theo says, we live in a source world, and compiling software is the only way to get some of the security features on OpenBSD. Besides, binary compatibility leads to Windows & x86-esque horrible backwards compatibility bloat, with support for obsolete and outright broken interfaces...
Source portability is the right thing to aim for.
It's not that they can't touch it. But they (OpenBSD) have decided not to incorporate any more nonfree code in to the project.
You could follow the cvs logs. Maybe the discussion on tech@ too.
I can't speak for Theo, but... if you look for it, you can find the attribution in Microsoft's stuff.
http://www.terminally-incohere...
As for your understanding about ISC, MIT, etc: can you point where exactly any of these licenses grants anyone the permission to change the license or sublicense or whatever? The copyright holder holds the right to do that. Where do the licenses grant the right to change the license? Last time I looked, they only granted rights to modify, distribute and sell the work the license covers. Not the license itself. In fact they explicitly ask you to retain the license.
And why the gripe about Linux using BSD code? Well I have a gripe with them claiming to be "free" and then change the license of free code to a non-free one, making it impossible for any useful modifications to flow back to the original free code. That is hypocrisy, and it is in my opinion extremely rude and disrespectful towards the original authors.
Much of "Linux people" are such hypocrites all the time, not just during this one incident. And there are many other incidents with "Linux people" switching over to more restrictive licenses. All the while still claiming to be free.
Can you point to all these ample examples so we can see and judge for ourselves?
The implementation of ASLR is not secret. It's not security through obscurity.
Compare with with cryptography: if someone makes his homebrew crypto algorithm and keeps it secret, hoping it is more secure because others don't know how it (the implementation) works, that is security through obscurity.
But if you use known, documented, public crypto primitives, you're not using a secret design or implementation. You still use random data in keys, nonces, etc. But that randomness is not secrecy of design or implementation. It is not security through obscurity, just as ASLR isn't.
In the past OpenBSD has been pushing hard for things like priv sep, stack layout changes and smashing protection, address randomness, guard pages, minimum permissions everywhere, more randomness everywhere, etc. The result is a system where sloppy code is very likely to just crash before causing any harm. It helps towards making the system secure, and it also makes software development on the OS oh-so-nice.
I realize OpenBSD's security isn't all about features like the ones listed above, but can we look forward to some new exciting techniques that push the idea further?
Thank you for a superb free operating system. And thank you for pushing the software ecosystem towards better quality standards!