PG 9.0 and standard_conforming_strings
in [PgSql]
|
Prev: [HACKERS] PG 9.0 and standard_conforming_strings
Next: Package namespace and Safe init cleanup for plperl [PATCH]
From: Tom Lane on 3 Feb 2010 14:20 "Greg Sabino Mullane" <greg(a)turnstep.com> writes: > Which fallout are we still dealing with? Are you saying that the > developers are not up to the challenge of handling this before 9.0 > is released? (If this were anything more than a simple boolean GUC > fix, I would be in your corner). I'm not certain that Robert is saying that, but *I* am. We have enough to do for 9.0; adding another work item of uncertain magnitude is not the thing to be doing right now. The notion that it's "a simple boolean GUC fix" and won't cause any followup work is unjustifiably optimistic. And that's just for the core code. I don't want to blindside driver writers and other third-party authors with a change like this made at the end of the cycle. If we do it at the beginning of the 9.1 devel cycle, no one will have room to argue that they didn't have adequate notice ... but they sure will be able to make that complaint if we do it now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mark Mielke on 3 Feb 2010 14:25 On 02/03/2010 01:20 PM, Robert Haas wrote: > I am not sure I really understand why anyone is a rush to make this > change. What harm is being done by the status quo? What benefit do > we get out of changing the default? The major argument that has been > offered so far is that "if we don't change it now, we never will", but > I don't believe that the tenor of this discussion supports the > contention that Tom or anyone else never wants to make this change. > For myself, it isn't so much a rush as a sense that the code out there that will break, will never change unless forced, and any time seems better than never. Correct me if I am wrong - but I think this issue represents an exploitable SQL injection security hole. I switched because I convinced myself that the ambiguity of \' represented actual danger. I'm concerned that if the web front end doing parameter checking and passing in code using either '' quoting or \' quoting can be exploited if the server happens to be configured the opposite way. To me, this ambiguity can only be addressed by everybody agreeing on the right way to do it, and '' quoting seems like the right way to do it to me. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mark Mielke on 3 Feb 2010 14:30 On 02/03/2010 02:15 PM, Robert Haas wrote: > The longer we wait before making an > incompatible change, the more people will have adjusted their code to > the new reality (or upgraded their drivers, etc.) and the fewer things > will break. > In my experience, the opposite is true, although in this case, the damage may already be done. That is, the longer bad habits are allowed to form, the harder they are to break, and the more code is written that may be broken. People won't "upgrade" unless forced. At some point, the switch does have to be tripped. Is now the time? I have no comment. I just don't want to see "never" be the time, and if "never" is not the time, than "now" does not seem impratical. That said, if you say we'll tell people to prepare for a change in 9.0, and enforce the change in a later release, that is fine too. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 3 Feb 2010 14:33 Rod Taylor escribi�: > As much as I would like GUCs to disappear I think this one should > proceed cautiously and probably be a 9.1 or even 9.2 item. Note that this is *not* about removing the configuration setting, only about flipping its default value. There has been *no* talk of removing the setting. If you have old clients around, simply change the value from the default to off. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 3 Feb 2010 14:34
On Wed, Feb 3, 2010 at 2:25 PM, Mark Mielke <mark(a)mark.mielke.cc> wrote: > On 02/03/2010 01:20 PM, Robert Haas wrote: >> I am not sure I really understand why anyone is a rush to make this >> change. What harm is being done by the status quo? What benefit do >> we get out of changing the default? The major argument that has been >> offered so far is that "if we don't change it now, we never will", but >> I don't believe that the tenor of this discussion supports the >> contention that Tom or anyone else never wants to make this change. > > For myself, it isn't so much a rush as a sense that the code out there that > will break, will never change unless forced, and any time seems better than > never. > > Correct me if I am wrong - but I think this issue represents an exploitable > SQL injection security hole. I switched because I convinced myself that the > ambiguity of \' represented actual danger. I'm concerned that if the web > front end doing parameter checking and passing in code using either '' > quoting or \' quoting can be exploited if the server happens to be > configured the opposite way. To me, this ambiguity can only be addressed by > everybody agreeing on the right way to do it, and '' quoting seems like the > right way to do it to me. OK, you're wrong. :-) Yeah, there's a problem if the client and server are configured in opposite ways, but flipping the default setting of standard_conforming_strings is not going to make that problem go away. If anything it's going to make it worse. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |