Subject:
Re: TLDP Tech
From:
####@####.####
Date:
6 Mar 2005 07:43:49 -0000
Message-Id: <Pine.LNX.4.60.0503061417330.4813@client1.linuxstuff.net.au>
Yes, all good points. PHP has had its share of exploits but if we start
with some coding standards and vet our code as we go, it should be OK.
At the end of the day, any language can be used to write sloppy code.
Some standards I'd like to see include turning off things like
register_globals and magic_quotes (is that what they're called? anyway,
they too encourage bad coding), and clean HTML (XHTML 1.0, CSS2),
Also, PHP5 would make sense as a starting point. It has better
object-oriented coding features and better XML/XSL support (based on
libxslt, not sablotron anymore thank god).
Mick
On Sat, 5 Mar 2005, Rick Moen wrote:
> Quoting Emma Jane Hogbin ####@####.####
>
>> So I would advocate going with PHP....but that's just me. It's plausible
>> we end up with a multi-language environment with different components
>> being hosted off-site and then "publishing" flat files to the ibiblio
>> server.
>
> I use PHP myself -- both by itself as a sort of HTML macro language and
> in its very common role as an intermediary to SQL databases -- and find
> it useful. (This post isn't advocacy for or against any
> software-environment alternative; you just reminded me of something
> relevant that should be taken into consideration, in my view.)
>
> Early on with PHP, and to a large extent continuing to this day, the
> emphasis has been on making the language and tools accessible to novices
> as well as experienced users. Thus, a lot of good-programming
> practices, especially for public-facing code, fell by the wayside, such
> as requiring that variables be declared and scoped before use. In
> consequence, the ability for anyone -- including random members of the
> public -- to declare a global-scope variable at any time, hung over the
> PHP-using community and lead to a number of security blowups in popular
> PHP code over the last year or two. And that's not the only misfeature:
> Here are three php.ini booleans I've set to "off", of late:
>
> register_globals
> allow_url_fopen
> file_uploads
>
> Each of those has traditionally defaulted to "on" as a convenience
> feature, and each has been a security hazard. The register_globals one
> was such a hazard that, after considerable dissention, they finally
> changed it to default = off for newer versions.
>
> Here's the thing, though: A lot of developed PHP code relies on that
> behaviour. More than one PHP package -- bulletin board packages, wikis,
> etc., breaks if, in the name of decent system security, you set that to
> "off" -- and the installation instructions will typically say "This
> package requires that you edit register_globals to "On".
>
> What I'm mostly suggesting is that, although the language certainly does
> support good, cautious coding, it also supports and (arguably) has for a
> long time encouraged the opposite. And fixing badly coded PHP so that
> it doesn't use security-risky shortcuts is much more difficult than
> cranking it out was in the first place.
>
> Just something to bear in mind.
>
>
>
> ______________________
> http://lists.tldp.org/
>
