go RE: OT: PHP/filePro Tools

[Jose Lerebours]

Let me craw back to my office and pop a few pills!


On 01/30/2016 04:53 PM, Fairlight via Filepro-list wrote:
> 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->
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list