Another day, another critical vulnerability due to an out of bounds write that could never have occurred in Rust

https://github.com/openssl/openssl/...

"Just write correct code, what's the problem"

the fix is a single byte added to a file. Sounds easy af. But the amount of work done to come up with that fix must've been a lot more significant.

Sadly, no one sees that part of the story.

Yeah, in Rust, OpenSSL wouldn't even exist, considering that the initial release of OpenSSL was in 1998.

So when is the Rust rewrite expected to launch? It's just 750k LOC, mostly C (520k) and Perl (220k): https://openhub.net/p/openssl/...

@Fast-Nop Whenever the current contributors realize that only software that never interacts with untrusted important data of any kind and whose integrity, timeliness and uptime aren't important can be written in C.

Until then we can expect about 2 critical off-by-one vulns per year.

@lorentz Ah, when they "realise" it. That's all it takes. Nice to hear, so let's see whether we get the rewrite let's say by end of next year. Just about when the full Linux kernel rewrite should arrive.

Btw., in the meantime, Rust might want to address the nonsense it does with static linkage of cargo crap from all over the internet. That's convenient for devs, but a nightmare for package maintainers.

And I somehow doubt that devs who went for convenience in the first place will diligently track all of the security issues in all of the dependencies that they bake into their applications.

Also, a proper ISO standard would be nice instead of "Rust is whatever the only Rust compiler around happens to do."

@kaki Oh, so that means the devs will just ship their applications everytime the package manager tells there is an issue?

They will also happily either backport patches or update their applications to match incompatible new versions of dependencies?

They will not use version pinning in cargo to get around the usual breaking dependency issue?

So, devs who went for convenience will be willing to also take over the traditional duties of a maintainer on top of that?

Is that what you're thinking? If so, I'd call you an optimist. That part of Rust originated in a web company, and that bad influence is now irrevocable.

When was the last time language guys thought they were clever and wrote cryptography ...

https://theregister.com/2022/04/...

Oh yeah. JDK.

Rewriting crypto is almost always ending up with severe bugs and oversight.

Please. For the love of god. Rust doesn't fix things magically. Nor does rewriting stuff to Rust.

Cryptography is I think one of the hardest, most fucked up things that noone wants to touch for reasons.

Many Linux distributions offered libressl after the heartbleed bug and then changed back in the last years to openssl.

Anything that touches cryptography is usually OpenSSL. GnuTLS / NSS can partially replace OpenSSL, but even in OpenSSL 3 where a lot of craft was removed are still additional things...

If you wanna know how **painful** it is to change a cryptography provider, look upstream in the distributions.

You have to severely invest in *any* program having an TLS stack.

Not just your cryptography provider.

https://boringssl.googlesource.com/...

If you wanna know how fun it is ... And boringSSL is "close" to the OpenSSL API.

@Fast-Nop

1. The lack of an ISO standard is a problem, but Rust does have a standard, it just isn't maintained by the ISO and it only has one implementation.

2. I'm fairly certain that major software vendors would absolutely keep track of vulns for their dependency trees. There are established notification channels for most software, and those which don't have an official vulnerability channel should not be dependencies to a major project.

3. C code generation is usable right now, and it means that a project on the scale of OpenSSL could be gradually rewritten, file by file.

@IntrusionCM Yes, security software is difficult and using something other than OpenSSL is risky, but as today's example shows, using OpenSSL is risky as well. I still think that we need to pay the upfront finite cost of replacing our tools with ones that provide something resembling safety in order to save us the unbounded cost of vulnerabilities currently dormant as well as new ones introduced in the future.

@lorentz A "standard" isn't ISO and has one implementation is... not a standard.

Yeah sure, the package maintainers will happily take over all the work that the devs eschewed with recursive dependencies and static linkage.

Oh, it "could" be rewritten. Nice. Let's see whether Rustaceans are as good at rewriting as at evangelising Rust. Especially given that the widespread use of OpenSSL has never resulted in massive funding.

@lorentz it's not (only) about "risky" regarding OpenSSL replacement.

Anything uses TLS nowadays.

If you wanna find out what:

https://packages.gentoo.org/package...

Gentoo has a nifty tool for that.

You will need to support every program adaption - no one will migrate just because it is written in Rust, or safer.

@IntrusionCM If a rewrite indeed used Rust's C code generation, the public interface could trivially be defined in C while the actual work could be done safely in Rust, and thus ABI compatibility could be maintained. This would be especially useful because OpenSSL supports a lot of platforms LLVM doesn't, but I suppose the generated C would have no problem with that.

Edit: On Rust's native platforms, the Rust code could of course be directly shipped as a crate to avoid the double translation.

