OpenXTalk Forums

From a posting [on another forum]:

https://www.infoworld.com/article/37132 ... c.amp.html

Is xTalk 'Memory-safe'?

"Memory-safe programming languages are protected from software bugs and vulnerabilities related to memory access, including buffer overflows, out-of-bounds reads, and memory leaks. Recent studies from Microsoft and Google have found that about 70 percent of all security vulnerabilities are caused by memory safety issues."

Q-n-Dirty Googly-Woogle:

"Memory safe languages include Rust, Go, C#, Java, Swift, Python, and JavaScript. Languages that are not memory safe include C, C++, and assembly."

If xTalk is memory-safe we should be shouting that at top volume for all to hear!

My understanding is that stacks are read into memory in LC / OXT.
(At least that's what the user guide states).

As with most programs, you can look at a memory disassembler and see what is currently loaded into memory at any given offset. If you can figure out the offsets of the allocation tables, you can pretty much read and write to any value loaded into memory - and force other code in.

This is a known technique in many nefarious circles, but potentially anything that loads data into one consecutive chunk of memory isn't deemed 'memory safe'. I don't think xTalk / Transcript has been designed with safe memory registers in mind - I'd be very pleasantly surprised if it had, but normally this needs to be specifically planned from the outset. Knowing what I know of the engine code, I'd hazard an educated guess that it's not been thought about.

The original poster said. "reason to keep using LiveCode", which was a bit silly without having checkiled if LiveCode is memory-safe first.

richmond62 wrote: ↑Wed Feb 28, 2024 10:47 am "Languages that are not memory safe include C, C++, and assembly."

If xTalk is memory-safe we should be shouting that at top volume for all to hear!

The engine is written in C/C++ and uses libraries written in the same, so that pretty much answers that question.
That doesn't mean the OS APIs or some other mechanism can't provide some levels of protection/sandboxing. IIRC Objective C has an object type or two for keeping things like passwords or other sensitive data in memory in a non-clear / encrypted way to prevent peaking.

That said, I specifically do not give any guarantees or warrantee about the security of the engine. In short I do NOT recommend for anyone to use a Stack for doing online banking or similar.

If anyone does want some sort of warranty with an xTalk scripting engine then you're looking in the wrong place, and should contact LC Ltd. and ask them about how secure their commercial product is (and then maybe get an independent assessment/second opinion), and what security guarantees they can provide, and then subscribe to their Engine/IDE-as-a-service platform if you're satisfied with the answers. I would not count on any guarantees from any limited liability company.