Hi,
On Apr 30, 2011, at 17:13, Anthony Ferrara ircmax...@gmail.com wrote:
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
Besides the question about query cache and security there is a bit more to keep
in mind:
Using native prepared statements
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
But I figured it would be good to start a discussion on it here. To
me, I consider this a pretty significant issue since it's not possible
to do true prepared statements while using PDO. All the code to
On 04/30/2011 08:13 AM, Anthony Ferrara wrote:
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
But I figured it would be good to start a discussion on it here. To
me, I consider this a pretty significant issue since it's not possible
to do true
Well, the benefit to doing it natively would be to prevent SQL
Injection (which is possible now even with PDO's prepared statements).
As it stands now, it's quite possible to inject when using prepared
statements (easy = 5.3.5, and possible = 5.3.6, depending on
config). So basically the choice
On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/30/2011 08:13 AM, Anthony Ferrara wrote:
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
But I figured it would be good to start a discussion on it here. To
me, I
Am 30.04.2011 17:45, schrieb Ferenc Kovacs:
On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Do you realize why we did this in the first place? The common versions of
MySQL in use out there are not very clever when it comes to the native
prepared statement handling.
On Sat, Apr 30, 2011 at 6:02 PM, Reindl Harald h.rei...@thelounge.netwrote:
Am 30.04.2011 17:45, schrieb Ferenc Kovacs:
On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
Do you realize why we did this in the first place? The common versions
of
MySQL in use out
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement handling. First, there is no prepared
statement cache, so there is no benefit to doing them natively, but
Since 5.1.17 there
On 04/30/2011 10:36 AM, Stas Malyshev wrote:
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement handling. First, there is no prepared
statement cache, so there is no benefit to
On Sat, Apr 30, 2011 at 7:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/30/2011 10:36 AM, Stas Malyshev wrote:
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement
Really would depend on the user. Part of my company still runs on SQLServer
2003, for instance...
Corporate infrastructure rarely sees upgrades. Your cousin with the wordpress
fetish, on the other hand...
On Apr 30, 2011, at 1:10 PM, Ferenc Kovacs wrote:
On Sat, Apr 30, 2011 at 7:53 PM,
Am 30.04.2011 20:10, schrieb Ferenc Kovacs:
People upgrade their databases even slower than they upgrade their PHP.
with 5.0 EOL-ed for some time, and even the debian stable is running 5.1, I
wonder how many of our user runs 5.0.
and why should anybody wait for lazy people?
5.5 did not hurt
On 04/30/2011 11:10 AM, Ferenc Kovacs wrote:
with 5.0 EOL-ed for some time, and even the debian stable is running
5.1, I wonder how many of our user runs 5.0.
I'm not disagreeing, I just don't agree it is a bug against 5.3. There
were good reasons for the default at the time 5.3 was
On Sat, Apr 30, 2011 at 8:16 PM, Matt Wilson sha...@gmail.com wrote:
Really would depend on the user. Part of my company still runs on SQLServer
2003, for instance...
Corporate infrastructure rarely sees upgrades. Your cousin with the
wordpress fetish, on the other hand...
what is
Sorry, you're right. It's 2000 service pack 3 :)
On Apr 30, 2011, at 1:44 PM, Ferenc Kovacs wrote:
On Sat, Apr 30, 2011 at 8:16 PM, Matt Wilson sha...@gmail.com wrote:
Really would depend on the user. Part of my company still runs on SQLServer
2003, for instance...
Corporate
Actually, I'm talking out my ass. I know it's some version prior to 2005 and
I'm only guessing I meant SP3. I don't work on it, i've just heard the number 3
thrown around with it. I'll remove myself from the conversation before I make a
larger fool of myself :)
On Apr 30, 2011, at 1:44 PM,
I'm not arguing if there weren't reasons for implementing it this way.
I am arguing if they are good enough reasons to justify the security
impact. It's not my decision (and I respect that), but I would stress
that what PDO is doing is not prepared statements or even
parameterized queries, and
On 04/30/2011 11:59 AM, Anthony Ferrara wrote:
I'm not arguing if there weren't reasons for implementing it this way.
I am arguing if they are good enough reasons to justify the security
impact. It's not my decision (and I respect that), but I would stress
that what PDO is doing is not
Native prepared statements will completely protect you from injection
via any of the bound parameters. The wire-level passage of the data
is completely different (and the data is sent by length, rather than
by deliminator). As an exercise, view the traffic that's sent to the
server via
On 04/30/2011 12:05 PM, Anthony Ferrara wrote:
Native prepared statements will completely protect you from injection
via any of the bound parameters. The wire-level passage of the data
is completely different (and the data is sent by length, rather than
by deliminator). As an exercise, view
Correct. But prior to 5.3.6 it was not possible to have PDO and MySQL
agree on the character set (at least without having root access to the
server). And after 5.3.6, the DSN *must* include the charset
parameter to make them agree. The common technique of setting the
charset via SET NAMES
On Sat, Apr 30, 2011 at 9:01 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/30/2011 11:59 AM, Anthony Ferrara wrote:
I'm not arguing if there weren't reasons for implementing it this way.
I am arguing if they are good enough reasons to justify the security
impact. It's not my decision
Excerpts from Rasmus Lerdorf's message of Sat Apr 30 10:53:30 -0700 2011:
On 04/30/2011 10:36 AM, Stas Malyshev wrote:
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement
On Sat, Apr 30, 2011 at 10:05 PM, Clint Byrum cl...@ubuntu.com wrote:
Excerpts from Rasmus Lerdorf's message of Sat Apr 30 10:53:30 -0700 2011:
On 04/30/2011 10:36 AM, Stas Malyshev wrote:
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use
hi,
It is also important to keep in mind that there are a growing
alternative to Oracle's mysql, so focusing only on Oracle plans is not
necessary a good thing to do.
That being said, it seems that we have an agreement to change this
behavior in trunk. It is a documentation matter then. There is
25 matches
Mail list logo
