Gavin Sherry <[EMAIL PROTECTED]> writes: > As for making a 7.2.2 release for the sake of form and for those > users who do provide access to untrusted users (universities, ISPs, > say) this would be pointless without the changes to opaque which Tom > has put forward and may/may not work on before 7.3 beta.
I don't think that releasing 7.2.2 without the opaque changes would be pointless. For one thing, the opaque-related security problems are comparatively minor: the cracker must be able to execute arbitrary SQL commands against the database, and by that stage of the game, a DoS attack is already trivial (e.g. disable GEQO and execute a 15 table join query). Also, from skimming the discussion on fixing the opaque problems, there will be at least some degree of backwards incompatibility. That is definitely undesirable for a stable point release -- as is an initdb, as you point out. This amount of pain to fix a minor security hole is *not* worth it, IMHO. So I think that fixing the opaque problems in 7.2.x is simply impossible. Given that, the question is whether we should make a 7.2.2 release with fixes for the other security holes (lpad(), rpad(), reverse(), and the datetime overruns). IMHO, we should. The datetime hole is fairly serious: it's not unreasonable for developers to accept datetime input from the user without limiting it's length. So it's quite likely that there are 7.2 systems in production that have a sane security policy (e.g. hidden behind a firewall, validate user input, etc.) that are still vulnerable. The alternative seems unattractive: if we require that users wait for 7.3 to come out, it may be months before the 7.3.0 release. And even then, upgrading to 7.3 is non-trivial: it requires an initdb and reload, as well as testing to ensure that the user's applications run smoothly on 7.3. Therefore, it may be several months before many production sites upgrade to 7.3; leaving them in the cold for that period isn't something I think we should do, if we can avoid it. That said, there's only a limited amount that I can do. I think we should make a 7.2.2 release, and to that end I've posted patches against REL7_2_STABLE for all four of the security holes. The rest of the work that goes into making a release needs to be done by others (Marc, Vince, Bruce, etc.) -- if there's anything I can do to help, let me know. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---------------------------(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
