That's also a solution.
Either way works for me.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 16, 2006 8:54 AM
> To: Andi Gutmans
> Cc: 'Ilia Alshanetsky'; 'Stanislav Malyshev'; 'PHP internals'
> Subject: RE: [PHP-DEV] display_errors =
Hi
>> Hello, I'm Marc and I'm new to this list. Whew! That was easy!
>>
>> I've read in the archive about a patch for supporting openssl pkcs12,
>
> First, thanks for this patch :)
Quite nice you did this, I was just thinking about doing it myself ;)
>
>> but nothing seems to be done so far. Sinc
Here is a couple of notes about both ideas.
On 12/17/06, Pierre <[EMAIL PROTECTED]> wrote:
One does not even need to check it until it is done with the
input decoding process. It will also work nicely with ext/filter, if a
validation failed due to the decoding, the error can be fetched using
thi
Hello,
On 12/16/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
Pursuant an IRC discussion with Rasmus.
It seems to be that in order to do any sort of error differentiation
we need to have a variable-level JIT decoding/filtering. It needs to
be smart though, because we want to issue errors only
Pursuant an IRC discussion with Rasmus.
It seems to be that in order to do any sort of error differentiation
we need to have a variable-level JIT decoding/filtering. It needs to
be smart though, because we want to issue errors only on the first
access to the variable. One way to approach th
On 16-Dec-06, at 4:26 PM, Stanislav Malyshev wrote:
If you know of vulnerability on zend.com, please write to
[EMAIL PROTECTED], that would be only responsible course of
action. However, I do not see how having vulnerabilities imply not
caring for security.
That's my point (and for recor
You seem to be ignoring the argument and clinging to a false assumption
that only people with open phpinfo()s have disable_errors enabled. I
guarantee you that is not the case for the most part.
Well, there's little we can do in that part except for educating users
and changing defaults. The
On 15-Dec-06, at 9:32 PM, Stanislav Malyshev wrote:
It is not just the phpinfo() servers, it is very much a common
case I assure you.
Well, people leaving such things in their servers should deal with
it first, then get to talk about real security :)
You seem to be ignoring the argument
On 12/16/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Fri, 15 Dec 2006, Andi Gutmans wrote:
> Time to turn it off in php.ini-dist in addition to php.ini-recommended?
I would instead change them to php.ini-development and
php.ini-production. In development you'd want to have this stuff on..
On Fri, 15 Dec 2006, Andi Gutmans wrote:
> Time to turn it off in php.ini-dist in addition to php.ini-recommended?
I would instead change them to php.ini-development and
php.ini-production. In development you'd want to have this stuff on..
regards,
Derick
--
Derick Rethans
http://derickretha
(Wietse Venema) wrote:
! zend_uchar is_ref:7;
! zend_uchar taint_flag:1;
Beginning of this year I was actually making tests with something like
that but I used
zend_uchar is_ref:1;
zend_uchar flags:7;
to be able to support multiple taint types (HTML and DB where the
On Sat, 2006-12-16 at 13:03 +, Lester Caine wrote:
> Lukas Kahwe Smith wrote:
>
> > To me some of Ilia's arguements do not make sense. Ext/filter has the
> > same danger of creating a false sense of security. The arguements that
> > did make sense to me are about the issue of (un)tainting be
pecl
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith wrote:
To me some of Ilia's arguements do not make sense. Ext/filter has the
same danger of creating a false sense of security. The arguements that
did make sense to me are about the issue of (un)tainting being directly
tied to the context in which the variable is being used.
Hi,
To me some of Ilia's arguements do not make sense. Ext/filter has the
same danger of creating a false sense of security. The arguements that
did make sense to me are about the issue of (un)tainting being directly
tied to the context in which the variable is being used.
This is a problem
Ilia Alshanetsky wrote:
In theory, you need to consider that many ISPs and users will interpret
taint mode == secure and enable it causing much grief to distributable
application writers who need to accommodate every environment.
actually i dont think this is a valid argument. people will qu
Lester Caine wrote:
I'm sure many people have their own preferred tools for creating files
- all I was trying to say was that - is taint support actually needed
at run time? Something that improves the visibility of mistakes while
editing files seems to be more worthwhile - something that can a
Andi Gutmans wrote:
I don't quite understand the relevance of PHPEclipse to the issue.
And I'm not sure how you judge "clogging up" PHP without seeing a patch
especially as I'm not sure how much PHP internals hacking you've done.
I'm sure many people have their own preferred tools for creating
On Sat, 2006-12-16 at 07:31 +, Lester Caine wrote:
> Wietse Venema wrote:
> > Ilia Alshanetsky:
> >> And here is your first exploit, let's say we say
> >> mysql_real_escape_string() takes tainted data and makes it untainted,
> >> what happens when this "safe" data is passed to exec().
> >
19 matches
Mail list logo
