On 12/06/2012 15:11, Christopher Schultz wrote: > Paul, > > On 6/12/12 9:03 AM, Paul Singleton wrote: >> On 12/06/2012 06:57, Caldarale, Charles R wrote: >>>> From: N.s.Karthik [mailto:nskarthi...@gmail.com] Subject: >>>> HttpOnly >>> >>>> Tomcat 6.0.10 >>> >>>> For some specific Reason We use Tomcat 6.0.10 for Dev/Deploy >>>> in INTRANET. >>> >>> Sorry, but there is simply no excuse for using a version of >>> Tomcat that's over five years old. > >> There may be a sound business rationale for using old versions of >> software.
Maybe, but only if that version hasn't been updated - and even then the risk associated with that software increases over time, not decreases. >> Tomcat 5.5.9, for example, works as well now as it did when it was >> judged ready to be a stable release. What a pointless statement. Software doesn't degrade over time. The issue is not whether it works 'as well as it did' (it can't work any other way) it's whether it works as well as it was _supposed to_. >> If there are no bugs or missing features in it which affect the >> security or functionality of an application, then there is no >> benefit from upgrading What a bizarre statement, given the context you set is a release that happened in March 2005. 7 years ago. > You are absolutely right. Feel free to read the find documentation on > the Tomcat site about all the security vulnerabilities that have been > fixed since 6.0.10 (and 5.5.9 for that matter). +1 >> but there will be costs and risks: > >> * downtime and manpower for the upgrade Should I infer that a typical upgrade will take a long time & a lot of people? Or are you saying that this is a small risk, 1 person and a few seconds? (A seven year window is probably enough to squeeze a couple of updates in.) >> * recommissioning/retesting: unless *all* acceptance tests are >> automated, this can be far more expensive than deploying the >> upgrade Yes, I sort of agree. Deploying the upgrade should be completely inexpensive; by comparison, the testing process should be more expensive, yes. > You are right about this, too. But there are certainly risks to not > upgrading as well. I'll leave those as an exercise for the reader. > >> * risk of introducing new bugs in new code That is a comparison between: a) measurable risk of impact on your application from known bugs b) *perceived* risk of impact on your application from unknown/unidentified bugs You cannot measure b), you can only address a). > Unless your webapp needs modifications to run under a new version of > Tomcat (which should never be the case when staying on a major-version > number line), you shouldn't be introducing any new bugs into any code. > Unless you mean bugs in Tomcat, which are always a possibility. > > So I guess you're saying that it's better to stick with the devil you > know? If that's what he's saying, then the argument is in favour of upgrading to address the bugs you *do* know about, surely? >> In general, older software is better understood and less risky >> than new software, and if it meets requirements, is preferable. Older software is only less risky if it's been debugged & patched. Which means updating it regularly. Would you say that the businesses of the world circa late 1999 felt that their venerable Cobol apps presented less risk that newly written ones? Or that they presented more risk, because it wasn't clear what would happen to them when the clock flipped over to 2000? Or that they presented more risk because it was harder to find people with the right skill set to debug said applications? p > In general, yes. I this case, no, for at least 2 reasons: > > 1. Many security, stability, and performance updates between 6.0.10 > and 6.0.35. > 2. Volunteer support on this forum doesn't care to support truly > ancient versions of software that is freely available. > > If the OP wants to go purchase a support contract for Tomcat 6.0.10, > he or she can certainly do that. -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