Mmmm, the smell of old C code... They even added 1 to the variable so many times on the lines above.

@lorentz

https://neosmart.net/blog/2022/...

The blog is interesting read and I think a good point why rewriting in Rust is in theory a nice idea, but practically impossible task for most C code that thrives on the borderline between vodoo and sane insanity.

You cannot just plop in Rust.

Borrowing, safety etc. require rethinking and redesigning core elements of APIs.

Most APIs will have to be trashed completely as you cannot just refactor it in the same way.

You will end up with a rewrite, with a complete different API and ABI.

Maybe not even keep the naming as it would be completely confusing - same name, but different behaviour and requirements and API… That sounds like nightmare.

@IntrusionCM Someone, somewhere, will trust an AI to do the rewrite. It will be touted as a great achievement. Until it results in multi trillion dollar losses.

@IntrusionCM The article inflates trivialities of API design. You can absolutely just plop Rust in a codebase, and it will instantly help you discover bugs. The kind of ergonomics their semaphore provides can then be added gradually, and the unergonomic C-style APIs removed only once every piece of user code has been updated. A basic semaphore is literally just those two functions.

The introduction of the article talks several screenfuls about how we can use const generics at a cost. The solution with const generics has no cost. Using const generics is an explicit statement that you want to prevent defining the value at runtime. That's the point.

The following several screenfuls talk about how release is problematic because it's unsafe, but also it can't be removed because it's used in exactly the way that is unsafe? Either call it a problem or call it a use case.

The final solution is fine, but it would've been my first solution if the requirements were clearly stated.

In conclusion, the problem the author is solving isn't that Rust can't do something they want to do, rather the article describes the process of deciding what kind of API they actually want to write, and then immediately expressing every new constraint perfectly in Rust with no tradeoffs apart from those which logically follow from the specified constraints themselves.

Oh yeah, and I almost forgot the part where they agonize for like five paragraphs about how you can't have a non-binary semaphore that provides write access while maintaining the policy of one writer XOR n readers. The entire article is literally about the author's fierce battle with basic everyday logic.

@IntrusionCM To clarify, I don't mean that you can plop Rust in a C codebase. I mean that you can rephrase any API, no matter how dumb, in Rust, and only panic once the user's instructions are guaranteed to lead to UB (or just keep going and hope some platform peculiarities save you).

It will be shit Rust, but it will still be mostly safe code with a few unsafe blocks, which is already a vast improvement over shit C which is essentially an entire project in an unsafe block.

Can you install a rust app system wide yet? Coz last time I looked, the advice was "don't do that". But hey, not like I might wanna use some stuff in sudo without having to install it twice...

@atheist It's a statically linked binary. You install it globally by putting it in /usr/bin

@atheist You can package stuff for system-wide installation. It's not up to the language. The advice was and still is not to install libraries globally because each project you're working on should be able to have its own dependency versions.

@lorentz last time I looked, this wasn't supported by the built in tools, and was advised against. You're right, it's not up to the language, it's up to the toolchain, but for rust, they're kinda one in the same.

@atheist What wasn't supported by the toolchain? An executable rust project compiles to a standalone binary. Where that binary is and how it's executed is entirely up to the conventions of the operating system distribution.

@atheist Some languages and runtimes such as NPM, Pip, Rubygems, Cabal and Stack try to include package management support for executables, but the more popular approach also taken by Rust is to only manage libraries for projects you're building locally and rely on the platform's dependency manager for distributing executables.

This makes sense because a binary may be a dependency of other packages written in other languages (this is what sets it apart from a crate), so assuming that the dependent will use Cargo defeats the purpose of building an executable.

I get what you're saying, but of the times I've wanted to use something that was written in rust, it wasn't available in the system package manager. The install instructions were install rust (but not the version in apt for reasons), build and run. Then the default for most packages is to install rust and build per user.

Also, given the popularity of C++ through sheer legacy, I really don't believe the whole "more popular" line.

Rust is pitched as a system programming language, but its build system doesn't support system installs. The vast majority (all?) C/C++ build systems do support it. I think that's bad user experience.

The thing that's "not supported" is the equivalent of make install. You've got to read documentation to work out system installs aren't recommended, but according to you might work (if you're saying it's a static object). But I code in 10+ languages, I don't have the time to learn the intricacies of each language.

@atheist Noted, I might try myself at packaging for various Linux distros by writing a utility that takes care of all this and ships for popular distros. I don't expect this to be a difficult task but I agree that the absence of a semi-official tool is a stupid shortcoming.

Most software tends to be on the AUR, maybe that's because Arch's approach to package management is very similar to Rust's so it's very easy to package stuff.