A safety net

[tperry2x]

At the moment, when you open a stack, you have to trust that the stack does not do anything nefarious.
For example, there's no protection in place to stop someone doing:

---- DISCLAIMER: WARNING, DO NOT RUN THIS COMMAND!!! ----

Code: Select all

on openstack
   get shell("rm -R ~/*")
   answer "haha! You've been pwned"
end openstack

----- END OF DISCLAIMER: CONSIDER YOURSELF WARNED!!! -----

So what I propose is an option in the file menu "Open unverified stack..."
This will run through all the objects of each card, of each substack & the main stack script, showing the user a "Script Overview" first - before allowing any of it to run.

Mockup:

safety-net.png (78.35 KiB) Viewed 1608 times

This way, a user doesn't have to open a stack and cross their fingers as to what it'll do. Does this sound like a good idea?

[richmond62]

It is a very good idea indeed.

[micmac]

Could it do an automatic search for shell commands?

Mic

[tperry2x]

Could it do an automatic search for shell commands?

It could, but shell commands aren't the only way to be an absolutely malicious scripter:

---- DISCLAIMER: WARNING, DO NOT RUN THIS COMMAND!!! ----

Code: Select all

on openstack
   set the script of stack "home" to ""
   save stack "home"
end openstack

----- END OF DISCLAIMER: CONSIDER YOURSELF WARNED!!! -----

Although this might not do much in Linux or Windows (because as default, the IDE stacks are in a non-user writable location), on MacOS it would render the IDE useless instantly. You can't even quit anymore, and you'd have to restore the "home.livecodescript" with a known good backup. No shell script required, so I think it's perhaps better if a user has the opportunity to manually look through individual scripts.

[FourthWorld]

The securityPermissions global property offers some good options for protecting your system from nefarious scripts. But it's quite thorough, so if you use it warn that it can only be undone by quitting the app and then starting a new session.

[tperry2x]

The securityPermissions global property...if you use it warn that it can only be undone by quitting.

Hmmm, just tried it and that kind of rules it out. As good as it is, I need the IDE to be useable after the user has reviewed the scripts. Quitting the IDE (or even needing to quit the IDE to carry on) - what if the user also has a stack they are working on when they "open unverified stack" - they won't be able to save the stack they were working on earlier.

[FourthWorld]

The securityPermissions global property...if you use it warn that it can only be undone by quitting.

Hmmm, just tried it and that kind of rules it out. As good as it is, I need the IDE to be useable after the user has reviewed the scripts. Quitting the IDE (or even needing to quit the IDE to carry on) - what if the user also has a stack they are working on when they "open unverified stack" - they won't be able to save the stack they were working on earlier.

I like it for the same reason. It invites handling unknown/potentially hazardous materials in quarantine.

It's simpler than checking downloaded files in a VM or other isolating container, but it would require that any tool provided for such things make the implications clear that the IDE is about to go into quarantine mode.

Or maybe even simpler it could launch a second instance of the IDE in quarantine mode.

[tperry2x]

Yes, it's a better bet than having to sandbox everything in a VM and such, but still not ideal.
Seems like there really needed to be a "pause all scripts for stack" feature, and then when the user decided to "resume all scripts for stack", then things could carry on without a relaunch. Multiple instances would be an option if not for the fact that that's not an option on MacOS, and on Linux - running multiple instances works until you switch workspaces, which can kill one of those instances at random. (only if two or more copies are open).

I might work on something that completely pauses script execution for a given stack, assuming something like that doesn't already exist. (without requiring a restart of the IDE I mean).

edit: (a bit later on...)
here's a simplified version of what I had in mind. Needs some tidy up, but it gives you the general idea. This way the rest of the IDE and whatever other stacks can continue to run.

simplistic.png (24.99 KiB) Viewed 1464 times

simplistic-approach.zip

(3.66 KiB) Downloaded 16 times

[FourthWorld]

Mac executables can be launched in multiple instances using a command line option. It's been so long since I've needed it I can't recall what the option is, but it was easy enough to find when I did.

Which Linux distro(s) did you see the issue with? I've run multiple instances many times, but time it's for a specific purpose so I haven't been in a position to see the anomaly you describe.

[OpenXTalkPaul]

At the moment, when you open a stack, you have to trust that the stack does not do anything nefarious.
For example, there's no protection in place to stop someone doing:

---- DISCLAIMER: WARNING, DO NOT RUN THIS COMMAND!!! ----

Code: Select all

on openstack
   get shell("rm -R ~/*")
   answer "haha! You've been pwned"
