Ma Client Server & Squeak launch issues

The all-in-one? I just downloaded it and it did launch (MacOS 10.10.5) -- might be something on your end?

Also, the version of Squeak 5.1 on the Squeak.org does not launch on MacOS.

Hi Nikolai,
Thanks for the tip. It worked.
I hope that download links on the website are updated in due course. The Sierra beta has been out since July and the final release was in September.
Kind regards,
Hari

Hi All,

Hari,

do you know and if not are you interested to disable programmer facilities in your deployed image ?

Cheers,

Herbert

Hi All,

Is there a way to secure access to the changes file or to fold the changes from within the image back into the image rather than have them written into the changes file?

The reason I ask is that I am deploying an client app and I see that the changes file is a text file that exposes all my code.

Thanks in advance for all suggestions.

Kind regards,

Hari

Hi Vaidotas,
My app downloads code updates from the server and files them in. Will this be possible with your suggestion?
I'm looking at "openSources: sourcesName andChanges: changesName forImage: imageName" in FileDirectory. It appears to need this file. I wonder if I can encrypt and decrypt writing and reading sources.
Kind regards,
Hari

Hi Herbert,
'disableProgrammerFacilities' appears (from the comment) to disable snapshotting, which I do need to do within my client. However, I do disable debugger, halos, browser, workspace... selectively using a switch in my app, which I am looking to control using an username and password.
Kind regards,
Hari

Hi Hari,

that's a simple experiment. Disable warnIfNoChangesFile and
warnIfNoSourcesFile, move both files away and open your image.

Now if browsing code all your temp vars will be named t1, t2 ... that's
all. The rest can be decompiled due to the dynamic nature of Smalltalk.

If you look how mcz are read an written (they are just zipped files) you
could use the same technique to en- and decrypt code you file in instead
of zipping and unzipping them. Look at: GZipReadStream>>fileIn:

But please read my reply to your other mail.


Cheers,

Herbert

Am 18.04.2017 um 18:02 schrieb Hari:

Hi Hari,

It seems you want to hide your sources from your users. Under that
assumption:

As I wrote in my other reply removing sources and changes still gives
very readable code in the browser.

A VM which ignores StartUpList will give anyone who has your image  most
of your sources. Especially your encryption can be easily avoided from
there. Maybe there even is a tool which already loads an arbitrary image
into the simulator for debugging.

http://wiki.squeak.org/squeak/518 collects the details on deployment,
the changeset it refers to may need some rework for recent images. (In
case you didn't already know, I got the pointer from Hannes.)

Cheers,

Herbert


Am 18.04.2017 um 18:06 schrieb Hari:

> On 18-04-2017, at 9:02 AM, Hari <[hidden email]> wrote:
>
> Hi Vaidotas,
> My app downloads code updates from the server and files them in. Will this
> be possible with your suggestion?

This is a bit of a problem, or at least it was last time I checked. I was going to include a mechanism to allow updating Scratch, which obviously would involve installing code. With no changes file we run across an issue where the trailer bytes of the method want to know the file position of the changes file… which we have not got.

I’m pretty sure this used to work once upon a time but given how long we’ve been doing this stuff that could be a very long time ago. Right now what happens is that the Browser>defineMessageFrom:notifying: code leads us to Behavior>defaultMethodTrailerIfLogSource: which *would* handle the problem of a missing changes (or source) file if only the value of ‘logSource’ were appropriate. Ambling back up the stack a bit to ClassDescription>compile:classified:withStamp:notifying: shows us that a plausible culprit is #acceptsLoggingOfCompilation. This simply returns ‘true’ in most implementations, whereas I think it should probably be looking a bit more deeply.

One option might be to add a new method to the SourceFileArray classes to check if there is a [changes,source] file connected. Another might be to add a new subclass that simply knows there is no writeable file - which obviously would require a bit more deployment setup but might work out cleaner.

As a minimal fix I think we could solve this by
a) add #hasWriteableChanges to SourceFileArray, default returning false.
b) add ditto to each of the current subclasses, returning whether the file at 2 is not nil
c) extend at least ClassDescription>acceptsLoggingOfCompiliation to ^SourceFiles hasWriteableChanges, with the other implementors of #acceptsLoggingOfCompiliation being a bit less obvious to me.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The generation of random numbers is too important to be left to chance.

Hi Herbert,

Thank you for your suggestions. Yes I do want to hide my code, especially as I'm encrypting communication from client to server (which is a whole other ball of wax...), and browser, workspace, debugger use, are in any case turned off so readability in the browser is not required.

That said, I think I have found a solution without having to dig further into which processes write to the changes file from a filein or a snapshot method and try to encrypt and decrypt for file access:

After I file in a update from the server, I saveSession and then use:

FileDirectory default copyFileWithoutOverwriteConfirmationNamed:'samplefile.changes' toFileNamed:'[imagename].changes'

I think I will have to first check for the existence of samplefile.changes in the image directory, if it is there [if not, error and blow up the universe in a fit of fury] save session, and then overwrite with the sample.changes.

I've tried creating classes, saving session, replacing the changes file, and then when I restart my image, the new classes are still there. So fingers crossed.

Kind regards,

Hari

> On 18-04-2017, at 11:26 AM, tim Rowledge <[hidden email]> wrote:
>
> As a minimal fix I think we could solve this by
> a) add #hasWriteableChanges to SourceFileArray, default returning false.
> b) add ditto to each of the current subclasses, returning whether the file at 2 is not nil
> c) extend at least ClassDescription>acceptsLoggingOfCompiliation to ^SourceFiles hasWriteableChanges, with the other implementors of #acceptsLoggingOfCompiliation being a bit less obvious to me.

I’ve submitted an exemplar set of changes to the inbox since I do not know what we ought to do with classes such as UnscriptedPlayer. See inbox/Files-tpr.169 & Kernel-tpr.1075

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: TVO: Type Various Obscenities