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

[Dale Henrichs via Glass]

My replies embedded...

On 5/11/15 9:33 AM, Mariano Martinez Peck via Glass wrote:
>
> On Thu, Feb 19, 2015 at 4:53 PM, James Foster 
> <james.foster at gemtalksystems.com 
> <mailto:james.foster at gemtalksystems.com>> wrote:
>
>     > On Feb 19, 2015, at 11:40 AM, Mariano Martinez Peck via Glass <glass at lists.gemtalksystems.com
>     <mailto:glass at lists.gemtalksystems.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150528/adde12ee/attachment.html>