Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » allow_url_include and php:/data: »

allow_url_include and php:/data:

php.internals

Stanislav Malyshev

19 years ago
Stefan Esser writes here: http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html that allow_url_include (and allow_url_fopen) can be easily worked around - i.e. extrenally-supplied code executed on server - by using php: and data: URLs. I think if we want allow_url_include have any value than we should fix it... What do you think?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Rasmus Lerdorf

19 years ago
Stanislav Malyshev wrote:
> Stefan Esser writes here: > http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html > > that allow_url_include (and allow_url_fopen) can be easily worked around > - i.e. extrenally-supplied code executed on server - by using php: and > data: URLs. I think if we want allow_url_include have any value than we > should fix it... What do you think?
Yeah, we probably should. Had a chat with Wez about it too. Here is the patch. I think this catches the cases we are interested in: http://lerdorf.com/php/is_url.diff If someone could doublecheck it against those attacks it would be helpful. -Rasmus

Peter Brodersen

19 years ago
On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
>Yeah, we probably should. Had a chat with Wez about it too. Here is >the patch. I think this catches the cases we are interested in: > > http://lerdorf.com/php/is_url.diff > >If someone could doublecheck it against those attacks it would be helpful.
Would requests to a smbserver, e.g. \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It seems like smbserver requests are regarded as part of the default filesystem wrapper.
-- - Peter Brodersen

Stanislav Malyshev

19 years ago
> Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper.
Good point. Generally I'd say it belongs to the OS, but I'm not sure if you can restrict this from OS side?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Ilia A.

19 years ago
I think it'd be wrong to consider networked file system as non-local. Mostly because many times there are no ways to identify them reliable and the fact this is a perfectly valid usage that if disallowed by default would break a large number of applications. On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote:
> On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > >> Yeah, we probably should. Had a chat with Wez about it too. Here is >> the patch. I think this catches the cases we are interested in: >> >> http://lerdorf.com/php/is_url.diff >> >> If someone could doublecheck it against those attacks it would be >> helpful. > > > Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper. > > -- > - Peter Brodersen > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Ilia Alshanetsky

Wez Furlong

19 years ago
I think it's a fair assumption that a random host specified in that way be treated as suspicious and lumped in under the disable-includes-by-default category. If someone discovers that it breaks their app, when they read the docs for allow_url_include it should be made very clear what the implications are and what should be done prior to turning it on. So i have no problem with disallowing includes for paths beginning with a double backslash on windows, when allow_url_include is disabled. --Wez. On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote:

Ilia A.

19 years ago
On 5-Nov-06, at 11:13 AM, Wez Furlong wrote:
> I think it's a fair assumption that a random host specified in that > way be treated as suspicious and lumped in under the > disable-includes-by-default category.
What's random? Non localhost/127.0.0.1 ?
> If someone discovers that it breaks their app, when they read the docs > for allow_url_include it should be made very clear what the > implications are and what should be done prior to turning it on. > > So i have no problem with disallowing includes for paths beginning > with a double backslash on windows, when allow_url_include is > disabled. > > --Wez. > > > On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote: >> I think it'd be wrong to consider networked file system as non-local. >> Mostly because many times there are no ways to identify them reliable >> and the fact this is a perfectly valid usage that if disallowed by >> default would break a large number of applications. >> >> >> On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote: >> >> > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals >> > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >> > >> >> Yeah, we probably should. Had a chat with Wez about it too. >> Here is >> >> the patch. I think this catches the cases we are interested in: >> >> >> >> http://lerdorf.com/php/is_url.diff >> >> >> >> If someone could doublecheck it against those attacks it would be >> >> helpful. >> > >> > >> > Would requests to a smbserver, e.g. >> > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It >> > seems like smbserver requests are regarded as part of the default >> > filesystem wrapper. >> > >> > -- >> > - Peter Brodersen >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> >> Ilia Alshanetsky >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >
Ilia Alshanetsky

Peter Brodersen

19 years ago
Hi, On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org (Ilia Alshanetsky) wrote:
>> I think it's a fair assumption that a random host specified in that >> way be treated as suspicious and lumped in under the >> disable-includes-by-default category. > >What's random? Non localhost/127.0.0.1 ?
Actually any smb server that is requested thorugh PHP's means of fetching a resource (\\smbserver\...) instead of a device mount in the operating system (e.g. Z:\ ...).
-- - Peter Brodersen

