The widespread acceptance of open source continues to grow as a cost-effective alternative to traditional network deployments. Well-known projects such as Linux have proven themselves to be in the enterprise environment, helping to dispel the fear, uncertainty and doubt preceding open source implementations. In the past two years, the industry has begun to shift from a total dependence on proprietary applications to a desire for more cost-effective, scalable and collaborative solutions.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.
That depends entirely on the application and situation. If the actual loss in productivity due to reduced functionality overshadows the cost of a potential security breach, then you probably want to reconsider. You want to find a balance between ease of use and security, taking into account all surrounding factors.
Member since:2005-10-02
That is however not a concern of the company behind the product, but merely a concern of those using the product.
1) It is the responsibility of the developers ( or the company/companies) to deliver a fix here and now.
2) It is the responsibility of the users to decide whether or not to install the fix.
If installing the fix breaks the users software and this is more expensive than a security breach, they shouldn't install the fix. If the security breach is more expensive than reduced functionality, they should install the fix. The developers however only have the responsibility to give the users the choice.
Finding the balance is solely the responsibility of the users.
Member since:2006-02-06
Keep this in perspective: Packages vs. what's needed to bring up a system are entirely different concepts.
If someone wrote a program to exploit a hole in the kernel, that's one thing. If an admin installs an FTPd, for example, they do so knowing that just because it's made to be compatible with the OS, doesn't always mean it's the most up-to-date port when dealing with Free/OpenBSD, which can result in an exploited system if the package goes unchecked - and that's up to the maintainer at that point.
If the port/package maintainers are lazy, then there's a HUGE problem. If the original authors are lazy, there's an even bigger problem with the solution to fork or take over the project somewhere else.
I've not meddled with the BSD's long enough to get into who's lazy and who isn't, so I'll let this one off here, but I will re-state that the differences between OS and other software packages are clearly distinct.
And yes, I get a "Thank you, Captain Obvious" here as well.
Member since:2005-07-06
What if the fix introduces another security hole? What if it breaks a major feature? I'm sorry, but except in extreme cases (say a worm thats been spreading over the net fast using the exploit), you need to properly test the fix first.
When possible, some companies do provide temporary workarounds until the fix is properly tested and released.
It requires a massive coordination to implement a proper fix.
Member since:
2005-10-02
In the default installation? Very seldom. But fixing serious vulnerabilities in their packages (not default installation) ? Constantly. Just because a port isn't a part of the default installation, doesn't mean it's not meant to be fixed
And OpenBSD has so far fixed their holes within hours. It is typical for MOST FLOSS-projects. Security! Security! Security!
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.