[ale] Well, this does nothing for the reputation of Linux

[Andy Borgmann]

Mike -

"Have fun rewriting your code for PHP 5.4 and later releases, by the way."
- you really are a bit passive aggressive aren't you.

Needless to say, thank you for your thoughts.  I genuinely appreciate them.
 I have learned a few things here today, which is the whole reason I
monitor (but rarely jump into) the discussions here.  Much appreciated.

*
*
*--*
*Andy Borgmann*

E-mail: andy at borgmann.me
Cell Phone: (404) 492-6527
Personal Website: http://andy.borgmann.me/<http://andy.borgmann.me/?r=email>

"*Preach the Word; be prepared in season and out of season; correct,
rebuke and encourage - with great patience and careful instruction.*" -
2Timothy 4:2


On Mon, Jul 22, 2013 at 10:36 AM, Michael B. Trausch <mbt at naunetcorp.com>wrote:

>  On 07/22/2013 10:15 AM, Andy Borgmann wrote:
>
> No need to get defensive.  I am not "minding" you, and I am sure you are a
> great programmer and have more experience than me.  My only point in this
> is that PHP is not inherently insecure.  Not saying it is better than C or
> Java or Python.  All I am saying is that the security flaws in PHP have
> more to do with poorly written code that is publicly viewable to the world
> than the system itself, and that the examples provided thus far haven't
> convinced me that it is any less secure than I originally knew other than
> less qualified people use it due to the low barrier of entry.
>
>
> On a technical level, you are correct.
>
> On a practical level, the only way to secure the web of PHP applications
> that are out there that would have any chance at being effective would be
> to remove PHP's automatic-screw-yous (e.g., the array one is particularly
> bad if you've ever been bitten by it—and you'll never, ever forget it if
> you do get bit by it, either) as well as remove its bad ideas.
>
> For example, there should be a standard, inbuilt method for creating
> secure SQL queries, and you should have to go out of your way to bypass
> it.  IOW, secure by default.  There is, sort of, but the defaults are still
> "whatever you want".  C# fixed this problem in its world by creating an
> extension to the language that maps directly to database queries (and it
> actually was developed for security sake, but it seems to create far better
> queries than most humans do by default, so in that case, security caused a
> performance benefit, too).
>
>
>  And I would very much be interested in what you know about HipHop,
> because everything I have read about it and looked into relates to
> performance, not security.
>
>
> It's been three or four months since I spent any time looking at it.  I've
> come back to looking into it with every PHP project I have done, including
> the current one.  However, the base requirements for the project I'm on,
> once they were decided, excluded HPHP for technical reasons (the base
> cannot be compiled with it).
>
> Among the things that weren't supported the last time I checked it out,
> and I *believe* are still unsupported (and these are the overlapping
> ones—both technically difficult and insecure):
>
>    - eval—which shouldn't really ever be used anyway, as it allows
>    injection to occur upon the compromise of any system trusted to inject via
>    that method.
>    - dynamic includes—With truly bad code, there is no way to avoid
>    them.  Such code cannot ever be compiled by HPHP because the very thing it
>    depends on does not exist.  (They do appear to have a new mode that runs in
>    a VM that might allow it, but whether they enabled such functionality or
>    not is not easily discoverable and I'd have to check it out to test it.)
>    Dynamic includes are worse than most people realize because they almost
>    never realize just how easy it is to attack and trick a PHP system into
>    including things outside of the app's control.
>
> Namespaces weren't implemented, either, the last time I checked, but that
> was because they hadn't gotten around to adding support for PHP 5.3 yet.
> Those are a great security feature, too.
>
>
>     — Mike
>
> --
>   [image: Naunet Corporation Logo]  Michael B. Trausch
>
> President, *Naunet Corporation*
> ☎ (678) 287-0693 x130 or (888) 494-5810 x130
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/bc296518/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jiifjbbg.png
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/bc296518/attachment-0001.png>