Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Kevin Ingwersen <ingwie2000@googlemail.com>
Cc: Bas van Beek <bas@tobin.nl>, PHP Internals <internals@lists.php.net>
In-Reply-To: <416063C7-D802-4AD1-938C-035F0EBC373D@googlemail.com>
References:
	 <CAOg_pRQxKsJPgFaZ6_y7Rf1i4Bfkbx+FhCxuBtE9PWu58uOfOQ@mail.gmail.com>
	 <537DA268.1000801@tobin.nl>
	 <416063C7-D802-4AD1-938C-035F0EBC373D@googlemail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 May 2014 16:29:08 +0200
Message-ID: <1400768948.2870.9057.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] encode php scripts with opcache compatibility
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Thu, 2014-05-22 at 15:47 +0200, Kevin Ingwersen wrote:
> Definitively an aproach I am going to test out myself, to learn more
> about this.

Mind that a user could simply do something like this in an
auto_append_file to get all scripts:

   <?php
   foreach (get_included_files() as $filename) {
       $sourcecode[$filename] = file_get_contents($filename);
   }
   ?>

So this ains little over using a phar file.

The question is from what kind of users one wants to hide this ... 
> 
The simple solutions provide ways to retrieve the source code easily (be
it by a simple printf() in the engine .. even that should be doable by
everybody who could understand the source and who has interest in it).
The a bit more advanced ways allow dumping opcodes which can be used to
Recreate the PHP code quite closely (our opcodes are quite high level
and we don't do notable optimisations, we even keep original names for
most things)
More advanced solutions use an extra executor and (more or less)
modified opcodes. This requires hacking this opcode ... has been done in
the past.
So maybe indeed go to system level (C / C++) languages.

What you also can do is rethink your business model, if you distrust the
users that much maybe you don't bring them the notable business value.
I've seen different companies which got rid of opcode encryption and the
customers loved the simpler deployment ...
(and yes, there are [more or less] valid business models around specific
algorithms, if the secrecy of the algorithm really is your value then
put it in C)

johannes