Linked by Mark Tolliver on Thu 13th Sep 2007 08:14 UTC
Editorial 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.
Thread beginning with comment 271097
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Response times
by dylansmrjones on Thu 13th Sep 2007 17:06 UTC in reply to "RE[2]: Response times"
dylansmrjones
Member since:
2005-10-02

How often has OpenBSD had to fix a serious security hole? How fast did they fix it?


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.

Reply Parent Score: 2

RE[4]: Response times
by dagw on Thu 13th Sep 2007 17:47 in reply to "RE[3]: Response times"
dagw 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.

Reply Parent Score: 2

RE[5]: Response times
by dylansmrjones on Thu 13th Sep 2007 17:54 in reply to "RE[4]: Response times"
dylansmrjones Member since:
2005-10-02

If the actual loss in productivity due to reduced functionality overshadows the cost of a potential security breach, then you probably want to reconsider.


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.

Reply Parent Score: 2

RE[5]: Response times
by WarpKat on Thu 13th Sep 2007 18:51 in reply to "RE[3]: Response times"
WarpKat 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.

Reply Parent Score: 1

RE[4]: Response times
by sappyvcv on Thu 13th Sep 2007 21:16 in reply to "RE[3]: Response times"
sappyvcv 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.

Reply Parent Score: 1