LiveCode Forums.

Hello All,

I've been thinking deployment strategies and I've come across a question I can't find an answer to.

The deployment method I'm leaning towards is multiple "Main" stacks where one is the executable and it uses the other (.rev) stacks. I believe this is similar to how RunRev deploys the IDE as I've noticed .rev files in, for example, the Toolset folder (such as revdatagridlibrary.rev). I'm attracted to this method because of the ability to more easily update "components" of the application.

So, I would have, for example, MyRevApp.exe and BaseControls.rev as my two files to deploy. Now, I know I can password protect stacks to keep people out of them, but what is to keep someone from creating some malicious code, naming the stack BaseControls.rev and dropping it into the folder my app is deployed in. When I "start using" BaseControls, the malicious code will be executed.

Is there a way to verify a stack is really my stack before I trigger any code in the stack?

Thanks in advance,

You might consider using a checksum on the stack files: read them into a variable and pass that into the md5Digest function, which will return a binary signature of the data. If you store that signature in your standalone and compare that to an MD5 value checked on startup you should have reasonable assurance that the stack file you're checking is indeed the one you originally put into place.

That said, such a method would preclude any dynamic updates in which you may want to replace individual components without replacing the standalone.

For such cases you might consider including a function in each of your stacks which returns a value known only to your standalone; you can call a function from a given object using the "call" command. If a stack returns a different value or doesn't include that function at all, you'll either get an unexpected value or an error, and either could serve as a flag to let you know to halt execution.

Hi Richard,

Thanks for the reply.

I was thinking along the same lines of having the main executable "talk" to the stack prior to any code execution but I'm so new to Rev (and stack programming in general...I've always been an OO guy), I'm not sure of the order of events.

I've learned that to use the external stack, I use the "Start Using" command which sends the libraryStack message to the external stack. Is there a way to "inspect" or make some kind of call into the stack prior to the "Start Using" command?

hi John,

before opening the stack you are loading dynamically you could
This will prevent to trigger any of the messages that are usually sent in the opening process of the stack. Then you could call the secret function as Richard mentioned in a try catch block. If that does not throw an error, unlock messages and start using the other stack, otherwise warn your user and quit the app.

All the best,
Malte

Hi Malte.

Excellent! That's just the kind of information I was looking for. So, to clarify, if I have legitimate code in my external stack's libraryStack handler, I could do the following:

1) Lock messages
2) Start using my external stack
3) Check my "secret function"
4) Assuming it is valid, Stop using my external stack
5) Unlock messages
6) Start using my external stack again (so it can now handle the libraryStack message)

OR...

Would I be just as well off after Step 3 to Unlock messages and then Send libraryStack to my external stack myself?

Thanks again for the information! Greatly appreciated!

I would (in pseudo code)

lock messages
open invisible stack "yourLib"
try
call function
catch theErr
-- malicious reaction here
exit to top
end try
unlock messages
start using stack "yourLib"
-- move on, all fine

Hth,

Malte

Thanks, Malte! I didn't know about "open invisible".