Ilia A.

19 years ago
What's to say /drive/smb or letter:// is not an SMB device? Also why break perfectly valid applications that perform operations on networked file systems? On 5-Nov-06, at 11:41 AM, Peter Brodersen wrote:
> Hi, > > On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org > (Ilia Alshanetsky) wrote: > >>> I think it's a fair assumption that a random host specified in that >>> way be treated as suspicious and lumped in under the >>> disable-includes-by-default category. >> >> What's random? Non localhost/127.0.0.1 ? > > Actually any smb server that is requested thorugh PHP's means of > fetching a resource (\\smbserver\...) instead of a device mount in the > operating system (e.g. Z:\ ...). > > -- > - Peter Brodersen >
Ilia Alshanetsky

Rasmus Lerdorf

19 years ago
Ilia Alshanetsky wrote:
> What's to say /drive/smb or letter:// is not an SMB device? Also why > break perfectly valid applications that perform operations on networked > file systems?
We are only talking about marking them as is_url which doesn't have anything to do with performing normal operations on networked filesystems. How many real apps rely on being able to execute code via an smb include? The exact same argument could me made for a localhost http or ftp include which we also disallow. The fact that someone can map a remote machine to a local drive actually means that they can make sure their app works because then they have pre-configured which hosts are valid hosts for this use. If a bad guy can mount remote filesystems onto your server, then you have bigger problems. -Rasmus

Ilia A.

19 years ago
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote: >> What's to say /drive/smb or letter:// is not an SMB device? Also why >> break perfectly valid applications that perform operations on >> networked >> file systems? > > We are only talking about marking them as is_url which doesn't have > anything to do with performing normal operations on networked > filesystems. How many real apps rely on being able to execute code > via > an smb include?
Quite a few since many "real apps" will happily install on an SMB share in a linux or windows environment. While this is an uncommon practice on linux I've seen this done many times in the Windows environment. In linux I have seen this date frequently for backup purposes (managed by PHP app) where php would create a backup and write it to the storage machine via SMB. Quite a few big hosters now offer access to SAN via SMB for backup purposes.
> The exact same argument could me made for a localhost > http or ftp include which we also disallow. The fact that someone can > map a remote machine to a local drive actually means that they can > make > sure their app works because then they have pre-configured which hosts > are valid hosts for this use.
Not all users can mount the smb system due to permission restrictions or simple lack of knowhow on how to do that. While latter can be solved, solving the former is quite a bit trickier. Ilia Alshanetsky

Ilia A.

19 years ago
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
> The exact same argument could me made for a localhost > http or ftp include which we also disallow.
For http allowing localhost access is dangerous simply because the person could make the script request itself making a very nasty request loop that will instantly result in a denial of service that requires nothing short of a web server restart to resolve. Ilia Alshanetsky

Richard Lynch

19 years ago
On Sun, November 5, 2006 11:13 am, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote: >> What's to say /drive/smb or letter:// is not an SMB device? Also why >> break perfectly valid applications that perform operations on >> networked >> file systems? > > We are only talking about marking them as is_url which doesn't have > anything to do with performing normal operations on networked > filesystems. How many real apps rely on being able to execute code > via > an smb include? The exact same argument could me made for a localhost > http or ftp include which we also disallow. The fact that someone can > map a remote machine to a local drive actually means that they can > make > sure their app works because then they have pre-configured which hosts > are valid hosts for this use. If a bad guy can mount remote > filesystems > onto your server, then you have bigger problems.
Maybe I'm just being stupid (again) but it seems like all of this is kinda pointless... I mean, if you're dumb enough to include() source code from some random computer you don't control/trust, what do you really expect as the outcome? I realize that a lot of idiots did: include $path; with register_globals on as part of their code, and allow_url_include is trying to stem the tide of disasters that caused... But, really, can somebody be both smart enough to get SMB to even work, then manage to mount somebody else's untrusted drive or be dumb enough to let somebody else mount their own SMB drive, and then include() it i their PHP code? How likely is this scenario? And how many Real Uses are going to be impacted by dis-allowing SMB shares? Does anybody *need* this feature? Somebody posted that large ISPs are using SMB shares -- Perhaps asking them if this would kill them, or if they could manage to mount everything as a named drive. They're probably the ones most at-risk and with the best understanding of the Real World issues/risks. It's entirely possible, yea, even likely, that I'm "missing" something fundamental here, but it seems like you're trying to block something that only somebody really smart could intentionally open up to "prove" how insecure PHP is, rather than an actual Security Issue. PS I found it interesting that the CAPTCHA on the blog that started this thread doesn't work... And the comments box doesn't scroll properly when you type too much. [Which I'm sure some here think I type too much anyway... ;-)] PPS Since I will most likely never be responsible for an SMB share as a repository for source code in a production environment, I don't have a personal stake in this one, as interesting as it as an academic exercise in "Security". :-) +0.00001
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Stanislav Malyshev

