Getting rid of .sources file for deployment

On 29 Aug 2020, at 04:49, Esteban Maringolo <[hidden email]> wrote:

Hi,

Is there a way to get rid the .sources file in a deployment scenario?

I followed this guide [1], but I cannot get rid of the .sources files,
because I'm using PharoADO (which uses PharoCOM) and it uses some
reflection for FFI and for some reason that implies using the .sources
file. I installed the FFICompilerPlugin as per the instructions, but I
don't have a way to tell whether I did in the right place/moment, nor
how to assess its proper installation.

If such [2] .sources file cannot be removed, what is the criteria for
the lookup, can it be renamed or modified via some parameter/config?

Thanks!

[1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/DeployYourPharoApplication.md#sources-obfuscation
[2] Pharo8.0-32bit-0932da8.sources in my case


Esteban A. Maringolo

On 3 Sep 2020, at 20:50, [hidden email] <[hidden email]> wrote:

On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> wrote:

The .sources file has been optional for as long as I can remember.  
Is it OK for list that somebody breaks this tradition? 
Trygve

Hi Trygve,

I’m not sure what you mean by this question. 

Are you asking, “Is it acceptable to have code that relies on reflection in order to operate properly?” To this question I would answer “yes” since some things are easier to do using reflection.

Or are you asking, “Would it be better to not have FFI at all until it can be implemented without reflection?” To this question I would answer  “no” since people that don’t want reflection can choose to forego features that require it.

Or are you asking, “Would it be nice if someone could do the work to implement FFI without reflection?” To this question I would answer “yes.” Unfortunately, there is a cost involved.

So were you asking one of those questions or something else?

James

On 4 Sep 2020, at 22:05, Esteban Maringolo <[hidden email]> wrote:

My compromise would be to disable the GUI version of the VM.

How can I compile a VM with the --headless setting hardcoded? Where to start?

Esteban A. Maringolo

On Fri, Sep 4, 2020 at 2:39 PM Stéphane Ducasse
<[hidden email]> wrote:

Thanks James

This is pretty much the right questions :)
And I would love to have money to solve the problems the way I would like but life is a compromise.

S

On 3 Sep 2020, at 20:50, [hidden email] <[hidden email]> wrote:


On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> wrote:

The .sources file has been optional for as long as I can remember.
Is it OK for list that somebody breaks this tradition?
Trygve


Hi Trygve,

I’m not sure what you mean by this question.

Are you asking, “Is it acceptable to have code that relies on reflection in order to operate properly?” To this question I would answer “yes” since some things are easier to do using reflection.

Or are you asking, “Would it be better to not have FFI at all until it can be implemented without reflection?” To this question I would answer  “no” since people that don’t want reflection can choose to forego features that require it.

Or are you asking, “Would it be nice if someone could do the work to implement FFI without reflection?” To this question I would answer “yes.” Unfortunately, there is a cost involved.

So were you asking one of those questions or something else?

James


--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Aurore Dalle
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

On 6 Sep 2020, at 15:55, Esteban Maringolo <[hidden email]> wrote:

Stef,

On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse
<[hidden email]> wrote:

just a question what if a bad guy you want to protect from is just smart
and use a default vm.

You're talking about decompiling and I'm talking about not making it
trivial to see the code, internals and other things.
Security is always what you can afford to protect form, with enough
resources anybody can crack most of the existing software.

I mean what kind of thieves do you want to protect from?

Think of it this way... as it is is like saving a six digits password
in plaintext on a file, what I propose is to have the same file, but
with the password encrypted with a lousy crypto (still easy to crack
with a dictionary attack but not as easy as seeing it at plain sight).

I'm not trying to protect from thieves, but from the competition.
This client part of the software runs in a computer where there is
also the software it's going to replace (eventually).

I simply want to obfuscate a little so it's not trivial to open it.
I'm not asking about encrypted image files. :-)

Because you can let everything and block the menu + the DNU and other exception
and nobody even you will be able to access the code.
If you remove all the <world menu> menu and toolbar + DNU + exception ...

I followed most of the guidelines to deploy it obfuscated [1].
But if there is a guide for obfuscation, it means that there is some
need for it, I just want to go one extra step.

Thanks!

[1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/DeployYourPharoApplication.md#sources-obfuscation

Esteban A. Maringolo