On 20/05/07, Steve Holdoway <[EMAIL PROTECTED]> wrote:
FYI is is imperative, in a production environment, that you build your web (and mail, and anything else that's regularly attacked) servers from source, along with any server side scripting languages you wish to support. This is because you need to be able to respond *IMMEDIATELY* to any security holes picked up in these products, and not to wait for the patches to become available through the normal channels. And, even if you're just a hoppyist, it's a clean and harmless way of passing the time.
In a production environment is is actually imperative to evaluate risks carefully. From your description above, it doesn't sound like you're creating your own patches based on announced vulnerabilities, so I guess you're talking about taking the package author's patch for a problem, and applying that, and the wait that you're referring to is the amount of time for your distribution's security team to take the same patch and port it into the repository. So, how much better are *you* than your distribution's security team? How much better is your test framework than theirs? For some distros, anything is better than nothing :-) For a mature repository-based distro (thinking specifically but not exclusively about Debian here), they are fast and accurate, and they backport security patches to versions that the original author has long since abandoned (and that's very common indeed). Now, I know you've spent a lot of time in multiple-distribution environment, judging by your posts to this list over time, and as such you might not have any choice but to follow all the security announcements by all your key product authors. But the rest of us should be choosing their production environment with the performance of the security patch team as a major aspect. Over the last few years I've been happy with the responsiveness of the Debian security team. They have been known to issue patches for products that have not had an upstream patch. They've stripped security patches out of upgrade patch bundles - and that's not an easy job. And throughout most of that, they've been able to keep my machines *stable*. There are a whole bunch of other considerations in the system vulnerability field too. Are you even vulnerable to the issue? Are you logging enough data to be able to discover a problem even if there has been no public vulnerability issues? Do you read your logs properly? What exploit does the vulnerability allow? Does it matter? What is more important, switching off your production service if a machine is compromised, or letting it run? (i.e., which costs your business more money? The exploit, or the absence of your service?) What is the patch going to change/break? Did you apply it properly? How can you verify that it's working? Does a new version introduce another, worse vulnerability? Basically, in the real world, "fast patching" is not a panacea. -jim
