Gareth Ardron wrote:
Rasmus Lerdorf wrote:
TCP/IP Firewalls break all sorts of applications as well until either
the application is modified to poke a hole in the firewall itself via
upnp, or you reconfigure the firewall. This makes firewalls
annoying, but they are necessary. This is exactly t
Rasmus Lerdorf wrote:
TCP/IP Firewalls break all sorts of applications as well until either
the application is modified to poke a hole in the firewall itself via
upnp, or you reconfigure the firewall. This makes firewalls annoying,
but they are necessary. This is exactly the same thing. It is
Andi Gutmans wrote:
At 01:37 AM 2/3/2005 +, Gareth Ardron wrote:
True, but you've still got a lot of boxes that are used both for dev
and production work. Take a small web design company, for example.
Now in such a position, the admin may want to access raw variables in
dev.site.com but have
At 01:37 AM 2/3/2005 +, Gareth Ardron wrote:
True, but you've still got a lot of boxes that are used both for dev and
production work. Take a small web design company, for example. Now in such
a position, the admin may want to access raw variables in dev.site.com but
have things restricted i
Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
Looking at my code here, it would actually be trivial to expose the
raw data as superglobals, but what do we achieve then? We are
simply renaming $_GET to $_GET_RAW or something like that? If you
don't want any filtering to be done by default, simp
At 01:44 PM 2/2/2005 -0800, Rasmus Lerdorf wrote:
You guys can write your own implementation and put it in PECL alongside
the one I am putting in there and we can decide if any of them should be
bundled by default. Perhaps none of them should, but like it or not,
people want to filter at this l
At 12:53 PM 2/2/2005 -0800, Rasmus Lerdorf wrote:
Pick 10 random PHP apps out there and go through them. With very very few
exceptions 10 out of 10 will be insecure. And the blame here is not just
on the developers of those applications, we are partially to blame for not
providing enough tools
Hello Andi,
>>However i'd like to see the 'ifsetor' or '?:' operator since it makes
>>many things much faster and easier to read.
AG> I am not sure if the security filter functions aren't enough because they
AG> will be used to gather and verify input which is the main purpose of
ifsetor.
AG> Al
At 10:26 PM 2/2/2005 +0100, Marcus Boerger wrote:
Hello Andi,
Tuesday, February 1, 2005, 8:26:15 PM, you wrote:
> Hey,
> I just heard from Wez that PDO is in very advanced stages now (ready
for beta).
> I would like to start the PHP 5.1 release process. Due to the lack of
> testing both the new en
http://www.binam.net/bug-27633.patch
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005 2:03 PM
To: Binam, Jesse
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PATCH] Bug# 27633 - Wrong translation in ASCII
mode
On Wed, 2 Feb 2005, B
Rasmus Lerdorf wrote:
Derick Rethans wrote:
Well, people turn on safe mode just because the name implies that things
are safe too - which is wrong. I agree with Ilia, we should not mangle
request data by default. It's fine to provide filter functions but the
normal post/get/cookie data should be no
I've ran across some strangeness which I can't figure out. When I run
the following code I get a Seg Fault / Bus Error in my apache log
(SegFault on Linux and Bus Error on Mac OS X).
$rate_id = Core_Request::get('rate_id','integer',true);
$plan_id = Core_Request::
Marcus Boerger wrote:
Well, people turn on safe mode just because the name implies that things
are safe too - which is wrong. I agree with Ilia, we should not mangle
request data by default. It's fine to provide filter functions but the
normal post/get/cookie data should be normally available throu
Hello Rasmus,
Wednesday, February 2, 2005, 11:07:55 PM, you wrote:
> Marcus Boerger wrote:
>>>Well, people turn on safe mode just because the name implies that things
>>>are safe too - which is wrong. I agree with Ilia, we should not mangle
>>>request data by default. It's fine to provide filter
I think http://www.php.net/~wez/extending-php.pdf might help you.
On Wed, 2 Feb 2005 00:19:55 +0800, taft <[EMAIL PROTECTED]> wrote:
> How can I write a module for PHP? Any ABC information?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/u
On Wed, 2 Feb 2005, Rasmus Lerdorf wrote:
> Derick Rethans wrote:
> > Well, people turn on safe mode just because the name implies that things
> > are safe too - which is wrong. I agree with Ilia, we should not mangle
> > request data by default. It's fine to provide filter functions but the
> > n
Derick Rethans wrote:
Well, people turn on safe mode just because the name implies that things
are safe too - which is wrong. I agree with Ilia, we should not mangle
request data by default. It's fine to provide filter functions but the
normal post/get/cookie data should be normally available throu
Hello Derick,
Wednesday, February 2, 2005, 10:30:39 PM, you wrote:
> On Wed, 2 Feb 2005, Rasmus Lerdorf wrote:
>> Ilia Alshanetsky wrote:
>> >> Looking at my code here, it would actually be trivial to expose the
>> >> raw data as superglobals, but what do we achieve then? We are simply
>> >> re
Jeff Moore wrote:
On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes,
braces, etc.
I hate to see more ini options. They make it more difficult to write
programs t
On Wed, 2 Feb 2005, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
> >> Looking at my code here, it would actually be trivial to expose the
> >> raw data as superglobals, but what do we achieve then? We are simply
> >> renaming $_GET to $_GET_RAW or something like that? If you don't want
> >> a
Hello Andi,
Tuesday, February 1, 2005, 8:26:15 PM, you wrote:
> Hey,
> I just heard from Wez that PDO is in very advanced stages now (ready for
> beta).
> I would like to start the PHP 5.1 release process. Due to the lack of
> testing both the new engine VM and PDO have received I would like t
On Wed, 2 Feb 2005, Binam, Jesse wrote:
> Can somebody please review and either commit and/or give me some
> feedback. It is against HEAD as of about 30 minutes ago.
Please post the patch online and provide a link, the list manager strips
non-text attachments.
Derick
--
Derick Rethans
http://d
Hello Ilia,
Wednesday, February 2, 2005, 7:04:24 PM, you wrote:
IA> The end result is that we are punishing people who have already written
IA> good code and continue to encourage people to write bad code by saying
IA> "we'll take care of data filtering", which is sorta like safe_mode.
On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes,
braces, etc.
I hate to see more ini options. They make it more difficult to write
programs that work under a va
WTF?? Appearently the attachment is getting stripped off
somewhere along the way...
Index:
ext/ftp/ftp.c===RCS
file: /repository/php-src/ext/ftp/ftp.c,vretrieving revision 1.106diff
-u -r1.106 ftp.c--- ext/ftp/ftp.c 5 Oct 2004
I guess the patch would be helpful
;)
From: Binam, Jesse
[mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005
12:34 PMTo: internals@lists.php.netSubject: [PHP-DEV]
[PATCH] Bug# 27633 - Wrong translation in ASCII mode
Can somebody please
review and either commit and/or give me som
Can somebody please
review and either commit and/or give me some feedback. It is against HEAD as of
about 30 minutes ago.
This is a data
integrity issue so I would think it would be extremely high
priority.
This is
a problem in both 4.3.10 and 5.0.3, this patch should apply nicely to both
I know that my opinion probably means diddly but my %2 is free. ;)
If I am understanding all of this right, if the raw varible contains
some shell code like "\x90\x90\x90\xab\xa3\x54\x77" and I do something
like $var = filter(GET,'foo',FILTER_NUMBER); $var would contain
something like " 90 90 90 3
I see no point in introducing this feature which is aimed at solving the
XSS and other related security issues once and for all across all PHP
applications while at the same time providing a completely insecure side
door. Dealing with security issues is a pain in the ass. This pain
doesn't go
Ilia Alshanetsky wrote:
Looking at my code here, it would actually be trivial to expose the
raw data as superglobals, but what do we achieve then? We are simply
renaming $_GET to $_GET_RAW or something like that? If you don't want
any filtering to be done by default, simply don't turn it on.
Ilia Alshanetsky wrote:
> Jay,
>
> I've noticed that you're still using the ini parser in this new code,
> would it not be easier and allow for greater code re-use to use the CSV
> database and the underlying fgetcsv code?
>
> Ilia
>
Hi Ilia, long time no irc...
It probably would be a lot eas
Hello PHP developers,
I have a just written a PHP-Extension as described in the
documentation. I am using PHP 4.3.10. Configure (--with-libadwin),
compiling and linking work fine, this is what ldd shows (libadwin.so.4
is the function used by my extension):
thomasb:~/php-4.3.10 1$ ldd ./sapi/cgi/
Looking at my code here, it would actually be trivial to expose the raw
data as superglobals, but what do we achieve then? We are simply
renaming $_GET to $_GET_RAW or something like that? If you don't want
any filtering to be done by default, simply don't turn it on.
In many cases it may not
Yeah I agree. I think additional superglobals are superfluous.
Not turned on $_GET behaves the same. Turned on then $_GET would be
filtered and you'd use a function call to get to the raw data. I don't see
this as a problem and am not concerned about performance.
Andi
At 08:25 PM 2/1/2005 -0800,
On Tue, 1 Feb 2005, Sean Coates wrote:
> Rasmus Lerdorf wrote:
> > As someone suggested, if
> > the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or
> > something to that effect then an individual script could in one shot
> > filter all GET data even if the default ini filter wasn't in
On Wed, 2 Feb 2005, Christian Schneider wrote:
> Rasmus Lerdorf wrote:
> > I don't actually see it as a per-script thing. Obviously the ini would
> > be per-dir Apache configurable, but I see this as being something set
> > across the board on a dedicated server that defines the security policy
>
On Tue, 1 Feb 2005, Rasmus Lerdorf wrote:
> Shane Caraveo wrote:
> > I thought my suggestion the other week was pretty goodsafe_filter :-)
>
> Hey, no snarky comments from the peanut gallery please! ;) No PHP
> function or feature will ever be called safe* again.
I totally agree with that.
37 matches
Mail list logo