19 years ago
Ilia Alshanetsky wrote:
> What's to say /drive/smb or letter:// is not an SMB device? Also why > break perfectly valid applications that perform operations on networked > file systems?
Well, it's the same as asking why break valid apps that perform operations on URL. Because of security policy - i.e., if we choose to have security policy that disallows running code with non-local origin influenced by user data - we must do it full nine yards, not "we won't give it to you by http, but you are welcome to do it by smb". Now, if it would be not allowed by default by Windows (AFAIK it is allowed) or there's known way to restrict that from Windows (which I don't know of) - then we may defer this task to the OS, but if there's none, then I don't see how http here would differ from smb... If we say including file from http source is not OK, then why would including file from smb source ok?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Ilia A.

19 years ago
On 5-Nov-06, at 1:22 PM, Stanislav Malyshev wrote:
> Ilia Alshanetsky wrote: >> What's to say /drive/smb or letter:// is not an SMB device? Also >> why break perfectly valid applications that perform operations on >> networked file systems? > > Well, it's the same as asking why break valid apps that perform > operations on URL.
I guess it is a question of frequency, as a rule a valid use of require/include on a URL is quite unusual. From my experience, I do not believe the same could be said about smb.
> Because of security policy - i.e., if we choose to have security > policy that disallows running code with non-local origin influenced > by user data - we must do it full nine yards, not "we won't give it > to you by http, but you are welcome to do it by smb".
This is a valid point, but at the same time we need to consider the consequences marking of smb:// as url will have on PHP applications and weather this is something to be done in a patch level release. Exploitation wise all of the hacks I've seen for remote code execution were based on http as that provides the best degree of anonymity for a hacker, a freehosting page somewhere sending php code via text file. Use of SMB requires a more tricky infrastructure in a form of an open smb share, usually meaning an exploited win32 box that accepts incoming smb connections.
> Now, if it would be not allowed by default by Windows (AFAIK it is > allowed) or there's known way to restrict that from Windows (which > I don't know of) - then we may defer this task to the OS, but if > there's none, then I don't see how http here would differ from > smb... If we say including file from http source is not OK, then > why would including file from smb source ok?
A firewall rule can be used to block outgoing smb connections quite easily on both linux and windows. Ilia Alshanetsky

Peter Brodersen

