Comment by vlovich123 | Hacker News Reader

Comment by vlovich123 | Hacker News Reader

Parent Full thread

The example with IEF doesn’t make sense. Whether you declare a function private or public doesn’t impact its usability as a gadget. And as I understand it reading up on IEF, the problem with removeDatabase is when it’s exposed as a remotely callable API without any auth check which is a very different problem. Am I misunderstanding what the author is saying?

I think the main problem with the article referenced in the submission is that percentages of vulnerabilities change based on the problem domain. The main threat for web facing services isn’t memory safety but that’s because most web facing services already use memory safe languages like JS, Java/JVM, Python, Ruby, or Go. It’s weird to pick Rust for its memory safety for web services. The reason to pick Rust is because you get C/C++ like performance without the memory safety issues. If you don’t need the perf, all the other languages are better choices because you’ll probably move quicker.

It’s interesting that 20% are still memory vulnerabilities. Assuming this is all the same class of attacks on web services, that means 20% of applications do care about perf and have exploitable memory safety issues. Or the methodology is shoddy and they’re comparing different classes of software. Regardless, the premise of the first article is flawed and rife with statistical analysis problems that paint a misleading picture while the response isn’t infusing me with a lot of confidence on the merits and comes off as unnecessarily fanboish trying to stretch for a reason of “but no rust still makes sense”. 70% of vulnerabilities in Chrome are memory safety. This holds for similar classes of software written in c/C++ (eg Windows). There’s a reason all major c/c++ codebases have started getting grass roots and organizational support to transition away as quickly as possible.

The second example given (extracting information from a web view) is also weird. The rust code has the exact same flaw as the java code, which is that they do not validate the source. I think the author didn't really understand the underlying problem here. Bounds checking was not the issue with the java (android) code

I hate to impune their skills since I don’t know the person and this could just have been a hastily written and poorly thought through article, but for me it brings into question their claims as a cyber security expert with 10 years experience.

Rust has other advantages as well. For example, a common error when something goes wrong in Python is that a 'None' value ends up somewhere where it shouldn't be. Typically this None has traveled quite a while before some code tried to use it.

The richer and stricter type system of Rust makes such errors a lot less likely. And if an error escapes, there usually is a way better indication of the origin of the error than just 'None'.

Most of those Rust features over Python, that are commonly referred to, are available in any programming language of ML linage.

Caml Light, SML, OCaml, Haskell, F#, Scala, and whatever else is out there.

Most of them also come with a REPL, and have multiple toolchains, no need for always be waiting for the compiler.

It is very nice that those languages have those features. But it is quite rare that people who are used to C or Python code bases are switching to those languages.

In particular a strong point of Rust is that C programmers feel comfortable switching to Rust in way that has not happened with other safe languages.

I disagree.

It's much more common to go from C to Python, Go or even Zig, rather than Rust.

I think the C++ to Rust transition is by far the most common one.

> In particular a strong point of Rust is that C programmers feel comfortable switching to Rust in way that has not happened with other safe languages.

I don't see this at all. C++ programmers might be switching, but C programmers aren't reaching for Rust when they need something better than C.

C folks hardly change to anything, at least the hardcore ones, unless forced to by external forces.

Python well, it isn't as if Rust is on the same level of developer experience and friendliness.

With CPython finally getting a JIT, and Mojo, I don't force that happening long term.

In any case, hardly changes the fact of not being Rust specific type system features not available anywhere else.

There is a huge amount of C programs and libraries that were written in C because back then it was the best tool for the job. A lot of people are not convinced about C++, but for many things that were written in C, Rust is now a good option. More and more people are asking questions about how C programs avoid memory errors. The easy solution is to switch to Rust for new programs and libraries.

Python has the problem that large Python programs are often awkward. There are many reasons for that. And somehow the Python community doesn't seem to be able to solve those issues. Rust is a lot better in that respect.

Many of those random userspace C programs (i.e. stuff in the (1) manpage section) could have been rewritten in e.g. OCaml just fine ages ago, if only people were paying attention and not in the curly brace mind prison.

Ergonomic advantages / reduced defect rates != vulnerability issues. The former aren’t a problem for languages like JS which has all sorts of weird sharp edges. But vulnerabilities are treated as a separate risk factor because the issues can spill to unexpected areas which makes risk harder to quantify and reason about. A vulnerability in some small tool that barely anyone uses can be used to exfil your entire customer database or do a ransomeare attack and cost you hundreds of millions of dollars in short term damage + investigations by regulatory bodies and law enforcement. A buggy piece of software at worst causes some bad PR or a failed product which is way way smaller and localized of an issue

Some classical programming languages that don't suffer from buffer overflow or memory allocation issues, but are horribly unsafe due to type (and other issues) are shell scripts and, at least, early versions of php.

Weak type checking at interface boundaries allows for all kinds of errors including vulnerabilities.

A famous class of vulnerabilities due to poor type checking is SQL injection.

SQL injection happens on any language where people decide string concatenation is better than using precompiled query parameters exposed by database drivers APIs.

Using Rust doesn't change how those folks keep concatenating strings.

> The reason to pick Rust is because you get C/C++ like performance without the memory safety issues. If you don’t need the perf, all the other languages are better choices because you’ll probably move quicker.

Lets not forget a competent type system as well. Go/Java are decent, but i'd not even consider dynamic langs these days for any remotely complex project. I just don't believe in the benefits of a dynamic system.

I use Rust in areas that otherwise don't require it in part because i prefer the type system.

Reply on news.ycombinator.com