Mitigating Memory Safety Issues in Open Source Software

For me cargo, rust-analyzer, and lifetimes/borrow checker just makes programming so much more pleasant.

edit: I dont go overboard on the more advanced features in the rust language, and probably write more C idiomatic code sometimes, but I still prefer using rust over C

As a security library... you really ought to be updating it every half year of so.

This has nothing to do with rust though. Rust maintains full backwards compatibility, so even if you upgrade the compiler (which is unlikely on long lived platforms) and not the library nothing breaks.

Nor is it necessarily the case that upgrading the library will require updating rust (though this isn't what you appear to be complaining about). Not only is it a build time dependency (that you don't even need to install if you are on common platforms which ave prebuilt binaries), but they are explicitly testing against a particular fixed old version of rust as well as recent ones: https://github.com/pyca/cryptography/blob/main/.github/workf...

> I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so.

This describes every version of rust since 1.0. Rust is fully backwards compatible, unlike new C standards.

> Do we have anyone committed to providing a stable rust environment for these cases?

Yes, the entire rust team...

> Especially considering that rust has no ABI for dynamic libraries.

This is... rather irrelevant? Technically it does have support for the C abi for dynamic libraries though.

But not in a memory unsafe language, please. There's hype and there are lies: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

But my point of view is quite biased. I am still baffled that people would start new projects in C instead of just using a strict subset of C++, at least: classes, only trivial templates for generics, references, maybe smart pointers depending on what you're doing, but no STL, no exceptions, no inheritance, etc.

The fact that rustc is backwards compatible is great, sure. But it does not solve the problem of distributors.

Say you have libfoo-1.0 that uses rust and cargo 1.2 . A distributor that now releases their linux version and wants to ship libfoo-1.0 must consider the requirements for supporting it. This support usually outlives the upstream support.

If libfoo-1.0 uses C, for instance, it is highly likely that a distributor can backport any security-relevant changes from libfoo-1.1, 1.2, and later into 1.0.

In the case of rust there are two uncertainties creeping in: One is the highly dynamic nature of cargo dependencies. libfoo might depend on a myriad of crates transitively and rust simply is too young to provide any experience in how long they will be available or supported. And no, it is generally not a good idea to update to new feature releases for security updates. This is something that stable distributions explicitly try to avoid.

So our distributor now must consider if changes in libfoo-1.2 pulled in changes via cargo that cannot be easily backported because they are feature releases or have a dependency on a newer version of rust.

The second problem is the compiler itself. Any change in libfoo-1.2 might require a newer version of rust. It is great that they want to be backwards compatible but now our distributor must consider upgrading a substantial piece of software during the support period (and testing the backwards compatibility, of course) just to backport a security fix.

Please don't get me wrong, I really like rust and I think these problems can be solved. But I also like stable software and all these languages with their package repositories seem to simply ignore everything that's older than one or two years. If rust wants to become a new C, which I would very much like, it needs to demonstrate a certain stability.