19 years ago
Hi, At first I didn't think there would be an easy solution as it isn't possible to distinguish between requests to a "local" SMB server and an "outside" server. Both are network requests. But on the other hand, requesting a file specific via network protocols in PHP such as SMB or HTTP or FTP really shouldn't be any different. One is asking PHP to perform the network operation to fetch a foreign resource. The key is that administrators would be able to map the needed SMB servers as local devices (just as one would mount a NFS share or for that sake make an FTP mount) thorugh the operating/file system. In that case requesting e.g. Z:\file.txt though a device on a SMB server share (or a NFS share or a FTP share or ...) would be perfectly fine. In that case it would be the operating/file system that is performing the network operation (based on central server administration) and not some random PHP code (possibly based on user input). Of course, those rare cases where one would actually need to fetch files through arbitrary external hosts through PHP one could just turn on allow_url_include. On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com ("Wez Furlong") wrote:
>I think it's a fair assumption that a random host specified in that >way be treated as suspicious and lumped in under the >disable-includes-by-default category. > >If someone discovers that it breaks their app, when they read the docs >for allow_url_include it should be made very clear what the >implications are and what should be done prior to turning it on. > >So i have no problem with disallowing includes for paths beginning >with a double backslash on windows, when allow_url_include is >disabled. > >--Wez. > > >On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote: >> I think it'd be wrong to consider networked file system as non-local. >> Mostly because many times there are no ways to identify them reliable >> and the fact this is a perfectly valid usage that if disallowed by >> default would break a large number of applications. >> >> >> On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote: >> >> > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals >> > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >> > >> >> Yeah, we probably should. Had a chat with Wez about it too. Here is >> >> the patch. I think this catches the cases we are interested in: >> >> >> >> http://lerdorf.com/php/is_url.diff >> >> >> >> If someone could doublecheck it against those attacks it would be >> >> helpful. >> > >> > >> > Would requests to a smbserver, e.g. >> > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It >> > seems like smbserver requests are regarded as part of the default >> > filesystem wrapper. >> > >> > -- >> > - Peter Brodersen >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> >> Ilia Alshanetsky >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
-- - Peter Brodersen

Richard Quadling

19 years ago
I develop solely on and for our Windows network. I regularly use includes on 2 different servers via \\ rather than a mapped drive. I can see that adding \\ to the list of restrictions would be an issue for me. But also, it is a trivial ini update to remove the problem. And it DOES make PHP more secure. So, +1 to add \\ to the list of restrictions. Not so sure it would be as easy for shared host ISPs on Windows to fix this though. On 05/11/06, Peter Brodersen <penguin@php.net> wrote:
> Hi, > > At first I didn't think there would be an easy solution as it isn't > possible to distinguish between requests to a "local" SMB server and > an "outside" server. Both are network requests. > > But on the other hand, requesting a file specific via network > protocols in PHP such as SMB or HTTP or FTP really shouldn't be any > different. One is asking PHP to perform the network operation to fetch > a foreign resource. > > The key is that administrators would be able to map the needed SMB > servers as local devices (just as one would mount a NFS share or for > that sake make an FTP mount) thorugh the operating/file system. > > In that case requesting e.g. Z:\file.txt though a device on a SMB > server share (or a NFS share or a FTP share or ...) would be perfectly > fine. In that case it would be the operating/file system that is > performing the network operation (based on central server > administration) and not some random PHP code (possibly based on user > input). > > Of course, those rare cases where one would actually need to fetch > files through arbitrary external hosts through PHP one could just turn > on allow_url_include. > > On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com > ("Wez Furlong") wrote: > > >I think it's a fair assumption that a random host specified in that > >way be treated as suspicious and lumped in under the > >disable-includes-by-default category. > > > >If someone discovers that it breaks their app, when they read the docs > >for allow_url_include it should be made very clear what the > >implications are and what should be done prior to turning it on. > > > >So i have no problem with disallowing includes for paths beginning > >with a double backslash on windows, when allow_url_include is > >disabled. > > > >--Wez. > > > > > >On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote: > >> I think it'd be wrong to consider networked file system as non-local. > >> Mostly because many times there are no ways to identify them reliable > >> and the fact this is a perfectly valid usage that if disallowed by > >> default would break a large number of applications. > >> > >> > >> On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote: > >> > >> > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals > >> > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > >> > > >> >> Yeah, we probably should. Had a chat with Wez about it too. Here is > >> >> the patch. I think this catches the cases we are interested in: > >> >> > >> >> http://lerdorf.com/php/is_url.diff > >> >> > >> >> If someone could doublecheck it against those attacks it would be > >> >> helpful. > >> > > >> > > >> > Would requests to a smbserver, e.g. > >> > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > >> > seems like smbserver requests are regarded as part of the default > >> > filesystem wrapper. > >> > > >> > -- > >> > - Peter Brodersen > >> > > >> > -- > >> > PHP Internals - PHP Runtime Development Mailing List > >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> > > >> > > >> > >> Ilia Alshanetsky > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > -- > - Peter Brodersen > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

Tom Sommer

