#rust adherents are deluded in believing the idea that merely memory access violations are the only kind of way in which the security of software is breached

firstly, this only applies to binary code running on physical or virtualized hardware, where a kernel is managing access to memory - it isn't relevant to such runtime environments like WASM or JVM because they already have automatic access controls and generally are not targeted by languages that have pointer arithmetic

secondly, more often the problem comes from poorly constructed access control systems, where simplicity of the code is the key thing to enabling the developers to notice that there is a problem and prevent the code running in the wild to be exploited by hackers looking to breach potentially valuable user data

thus, the more complex and circuitous the language syntax is, the more ways in which it can be made completely idiosyncratic by the use of macro programming, the harder it is to learn the language, ie, the more complex the syntax, the more ways in which errors in ACL systems can be introduced and lead to methods to bypass the ACL and/or privilege escalate to enable read/write access to data that is supposed to be privileged

and lastly, a hard to understand, and difficult to learn memory management system, that prevents the aforementioned buffer overflow attacks, creates a false sense of security for those who make decisions about what language to implement a system with

most of the shitcoins now run smart contracts written in rust, and unless i'm mistaken, the frequency of breaches and hacks has not changed one iota

#fuckrust

Reply to this note

Please Login to reply.

Discussion

The only way to avoid bugs is to be a good programmer, and for that, the language doesn't matter.

Being said that, I must admit that pure functional languages are just much better at forcing the programmer to write good code.

functional languages achieve much of this at the expense of massive amounts of memory copying, and if you add concurrency to the features, because there is good reasons to, you wind up with a problem that most of the time you should be using pointers and mutexes

and this doubly applies to the compiler itself, as with most languages, the compiler is written in the language itself, via a "bootstrap" method, i have seen haskell compilations OOM kill almost as often as i've seen badly written C++

compilation requires the use of massive tree structures and this combined with a pass by value policy leads to a LOT of garbage

and no, being a good programmer is only part of the story... if we were talking about carpentry, would you agree that frilly decorative crochet pieces around the tools are going to not impede with the work at hand?

that's how i see most of the languages...

i read python, so much repetition, such a poor visual impact of the general pattern of syntax

java, so many ridiculously long names and multi-hop paths due to the OOP... and C++ and javascript both also suffer from this extremely noisy visual aspect

in Go, you can often spot a bug just by that first momentary glance by the shape of the code

it is often tempting to forget to obey one of the first laws of go: fail fast - handle the error case before you handle success, and it always bites you on the arse, and this is an example of something that can be recognised instantly at a glance by the underscore where the programmer is pretending teh error case does not matter

it almost always matters, except in a few rare cases like running out of entropy

and yes, there is several critical parts of the Go standard library that push noisy, stuttering things on you like the context library, which is used to enable clean shutdown and timeouts of threads... not saying it's perfect, just that if you follow the rules in your code you less often have to go back and debug later on when things start going wrong

You probably haven't used much Clojure, Scala or Haskell (and Lisp, but this is dynamic), they use pointers internally for everything, while you have the impression they don't. And they are very well optimized. So it is not massive copying, it's just a bit, combined with pointer magic.

> and no, being a good programmer is only part of the story... if we were talking about carpentry, would you agree that frilly decorative crochet pieces around the tools are going to not impede with the work at hand?

Nice comparition, but I would rather compare C to a knife and Haskell to a full featured programmable electric saw. You can do the same with both, but with the knife you have to do it by hand, while with the electric saw you just have to introduce the parameters.

About Java, it's not the language itself the good part, but the JVM, or at least it was at my time, probably it is no longer the case.

Python is for doing 100 to 1000 lines scripts, I wouldn't make a full application on it.

And Go, I have no idea, I'm very old and I retired before it went mainstream.

well, i just like to point out that the three main guys that invented it are some of the most influential guys in computer programming... the co-inventor of C, the Newsqueak and Plan 9 OS guy, and the guy who built the javascript engine used in Chrome

and of course the functional languages have to use pointers but the inordinate size of memory usage during compilation hints at an incredible amount of memory utilization that just doesn't plague Go builds at all, in fact, a full application that was comparable to Bitcoin Core (with GUI and miner built in) that I worked on, compiled in under 20 seconds given all deps were cached, and you wait half an hour for bitcoin core, and i've built Simplex from source, that is also a 10-15 minute exercise and will blow up on a system with no swap and only 16gb memory

i do hope you still write a bit of code from time to time, i can never imagine ever quitting this, i've loved it from the moment i first saw a commodore 64 BASIC program printing some silly nonsense on a display at a shop, can't keep my fingers to myself lol

Well, you know, Bitcoin is quitter for everyone. Once you have enough to live out of it, all what is left is making memes on social media. 😏

It's been near 10 years without programming, and every day that passes it's becoming harder and harder.

yeah, i don't ever want to stop

i still have a hundred problems to solve and i won't sleep until i'm dead

The JVM has the String pool. An area of memory which is NEVER garbage collected. It only cleans itself on heap dump or application restarts. Unless you are encrypting client-side, your PII and credentials are stored in plain text in memory. #NoMoreJava

that sounds like a nightmare... but in android runtimes it is one memory map per app right?

That gets a little complicated. The short answer is yes, but the are not any security measures preventing heap dumps from memory access violations. If your application is on the device, it can cause a dump and grab the info from it.

does this require an exploit in the app itself or is this an exploit in linux LXC namespaces?

Neither. This is a weakness in how the JVM responds to invalid memory access. While there are some security issues existing in the LXC namespace, they do not correlated with this issue.