OpenSSL is not part of the OpenBSD project in the same sense that OpenSSH is.
I have never said that OpenBSD's auditing will catch all bugs before code goes into production (the auditing is after all done by humans with limited amounts of time at their hands) but it certainly helps a lot.
I find that an auditing process may in fact speed up development in bigger projects, since it catches a lot of non-security related bugs and also improves both code and documentation in general.
Maybe the Linux developers could learn something from the OpenBSD project and its continuous source, documentation and license auditing. The process not only catches security holes, but also results in cleaner code, better documentation and a more stable system in general.
>... because it would be a problem trying to > adapt users to the level of security in OpenBSD.
This is just silly. From the users point of view, switching to OpenBSD from Linux is not any harder than switching to FreeBSD or NetBSD. Most of the security comes from code audits and chanfes which are invisible to the user.
> I made a few installs of OpenBSD and I may > tell you that it is not easy to install > something on it.
Installing a pre-compiled package bar-1.0.tgz: # export PKG_PATH="ftp://ftp.foo.com/pub/OpenBSD/ 3.1/pack ages/i386" # pkg_add $PKG_PATH/bar-1.0.tgz This will automatically fetch all pachages, on which bar-1.0.tgz depend, from the FTP server named in PKG_PATH.
Installing bar-1.0.tgz from ports: # cd/usr/ports/gazonk/bar # make # make install This will fetch all required sources, including dependencies, compile them, build packages, and install the packages. You can then uninstall the packages just like you do with the pre-compiled packages.
Installing from source mostly just requires: #./configure # make # make install with the exception that you sometimes have to use GNU make (gmake). What so hard about these procedures?
If it was oss software, I doubt you would be guaranteed to get a team dedicated to fix a problem.
I hope that you are aware of the fact that there are companies out there, like the one where I work, who provide commercial support for OSS.
It is really simple: Provide money and you get a guarantee that there will be a dedicated team of clever people working on any eventual problems you have with the OSS you use. No exams or real jobs will get in the way, and there will be someone to blame if things go wrong. As I see it you get the best of both worlds this way. And yes, we have previous experience working on software used in the aviation industry...
Not all OSS groups are like Debian. Maybe you
should take a look at OpenBSD and it's history of on-time twice-a-year releases. I bet you will not find many commercial projects with better release histories than that.
Slashdot Mirror
OpenSSL is not part of the OpenBSD project in the same sense that OpenSSH is.
I have never said that OpenBSD's auditing will catch all bugs before code goes into production (the auditing is after all done by humans with limited amounts of time at their hands) but it certainly helps a lot.
I find that an auditing process may in fact speed up development in bigger projects, since it catches a lot of non-security related bugs and also improves both code and documentation in general.
Maybe the Linux developers could learn something from the OpenBSD project and its continuous source, documentation and license auditing. The process not only catches security holes, but also results in cleaner code, better documentation and a more stable system in general.
> ... because it would be a problem trying to
k ages/i386"
/usr/ports/gazonk/bar
./configure
> adapt users to the level of security in OpenBSD.
This is just silly. From the users point of view,
switching to OpenBSD from Linux is not any harder
than switching to FreeBSD or NetBSD. Most of the
security comes from code audits and chanfes which
are invisible to the user.
> I made a few installs of OpenBSD and I may
> tell you that it is not easy to install
> something on it.
Installing a pre-compiled package bar-1.0.tgz:
# export PKG_PATH="ftp://ftp.foo.com/pub/OpenBSD/
3.1/pac
# pkg_add $PKG_PATH/bar-1.0.tgz
This will automatically fetch all pachages, on
which bar-1.0.tgz depend, from the FTP server
named in PKG_PATH.
Installing bar-1.0.tgz from ports:
# cd
# make
# make install
This will fetch all required sources, including
dependencies, compile them, build packages, and
install the packages. You can then uninstall the
packages just like you do with the pre-compiled
packages.
Installing from source mostly just requires:
#
# make
# make install
with the exception that you sometimes have to use
GNU make (gmake).
What so hard about these procedures?
And they were all well-off, spoiled brats that think they can solve problems by blowing things up.
Yes, can you imagine a person like that as the US president... Oh, wait...
If it was oss software, I doubt you would be guaranteed to get a team dedicated to fix a problem.
I hope that you are aware of the fact that there are companies out there, like the one where I work, who provide commercial support for OSS.
It is really simple: Provide money and you get a guarantee that there will be a dedicated team of clever people working on any eventual problems you have with the OSS you use. No exams or real jobs will get in the way, and there will be someone to blame if things go wrong. As I see it you get the best of both worlds this way. And yes, we have previous experience working on software used in the aviation industry...
Not all OSS groups are like Debian. Maybe you should take a look at OpenBSD and it's history of on-time twice-a-year releases. I bet you will not find many commercial projects with better release histories than that.
Just for reference...
X11 window manager written in Python:
PLWM
X11 client-side implementation written in Python:
Python X Library