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:41 Mark Mielke <mark(a)mark.mielke.cc> writes: > 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. > 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. I have not heard anyone arguing for the position that we should never do it. The argument is about whether it's a good idea to do it *right now*, without any advance notice or planning. > Correct me if I am wrong - but I think this issue represents an > exploitable SQL injection security hole. Indeed it is, which is one of the reasons to be cautious with changing it. We've been telling people to move away from \' for a long time, but actually flipping the switch that will make their apps insecure is not something to do on the spur of the moment. 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: Nathan Wagner on 3 Feb 2010 16:22 On Wed, 03 Feb 2010 14:41:13 -0500, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Indeed it is, which is one of the reasons to be cautious with changing > it. We've been telling people to move away from \' for a long time, > but actually flipping the switch that will make their apps insecure > is not something to do on the spur of the moment. AFAICT the switch was added in 8.2, and mentioned in the release notes dated 2006-12-05. The documentation for 8.2 says "The default is currently off, causing PostgreSQL to have its historical behavior of treating backslashes as escape characters. The default will change to on in a future release to improve compatibility with the standard." So people have had three years of warning, which I would hardly characterize as "spur of the moment". If you want the old behavior, change the setting to off. I think that a major release point is exactly the right time to do this, doing it at a minor release number is much less reasonable. A question for those opposed to doing it now: how exactly do you propose to warn people that is different than the notice that it will be changed in a future release that has been around for the last three years? -- nw -- 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: Dimitri Fontaine on 3 Feb 2010 16:35 Tom Lane <tgl(a)sss.pgh.pa.us> writes: > 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. Well, in fact my impression is that the time third-party authors are going to begin to look at things is not alpha1 but beta1. Because until beta comes out you don't know what's in there. Some commits could get reverted before entering beta is what is being said, the goal being to be able to reach code stability in non-infinite time... In my mind the fact that beta is meant to be about 2 to 3 months old is for those problems to get solved before release. In short, I am the blind driver who's not seeing what problem you're talking about. Regards, -- dim -- 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: Dimitri Fontaine on 3 Feb 2010 16:48 Josh Berkus <josh(a)agliodbs.com> writes: >> I still think that changing it now is going to open a can of worms that >> we shouldn't be opening at this stage. We have got more than enough to >> worry about for 9.0 already. I think it is absolute folly to believe >> that this is only going to be a matter of "flip the default and nothing >> else is going to pop up". > > I'll support Tom on this. I'm already worried about the timeline. Vote time? +1 for Tom's idea that plates are already full. At the same time, escape_string_warning = on is the default and I guess everybody find it annoying enough to use the E'foo\tbar' syntax, which will work all the same once standard_conforming_strings is on. By design. And the fact than switching the GUC to off again is so easy makes me wonder about how high the risk is for third party code. It has been said earlier in this thread that one of the risky clients is pg_dump. That's what balances it for me. Do anyone know how much downloads or testing the alphas have seen? -- dim -- 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: marcin mank on 3 Feb 2010 17:39
A certain prominent web framework has a nasty SQL injection bug when PG is configured with SCS. This bug is not present without SCS (details per email for interested PG hackers). I say, hold it off. Greetings Marcin MaÅk -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |