The US Government is advising the software development community to use what it determines are “Memory Safe” development languages, to help combat cyber crime from certain nations.
I found this document which appears to provide an overview of the testing criteria. Hopefully it will help Xojo’s engineers to meet the requirements and have their tool added to the approved list.
Some detailed explanations from Malwarebytes
I guess it will take more than a dozen years for Operating Systems providers as Microsoft and Apple rewrite their OSes entirely in Rust. Linux just started a small fraction.
Swift is on the NSA’s list of recommended languages, so I’d say Apple is well on their way to being memory safe (r).
But Swift is not a low level system language, and Apple has no plans for that. That’s why Rust became the lowest denominator currently for all platforms it’s present already.
From the Swift website:
“Swift is general-purpose and modern. Suitable for everything from systems programming, through mobile and desktop apps, to cloud services.”
That was an explicit goal from the beginning. Apple wanted a language that would cover a very wide swath of use cases.
Its a bit of a dummy article I think, since you wont see Display card drivers or Kernels written in C# or Java.
There are just some jobs that the higher level languages are not fit for.
Apple MAY be planning something really. I’ve read just now that big techs joined forces on a Board of Directors of the Rust Org, but Apple did not embark it. On the other side, Apple poached some engineers from them. 
That kind of thing makes sense when you think about a company targeting not being open and controlling all aspects of its ecosystem.
Last time I’ve read about Swift, it was not allowed mixing inline assembly code, or doing proper pointer arithmetic and interfacing it with low level APIs, or accessing hardware ports, etc Those aspects a system language should have… But things could have changed after I gave up on Swift. Or maybe there’s an “Internal version” more capable… Who knows. If that changed, let me know.
When I first tried Swift 1.0, I came away after a week or two completely disappointed. At that time Xojo had a massive lead over Swift’s capabilities. Apple has worked hard, and in 4 iterations, has not only flipped the table, it’s obliterated it, at least for me.
I’ve never tried using assembly code in Xojo, I didn’t know you could. As for pointer arithmetic, there is something about it… I just don’t know enough (yet) but accessing one low level API came with a bunch of gotchya’s and warnings and suggestion that the solution is likely to change in the near future to improve security.
It’s hard for me to square the notion of memory safety - which must be enforced by a framework somewhere - and allowing inline assembly. Not my area of expertise but it just seems like the assembly could be sneaking around behind the framework’s back and causing all sorts of mischief. Thoughts?
This thread is about memory safe programming languages and expanded to a list of things we were discussing after the White House call, kind of “banning” C and C++. Some facts has risen about the subject pointing for solutions (a market oriented one, looking for a global one), but none reaching Xojo or Swift.
Such solution needs to cover what C covers today. It needs to be a system programming language.
And system languages need to provide low level access, and the lowest level all them reach is allowing mixing native CPU code, and yes, when people decide touching the bits they are aware that they need to press the button “unsafe mode on here in this part, please”. Without that, hardly a language can be called a system language. It’s not just a language able do call low level APIs of some OS, it must be a language able to write the entire OS, its drivers, touching CPU, GPU, UART, controllers, all sorts of hardware bits.
All our OSes are currently written using the universal now-declared enemy, “C” + CPU inlined ASM. At least their kernel are.
The White House call will affect all those vendors / providers that are the base of ALL software.
The options are already on course, none for a short term, none involves Swift.
Xojo is a high-level language, and will go with the market, once you see MySQL, PostgreSQL, SQlite, ICU etc rewritten in the market/experts blessed one, Xojo will need to follow.
My point is, we are far from the point of not using C. This call won’t be effective in less than a decade if declared urgent.
I’ll be honest, I’ve not studied this much. I also don’t know enough about Xojo’s framework as I’ve never seen the code, I’ve been able to determine some things from my experience with Apple’s frameworks, but not this kind of low level stuff.
We don’t know if any government has tested Xojo for memory safety, I’d assume that had the US government tested it and found it “memory-safe”, we’d know about it.
At this point Xojo isn’t on the list, can they get on this list, I’m 100% they can, is it feasible for their target audience? I don’t know. I suspect that larger companies are going to be paying attention to this list, but again, I don’t think we’re talking about the kind of companies who’d invest in Xojo.
The list from the White House carriers no legal weight, so I wouldn’t worry about it too much. The software industry has already been moving in the direction of better security practices at all levels for a long time now - market pressures are already driving change and will be more effective than press releases.
I think the idea is that if we reduce the amount of low level stuff as much as possible then that which remains and is necessary will be widely used and therefore widely tested becoming more and more secure with time. As long as each new program isn’t adding more problems by being written with bad practices that things will improve. And this is almost certainly correct.
It is absolutely possible to write demonstrably memory safe code in C and anything else assuming the underlying libraries are clean. The standard C libraries are very mature at this point, but you have to use them properly. it’s harder to do and without a lot of review and knowledge, any miscalculations or oversights that creep in can render all the other work pointless. It’s just easier when the language enforces that.
Its I think often mentally thing and change of thinking that is needed.
C and C++ and their libraries as you say are very mature, however what I see in all sorts of libraries are function variants used from those libraries which are deprecated because their less safe. And this is often because library maintainers want to keep compatibility preferably to the day when their grandmother was born, meaning the new safer routines often are not getting used.
I see such warnings all the time in most libraries. So what I am saying is it would go a long way for code security to just let go of the past and update to the newer routines in the standard libraries.
