Re: Perl CGI and PHP - with some TT thrown in
On Mon, Dec 09, 2002 at 05:30:22PM +, Simon Wistow wrote: On Mon, Dec 09, 2002 at 02:59:29PM +, the hatter said: This got me wondering bad an evil thoughts about wrapping PHP as a Perl module. IIRC correctly the actual interface to the parser isn't all that complicated - something like ... I smell a trigger-happy hacker :). Maybe I'm just really thick, but would it be a better idea to run a backend PHP application server, cutting the problem into two nice, simple, easy to maintain layers. Have all the frontend in perl -- with maybe a namespace dedicated to the PHP backend via. mod_rewrite. PHP requests that need wrapped with header/ footers, etc. can be parsed by the intermediary perl. If it's the other way aronud, with perl output being fed into the PHP interpreter, I'm sure a setup similar to this could work too. Your problem sounds a bit icky though - is there no nicer way around it? Merging a PHP package into a perl app sounds minging.. David.
Re: webmail
On Mon, Nov 04, 2002 at 09:06:43AM +, Lusercop wrote: As a result of this, we now have a steady stream of security vulnerabilities published on major security mailling lists daily about insecure PHP packages (I think this is how the discussion started?). This is true. I'm gratified by your blessing. The actual PHP codebase itself has only had a few insecurities -- I haven't looked at the figures, but at a guess I'd say less than the likes of suidperl (which has been around for quite a long time I must admit, but I'm trying to make PHP look good here). I wouldn't say that using suidperl is safe, but using perl as a whole, invoked by root, is not a bad thing. PHP has had remote attacks against it: So, a uid 0 script is fine, as long as it wasn't started suid? heh. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mod_php Though I thought that there had been more than just that one. A remote arbitrary code execution vulnerability is considerably more dangerous than a local privilege escalation, in general. As far as actual holes are concerned (and I'm rather drunk right now, yes, at this time of the morning), I think there have only been two (2) in PHP 4. PHP 3 is not PHP. It's shit. :) What this boils down to, is that a) I don't believe that scalable and maintainable sites can be easily written in PHP I addressed this. It is because you suck, not the language. I thought people liked perl because of it's flexibility. And define scalability. mod_perl vs. mod_php are both equally as scaleable, ie. they rely on the Apache host. I could even argue PHP is more scaleable due its ability to run on top of shitloads of APIs. So, when your site breaks the 2 hits/sec threshold, and you need a scaleable web server and Apache is not it, a FastCGI or ISAPI-capable host might be. b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet And you've read them, as well as perl. I'm impressed -- how old are you? As someone who's debugged, modified, and written extensions for PHP, I'd say it's one of the nicer programs around to work on. Fundamental vulnerabilities are not uncommon -- in fact, you're guaranteed at least one fuckup a month these days. PHP's POST handling vulnerability was such a thing. This doesn't mean you loose all confidence in it. Therefore I'm not likely to run it anytime soon. If I were in charge of a production PHP environment (thanks to the N. Ireland I.T. industry, I'm not), it wouldn't be running facing the Internet directly. Then again, neither would mod_perl or any other large program with bits I hadn't explored. At this point, I'd like to declare the classic security is a myth followed by end of thread, before this develops into a PHP vs. Perl, which I c.b.a. with. Dave.
Re: webmail
On Mon, Nov 04, 2002 at 12:44:00AM +, Paul Makepeace wrote: According to a Netcraft survey published in April 2002, PHP is now being used by over 24% of the sites on the Internet. Of the 37.6 million web sites reported worldwide (http://www.netcraft.com/Survey/index-200204.html), PHP is running on over 9 million sites and continues to grow at an explosive rate. Over the past two years PHP has averaged a 6.5% monthly growth rate. That's an enormous number of hobby sites :-) Oh well, who knows - my basic point is that for all the interesting discussion about how bad PHP is there's an awful lot of productive work going on with it, that same work that probably wouldn't've happened with perl. (I know at least half a dozen PHPers who were too scared by perl.) I think the bad publicity that PHP gets is largely due to two/three things: a) The speed at which it evolves: PHP has went through a crazy development cycle in the last year or two.. quite a bit of the API changed to be more uniform, and other such language enhancements. This period is not over, Zend2 is on the way which will change some of the language syntax, although on saying that, perl6 is on the way too, and perl's syntax will probably change more than PHP's will with this upgrade. b) The number of bad PHP programmers: PHP is probably one of the easiest web languages in the world to pick up. Given that, and the number of .* in 24 hours books available for it, the universe now has a surplus of PHP coders who don't really know what they are doing. As a result of this, we now have a steady stream of security vulnerabilities published on major security mailling lists daily about insecure PHP packages (I think this is how the discussion started?). The actual PHP codebase itself has only had a few insecurities -- I haven't looked at the figures, but at a guess I'd say less than the likes of suidperl (which has been around for quite a long time I must admit, but I'm trying to make PHP look good here). A properly coded PHP project should be just as secure as it's perl or C (or insert-language-here) counterparts. It is the In-24-hrs-Newbie who is writing code like 'system(getenv(USERNAME));'. This could just as easily be done in any other language. (please skip the perl tainting rants :). c) Lack of traditions regarding project management and syntax style: Well organized PHP projects are few and far between; I've heard hundreds of anti-PHP arguments, most of them valid, but a large number have been that PHP does not cope well when given a large codebase (1000+ lines). If your PHP codebase has got messy, that is your fault, not the languages. PHP doesn't have a recognized way of organizing code (like Perl or Python modules), it leaves it up to you to be creative in finding a way. As a side note, there is a CPAN clone well under way, however, PEAR. The only real complaint I have with PHP is the memory management, which I have seen get messy in really simple situations. Apart from that, it's a nice neat little language. If you keep up with the development of the language (like any good programmer should anyway), you're sorted. Admittedly, PHP language development moves about 100 times faster then any other language at times, but thats just it's nature. /rant Dave.
Re: test
On Wed, Oct 09, 2002 at 06:18:02PM +0100, Lusercop wrote: I'm sure I've asked people on mailing lists before not to test to mailing lists. It really is unbelievably rude. Please don't do it. This sounds regurgitated. I have always managed to believe how rude something is, and even if something was so rude, as to be past the point of belief, I doubt it would be sending a test message to a list already partially filled with noise and spam. How else do you suggest, one can test a successful bidirectional subscription to a mailing list? Why not fill out a feature request such as allow setting of test flag in mail headers with whatever MLM software project runs this list? It'd be a hell of a lot more positive than posting Yet Another Pointless Flame(tm)[0]. Please, if you have something worthwhile to say, say it, otherwise, save some bandwidth. Dave. (being a nasty little troll) [0] This very post is such a thing[1]. [1] I'd prefer a test message to one of your typical 'mememe' posts any day of the week[2]. [2] Proof of [0] :p