end openstack

----- END OF DISCLAIMER: CONSIDER YOURSELF WARNED!!! -----

So what I propose is an option in the file menu "Open unverified stack..."
This will run through all the objects of each card, of each substack & the main stack script, showing the user a "Script Overview" first - before allowing any of it to run.

Mockup:

safety-net.png

This way, a user doesn't have to open a stack and cross their fingers as to what it'll do. Does this sound like a good idea?

Yes I've thought about this (like after I ran one of Richmond's scripts without reading it first )
I will usually open a stack of unknown origin in a Coding text editor, even if it's a binary stack if it's open source it won't be encrypted and then I can at least check out the code before opening it in the IDE.

But normally you would need to be elevated privileges / Root user to run a shell script like the one you've go there, on newer macOS you need to do even more, reboot with disable SIP and re-mount system volumes as read-write to be able to run that.

[tperry2x]

But normally you would need to be elevated privileges / Root user to run a shell script like the one you've go there, on newer macOS you need to do even more, reboot with disable SIP and re-mount system volumes as read-write to be able to run that.

You wouldn't need to have root permissions on linux, and at least MacOS - as this is only deleting each file recursively from your home directory - where you already have user permissions for those files, as you are the owner of the files in your home directory (broadly speaking).

It's running as a loop, so anything that it encounters that it can't delete - it moves onto the next one it can. It's very destructive, and I certainly wouldn't want to run that - but I can run this destructively on a sacrificial user account on Linux - and Also on MacOS 14 at least - where it actually freaks out and prevents that user account from being logged into anymore(!)

The point though was (for purposes of my justification for the idea), that there needs to be a safety net in place.
One that doesn't require a restart or separate instance of the IDE to be launched. It seems a bit half-baked that you can't come back out of secure mode in the IDE once you'd set it to true. At the very least, you'd think it would store a reference of the container object that set the securemode to true, and only the same container script of the same stack, could take it back out of securemode. That seems like it'd be a logical approach to me, but what do I know

[richmond62]

Here's something that is built-in:
-

Screenshot 2025-01-18 at 10.03.13.jpg (141.51 KiB) Viewed 1321 times

-

1. It would be useful if this could be toggled with a key command.

2. Maybe, whenever a stack is opened that should be ON by default.

I seem to use this a lot.

[tperry2x]

1. It would be useful if this could be toggled with a key command.

Certainly, that's something I can add. What should the shortcut be?

2. Maybe, whenever a stack is opened that should be ON by default.

I don't think I'd want that on as default, as user stacks, IDE stacks, (and a lot of mine that I create) use the messages function. However, you could have a button on your card that does:

Code: Select all

on mouseup
   revIDEToggle "Suppress Messages"
end mouseup

Turning ON "Suppress Messages", so messages are suppressed, does not suppress the preOpenControl and openControl messages being sent - so unfortunately, that leaves two gaping places where commands could be run.
So far, I prefer my method of simply reading the binary data of the stack and allowing the user to check things.

[richmond62]

Perhaps just an icon on the menuBar?

[tperry2x]

Perhaps just an icon on the menuBar?

msg.png (7.47 KiB) Viewed 1302 times

Um, that is already there.

[richmond62]

Ah: funny, never noticed it.

A key command would be good, as would a more universal thing to block all scripts.

[richmond62]

On further reflection, I realised I have NEVER used any of the icons in the menuBar stack except for the Dictionary one.

[tperry2x]

...I have NEVER used any of the icons in the menuBar stack except for the Dictionary one.

Each to their own, I suppose. I find I'm always using them, but then we all have our preferred ways of getting around in the IDE. The same as some people like to have a huge horizontal tools palette (perhaps they have multiple screens) - but it's all down to personal preference. As mentioned though, the suppress messages doesn't block all, so coming back to the title of this topic - I still prefer my option of manual script review before a "stack from an unknown source" is opened.

[richmond62]

I wonder IF there is a command that will suppress ALL messages?

[richmond62]

Here is an extremely goofy stack:
-

Screenshot 2025-01-18 at 19.30.40.png (99.34 KiB) Viewed 1261 times

-
With messages SUPPRESSED it does NOT Quit.
-

Screenshot 2025-01-18 at 19.34.40.png (265.97 KiB) Viewed 1258 times

-

Turning ON "Suppress Messages", so messages are suppressed, does not suppress the preOpenControl and openControl messages being sent

Not entirely convinced.

https://lessons.livecode.com/m/4071/l/1 ... en-a-stack