Pierre wrote:
Hi Thomas, Wez,
On 1/13/07, Wez Furlong <[EMAIL PROTECTED]> wrote:
Hi Thomas,
I think Marcus gave you all the right pointers.
I just wanted to let you know that I have a pending patch for DH kex
and some bignum functions, and that Pierre mentioned that he's been
working on a few
Hi Thomas, Wez,
On 1/13/07, Wez Furlong <[EMAIL PROTECTED]> wrote:
Hi Thomas,
I think Marcus gave you all the right pointers.
I just wanted to let you know that I have a pending patch for DH kex
and some bignum functions, and that Pierre mentioned that he's been
working on a few other bits rece
Hi Thomas,
I think Marcus gave you all the right pointers.
I just wanted to let you know that I have a pending patch for DH kex
and some bignum functions, and that Pierre mentioned that he's been
working on a few other bits recently.
If you think that we'll be overlapping, we can try harder to ei
On 1/12/07, Brian Moon <[EMAIL PROTECTED]> wrote:
The PHP manual nor
the MySQL manual mentions sql injection when talking about prepared
statements.
I don't think you've read the section on prepared statements in the
PDO documentation, because it does mention it there, although it
doesn't beat
There will be a short downtime of the cvs server this afternoon. I need
to move it to another data center. The IP address will be changing as
well. I lowered the TTL of the dns zone file yesterday, so it should be
pretty quick to catch up once the machine is hooked back up. I expect
about 20-30
I don't believe you'd lose REMOTE_ADDR in FCGI setup, at least I have
never seen it be lost. It is fairly important for many applications
and I'd imagine we would've heard it is missing. The ones missing
often are DOCUMENT_ROOT, PHP_SELF not being quite the same, PATH_INFO
missing or differ
The $_SERVER vars maybe not quite the same as well when comparing
mod_php and fcgi.
I think the vital ones should be the same, though you indeed might lose
some ones like REMOTE_PORT or REMOTE_ADDR - though I checked in my FCGI
setup they seem to be ok.
--
Stanislav Malyshev, Zend Products E
On 12-Jan-07, at 4:12 PM, Stanislav Malyshev wrote:
That said, if my Production environment is mod_php, I want my dev
environment to be mod_php, because I'd rather not find out the hard
way that it makes some subtle but important difference when I get to
QA/staging.
Well, if you develop on Wi
The big one is the HTTP Authentication (?) because, errr, it would
have to pass the password in cleartext through a process that would be
visible to `ps auxwww` ??? So while it's not technically impossible,
FCGI operates by use of pipes, so any data sent back and forth are not
accessible unles
On 1/12/07, Michael B Allen <[EMAIL PROTECTED]> wrote:
On Fri, 12 Jan 2007 11:40:32 -0500
Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
> >
> > Limits, table names, and several other query parts are protected by
> > MediaWiki's query builder.
On Fri, 12 Jan 2007 11:40:32 -0500
Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
> >
> > Limits, table names, and several other query parts are protected by
> > MediaWiki's query builder. A complex select query might look like this:
> >
> > $r
> And using prepare statement to pass variable by binding variable
> is simple good programming (and must be used with many other good
> practice...input check...)
> And effectively is the variable binding and not the prepare
> statement that add real security again sql injection...
> but actualy
Robert Cummings wrote:
> Wow, that's hideous!
Only because I chose a complex example, to demonstrate its capabilities.
It's a great deal easier than the equivalent string wrangling. SQL is
meant to be human readable. It's not particularly well-suited to
construction from PHP data types, or to pars
On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
>
> Limits, table names, and several other query parts are protected by
> MediaWiki's query builder. A complex select query might look like this:
>
> $result = $db->select(
> # Tables
> array( 'user', 'revision' ),
> # Fields
>
Brian Moon wrote:
> Mathieu CARBONNEAUX wrote:
>> but i think some good security idea have been said, for exemple using
>> "prepare statement" to avoid sql injection...
>
> We really need to stop spreading this myth that prepared statements are
> a security measure. Prepared statements only allow
Hello Andi,
On 1/11/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Do we need to provide better tools for our developers? Definitely! This is why
we are working on ext/filter (I agree the first pass
wasn't very successful), a filter extension in Zend Framework, and other best
practices.
What d
_
From: Vlad Bosinceanu [mailto:[EMAIL PROTECTED]
What might help is pushing (via the manual) for the adoption of tools
that prevent common problems, with pdo's prepared statements being one
such tool.ok, documenting is what i say...
but not all use php5 pdo... not all use php5... many
_
From: Brian Moon [mailto:[EMAIL PROTECTED]
We really need to stop spreading this myth that prepared statements are
a security measure. Prepared statements only allow passing of the value
parts of where clauses and a couple of other parts of the query. Limit
values would be the most c
On 1/11/07, Pierre <[EMAIL PROTECTED]> wrote:
Hi Stefan,
On 1/11/07, Stefan Esser <[EMAIL PROTECTED]> wrote:
>
> > For your information, zip is not enabled by default. If you have a
> > bug/issue about the specific zip:// URL, please let me know. Ilia and
> > Tony already fixed some paths fixes
19 matches
Mail list logo