19 years ago
On Mon, November 6, 2006 09:55, Richard Quadling wrote:
> I develop solely on and for our Windows network. I regularly use > includes on 2 different servers via \\ rather than a mapped drive. > > I can see that adding \\ to the list of restrictions would be an issue > for me. > > But also, it is a trivial ini update to remove the problem. And it > DOES make PHP more secure. > > > So, +1 to add \\ to the list of restrictions. > > > Not so sure it would be as easy for shared host ISPs on Windows to fix > this though.
This seems to be more of a network setup issue, rather than a PHP issue. If you haven't blocked access to remote SMB servers in your network, you are asking for trouble. If you have a rogue SMB box or mount on your network, PHP is the least of your problems. You can pretty much guarantee that if people are including URLs, they are either asking for trouble or looking for it. Blocking network mounts seems to be too much of an edge case for it to be included as a feature in allow_url_include, as it might have valid uses while URLs does not. You could add a allow_remote_include option, but that would require another INI option, and those aren't so popular :) My two cents // Tom

Nuno Lopes

19 years ago
> Stefan Esser writes here: > http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html > > that allow_url_include (and allow_url_fopen) can be easily worked around - > i.e. extrenally-supplied code executed on server - by using php: and > data: URLs. I think if we want allow_url_include have any value than we > should fix it... What do you think?
I don't usually intervene in discussions nor rudenesses here, but this time I felt I had to write this.. I'm pretty tired and reading such pathetic posts is frustrating.. Well in first place I think Stefan should define in which side he is. He pretends to be a PHP developer, but he doesn't act as one, as it posted a message in his blog saying that a product that he supposedly helps to make is insecure.. This is not really ethical, IMHO. If he found some problem (security related or not), the first thing he would have to do was to warn the PHP team (or fix it directly), not to release a public advisory, nor an exploit, nor a slashdot/digg/... post, nor whatever.. But yes, I agree with Ramus' patch.
> Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper.
Well, this is a windows only problem. open_basedir will block it, but probably it won't be blocked by anything else as it is handled as a local file by the OS. However, we can/should also think in this problem. Nuno

Stefan Esser

19 years ago
Nuno, there is a simple answer to your email: stick your anti Esser propaganda deep into some place noone is interested in. Before I posted about this, I brought this topic up MONTHS before PHP 5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6 tree. And now please die or just shut the fuck up. I am sick of morons like you who believe they can attack me without knowing the facts. Stefan Esser

Nuno Lopes

19 years ago
> Nuno, > > there is a simple answer to your email: > > stick your anti Esser propaganda deep into some place noone is > interested in.
I was already expecting this kind of answer from you, but you clearly don't know me. The previous e-mail wasn't a personal attack nor an attack to your business, nor I was doing any type of propaganda against you. I really appreciate your effort in researching new security problems in PHP itself and in its usage. I personally also like to analyze the PHP code when I have some free time as you do, which is a task that most developers doesn't usually like.
> Before I posted about this, I brought this topic up MONTHS before PHP > 5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6 > tree.
I didn't know that, really. But in theory I'm also a PHP developer (although not very active) and I didn't receive any information about that. So, I don't know who knew that. But if the security team was aware of that, I present my excuses to you.
> And now please die or just shut the fuck up. I am sick of morons like > you who believe they can attack me without knowing the facts.
If people doesn't know the facts, just explain the things to them nicely. No violence is needed, IMHO. Nuno

Stefan Esser

19 years ago
Hi Nuno,
> > I was already expecting this kind of answer from you, but you clearly > don't know me. > The previous e-mail wasn't a personal attack nor an attack to your > business, nor I was doing any type of propaganda against you.
Calling my actions unethical and my posts pathetic is kinda a personal attack in the real world.
> I didn't know that, really. But in theory I'm also a PHP developer > (although not very active) and I didn't receive any information about > that. > So, I don't know who knew that. But if the security team was aware of > that, I present my excuses to you.
The fact that allow_url_fopen does not affect php://input was not only brought up by me before but is actively used by skript kiddies for years. And I really don't like to repeat myself 1000 times. When I brought this up the response I got was: "Yeah whatever. Stopping a few URLs is better than stopping none."
> > If people doesn't know the facts, just explain the things to them > nicely. No violence is needed, IMHO.
Well PHP developers discuss on IRC how to kill me best by shooting me in my back. I am just answering in the same tone. Stefan