[Glass] Implications of #removeAllSourceButFirstComment [WAS] Re: data encryption

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano,

Regarding "I don't want my client to have access to my app code," why not?

My first thought was that if you were afraid of your customer stealing your code, you probably don't want him as a customer anyway. :-) Obviously, there is more to it than that.

Given the recent popularity of open source everything, is it really worth the trouble to have a closed source system? This is especially so in Smalltalk which has always included the source, with very few exceptions.

Given Smalltalk code as Open Source is more or less practically equal to
closed source, unreadable source or unuseable source.

Mainly to the fact, that Smalltalk is a very small niche software and a
customer might need a Smalltalker to understand this ... and this chance
is mostly equally to zero.



Marten



Am 11.05.2015 um 22:11 schrieb Richard Sargent via Glass:
> Mariano,
>
> Regarding "I don't want my client to have access to my app code," why not?
>


--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

My replies embedded...

On Thu, Feb 19, 2015 at 4:53 PM, James Foster <[hidden email]> wrote:

> On Feb 19, 2015, at 11:40 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:
>
> Anyway...what I would really like is a way to obfuscate a repository (I don't want my client to have access to my app code) in the case I must deploy my app in client's server. Is this possible?

See GsNMethod>>#’removeAllSourceButFirstComment’

James

Hi, 

I want to know the implications of #removeAllSourceButFirstComment.

This would solve showing code when browsing, file out, getSource blah blah blah. My questions are...

1) for logs (when there is an error in the seaside gems and the stack is written to log file) this should not be a problem, right?

this should not be a problem ...

2) what happen if I do a "Remote Debug" on GemTools and all my stuff was done with a #removeAllSourceButFirstComment? I guess I cannot open a debugger at all right?

I haven't done the experiments with this, but needless to say debugging will be difficult if you can't see the source code ...

 

3) are there any possibility after #removeAllSourceButFirstComment that instead of the selector + first comment, it displays me instead the "decompiled version" of the compiled method?  Because if this is the case, then they could get quite an approximate to the original source.

In theory this could be done as an option, but the decompiling will done via a smalltalk method call, which would also be available to a user.

Just about all of the techniques for obscuring source code have the same basic problem: the source is effectively hidden from all but the folks who are determined to get it ... the casual user will never think to "steal your source" and the sophisticated, evil user will find a way to circumvent your system ...

With that said, it occurs to me that might be possible to lock down access to source code/decompiliation/etc. by creative use of Session Methods ... with session methods you can override the dangerous methods like #source the #compile:classified: methods in only the sessions  where unsafe code might be executed. Your override would simply return an innocuous string or in the case of an attempt to add a class or method, generate an error ...For debugging and development you would arrange to not install the session method overrides ...

One would have to scan the system and find potentially dangerous methods and implement an override, but I think that this can be a pretty good mechanism for deterring users from doing casual spelunking:)

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass