go RE: OT: PHP/filePro Tools

[Fairlight]

On Sat, Jan 30, 2016 at 04:34:25PM -0500, Mike Dawson via Filepro-list thus spoke:
> A couple of comments:
> 
> 1.  PHP is an ever evolving challenge to keep secure.  There is no argument
> you can present to discredit this fact.

No doubt.  It used to be the case that there was a hole or three per week.
They've gotten it down to a few per month but...  Anything which builds
with stock configure values and generates over 20 screens of warnings is
not something I trust - with good reason.

> 	PERL is a far more secure interface IMHO.

Indeed.  I think there have been three Perl security patches in the last
decade.  I can only clearly remember two, but I think there -may- have been
a third - in 10-15 years.  PHP didn't make it more than seven days into
this year before needing 5.6.17 (noted as a security update on their site).

Then there is the 'quality' of PHP code written by developers using the
language, further compounding the issue.  Can you shoot yourself in the
foot with Perl?  Sure.  You have to go out of your way to do it, but it's
possible to override the safeties if you really want to.  Few who still
program in it would do so.

PHP is the AOL of languages - so simple any idiot can do it, and far too
many do.  Designed about as well, too.  And don't start me on a company
who replaces the entire PCRE library on a whim "because it was available"
on a third pointlevel patch which is patching a fouled patch from the day
before.  Zend's done exactly that, at least once.  Third pointlevel patches
should arguably never break building an RPM, and they have repeatedly done
so.

Not all PHP coders are bad.  However, it's like any community; the more of
the general population you draw in, the further the quality of your
population declines.  That goes for any community, from programming, to
gaming, to whatever.

There's actually a reason I believe the code.org initiative is a bad idea.
They're going to teach everyone and their brother to code, but I'm betting
they won't teach them proper methodologies, systems, security, etc.  I'm
doubting most of the instructors even know those areas worth a damn.  It's
not an elitist view, it's a practical view; you don't want people coding
who don't actually know systems, or who know just enough to be dangerous.
You should see some of the code out of Ukraine or Mumbai.  *shudder*

> 4.  Your approach sounds to be more of a read only method.  Should you
> attempt to implement a full R/W solution utilizing fP's index system,
> 	I fail to see how the lockfile issues can be avoided.

Depends which locking you're talking about.  If it's strictly fcntl()
locking of a byte segment of a file, no problem.  If it comes down to
needing to calculate proprietary checksums or manipulate the same shared
memory segment, you start veering into DMCA-suit-inducing territory.  I
-believe- simply modifying the indexes would strictly be a fcntl() oriented
approach, but I don't know that definitively.  But if there are checksums
in the indexes (and many fP files have checksums based on proprietary
calculations/algorithms), then manipulating those definitely would veer
into DMCA territory as well.

mark->