Neil Conway wrote: > On Thu, 2003-01-16 at 22:47, Justin Clift wrote: > > Over the last few days we've had patches submitted for 7.2.3 that > > address a couple of things, both the WAL Recovery Bug that Tom has > > developed a patch for, and a couple of buffer overflows that have been > > widely reported. > > The buffer overflows, IMHO, are not sufficient reason to release an > update. As Tom pointed out, there are lots of other, unpatched overflows > in 7.2.3 (and the whole class of vulnerability requires SQL access to > begin with). > > As for the "WAL recovery bug", AFAIK no such bug has been reported "in > the last few days". Exactly what issue are you referring to?
Let's look at the issue here --- I think security fixes are of a different class from corruption bugs or functionality bugs. For the latter, fixing those fixes actual problems in the server that actually improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? I don't see any improvement in the functionality of PostgreSQL in such a case, while feature/corruption fixes _do_ improve the backend code. I think we have to accept the statement that in 7.2.X malicious SQL queries can cause database failure, and fixing one or two of the ten known problems doesn't change that fact. I don't have a problem with releasing 7.2.4 and including all the fixes, including security fixes, but I don't see the security fixes _as_ _a_ _reason_ to release a 7.2.4. So, do we have non-security fixes to warrant a 7.2.X? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
