Quote:
Originally Posted by knasbas
Basically what I do is that install latest version, update it to stable...
|
Once? Or regularly throughout the life of the release you've installed? Of course, the life of any release is only
one year. Support:
- accepting problem reports
- publishing patches
- updating the -stable branch
cease when the release reaches end-of-life.
Quote:
...I havent kept on updating nor upgraded to latest version, which is a securityrisk, i know...
|
When did you last build 4.0-stable? A remote attack vector was announced and a patch published in March, 2007.
Quote:
...I just feel safe with openbsd.
|
I don't understand why you might feel "safe" when you acknowledge an unsupported release is risky. There are many security and reliability fixes to the OS which are never backported to unsupported releases, such as yours.
Quote:
About updates, i understand the securityrisk but at the same time, if you dont mess with a working system, that system can keep running forever.
|
Your definition of the word security must not be the same as mine, then.
Security is
not something you buy, download, or install.
Security is a process. A
continuous process.
Using the example I cited above, OpenBSD may be "secure by default" but has had two remote attack vectors exposed in its lifetime. How many unexposed ones exist now? No one knows about the third (or fourth..) until it is discovered, analyzed, and published. Is one there? No one knows for sure, but I'll guess that more will be uncovered over time.
That's it for remote security issues. What about internal problems that affect security?
From the beginning of the Project to present day, internal attack vectors are discovered, analyzed, published, and patched. For example, since support ceased for 4.0, there have been six serious security patches published.
More security flaws
will be found, and that continuous process to improve security
will continue, through the life of the Project.
Quote:
Originally Posted by snes-addict
...the only thing you should have to worry about is properly merging in the new /etc files with your own installed /etc files.
|
And some files in /var, as well. Each upgrade guide describes the affected changes that require manual effort. For older releases, the mergemaster package can automate much of the effort of making these changes; in newer releases, the
sysmerge(8) built-in tool replaces mergemaster.
Quote:
Originally Posted by KlaymenDK
...Isn't that why OpenBSD is slow to include all the latest bells and whistles
|
Is that in references to ports/packages? If so, that's because the kernel, userland, and ports trees are synchronized. See FAQ 15.4.2 for details.
Quote:
You need to consider if you're focusing on security, stability, or features.
|
Exactly. It is possible that knasbas has confused security with stability.