LiveCode Forums.

I have put together the attached stack, in order to clear to my self how encrypting and decrypting stacks can be done.

As of now it works:
- open stack TestUno
- click on "OpenOtherStak"
- stack "TestDue" will open
- make some change to it
- click on "SaveOtherStak"

But there are a few things that I don't understand:

1) line 10 of command "cassaopen":
The decrypt put the decrypted data into it. If I don't do the "go it", nothing happens.
Is this the only way to make LC to recognize the opened stack? (without saving it to disk)
What is "it" at that point? Can I put it into a global and make the stack appear later on (uh!)?

2) after opening the stack "TestDue", this stack doesn't have a file path (you can see it int the RevApplicationOverview or in the project browser)
Is it ok to keep working with a stack only in memory and save it encrypting whenever needed (probably often) ?

3) line 23 of command cassasave
I did not know how to load the binary data of the stack, in order to pass them to the encrypt command, without first saving the stack to disk.
Is there another way to do it in memory only?

4) line 35 of command cassasave
after deleting the cashed stack, there is no file anymore
- on the RevApplicationoverview the TestDue still shows its path: Wrong
- on the project browser it does not have a path anymore: OK
- doing a "the filename of this stack" report the path: Wrong
What gives?

Any comment and suggestions are welcomed
Trevix

Nice work, Trevix. Good solution for encrypting stack files.

Let's see if I can help answer these questions:

trevix wrote:1) line 10 of command "cassaopen":
The decrypt put the decrypted data into it. If I don't do the "go it", nothing happens.
Is this the only way to make LC to recognize the opened stack? (without saving it to disk)
What is "it" at that point? Can I put it into a global and make the stack appear later on (uh!)?

A stack derived from a binary blob (whether the blob was originally encrypted data, or any data read using "read" rather than "open" or "go", or downloaded from the web) is initially just data to LC; the engine treats it as any other collection of bytes. A "go" or "open" command is needed to tell LC it's a stack, prompting it to unpack it as such and then send messages (preopenstack, etc.) to it.

2) after opening the stack "TestDue", this stack doesn't have a file path (you can see it int the RevApplicationOverview or in the project browser)
Is it ok to keep working with a stack only in memory and save it encrypting whenever needed (probably often) ?

You can work with it in RAM only, but like anything in RAM it's volatile and subject to loss in the event of power outage, etc. Save regularly, whether with LC's "save" command or your custom encrypted variant.

3) line 23 of command cassasave
I did not know how to load the binary data of the stack, in order to pass them to the encrypt command, without first saving the stack to disk.
Is there another way to do it in memory only?

The only purely in-memory option I've found is to use the "copy" command to copy the stack, and using "paste" to restore it. After using copy, the clipboardData["objects"] will contain a clipboard-compatible copy of the stack data. Note that this is different from the data of the stack by itself, and while there may be a way to parse that out I haven't taken the time. Once you get the clipboardData["objects"] you'll have a binary stream you can write to disk, send over the network, etc. To restore reverse the process: get the byestream, stick it into the clipboardData["objects"] then paste.

As a favor to your user you'll probably want to save and restore the contents of the clipboardData array before copying and when restoring, and reset the clipboardData to that when you're done.

4) line 35 of command cassasave
after deleting the cashed stack, there is no file anymore
- on the RevApplicationoverview the TestDue still shows its path: Wrong
- on the project browser it does not have a path anymore: OK
- doing a "the filename of this stack" report the path: Wrong
What gives?

Not sure why there are differences among inspectors (bug in one or more of them not updating in a timely manner?), but your cassasave routine deletes the file, but doesn't clear the filename of the in-memory copy of the stack.

I've never tried this before but I was curious while writing this reply, so I tried setting the filename of the stack to empty and sure enough it works as expected; querying the property after that confirms it's empty, and next time I hit Ctrl-S it brings up the Save As dialog as I would expect for a stack that has no filename.

Thanks for the answers.
I have seen that in the Forum and the quality control center, the need to put a stack into a var has already been discussed in the past.

I'am having some problem on getting a sure reference to the decrypted stack:
- decrypt the binary
- go it (in order to transform it in a stack)
- how do I refer to the new opened stack?

I tried "put the short name of it" but it doesn't work
Sometimes "put the short name of current stack", works but not always: sometimes the function return the name of the main stack, not of the just opened one (also note that in my App the script is running in a library stack so things gets complicated).
Probably also "defaultstack" could work. But i wish something more safe.

I also noticed that th name of the stack appears in the decrypted data (in my example "TestDue")

REVO7000ÌTestDue1 P6On Preopenstack
answer "preopen"
end Preopenstack
ÄQãêê= ˇˇˇˇcREVGeneral
breakpointstatesbreakpointsbreakpointconditionsscripteditorselection36scalefactor?scripteditorvscrollÍ @êê:ÌÌShow the path of me‚Eãp=on mouseUp
answer the filename of this stack
end mouseUp
Ä%»òcREVGeneral
scripteditorvscrollscripteditorselection48

But I am not sure how consistent this could be.

Regards
Trevix

As you can see from the attached example, also using the copy and paste there is a problem of referencing the opened stack.
Having a defaultstack at line 3 of stack cassafort, when doing a paste (line 18) the stack appear ok, the preopenstack is run BUT the default is not updated.

Also, a strange "untitled 2" stack appear on the project browser.

So I managed to have my standalone to save encrypted stacks:

1 - change the name of the stack to be saved to a uuid() ( so that i can reference it when i load it)
2 - save it to "temporary"
3 - load the binary to variable
4 - encrypt the variable
5 - save the encrypted file to disk (put tUUIDname & it into URL ("binfile:" & pPathTo)
6 - clean up
delete the file from "temporary"
rename the stack to its original name
set its filename to empty (other wise is the path to temporary)

At the end of all this (sigh), I am slightly annoyed of having the IDE to remember me that the stack is not saved, if I quit. Without using a back script as in http://use-livecode.runrev.narkive.com/ ... ack-dialog, have there been a change in the gRevStackStatus flag, so that I can tell the IDE that the stack is saved?

Thanks
Trevix

As far as I can tell, the gRevStackStatus flag is no longer in use.

Just curious why you don't just password-protect the stack, which encrypts and doesn't require you to do anything special when opening it.

Because my standalone needs to make a duplicate of a stack or substack, copy groups in and out of it, save it to desk or the web with other users, many time during a session.
I tried but because of the fact the Passkey is not reversible without closing and reopening a stack, I would have to do it too many times to make it reasonable.