My Concern With Rust, or a Case for the BSD's

July 5th, 2024: After reviewing some comments about this article, I needed to fix some inaccuracies and provide clarifications to properly connect the ideas.  Thanks to everyone for the feedback! Hopefully the recent edits help.

If I was to boil down my concern to one word, I would say: crates. Why? That is what I aim to answer here.

Crates

Rust is considered a "safe" systems programming language. If you've ever worked with Rust, then you know that utilizing one single library in a project will cause an avalanche of dependencies being downloaded to your system from across the Internet. What are these libraries and dependencies? These dependencies are, what the Rust world calls, "crates." However, what exactly is a "crate?" From the Rust documentation:

"A Rust crate is either a library or an executable program, referred to as either a library crate or a binary crate, respectively."

I had misunderstood this sentence initially to mean that a crate is either a collection of code or a blob of precompiled code. However, I've learned to better understand this to mean the source code within the crate is destined to either become a library file or an executable file.  Continuing in the documentation, another definition is given:

"Every target defined for a Cargo package is a crate."

I believe that "target" here is referring to a compilation target, such as 64bit Linux, or macOS. We might extrapolate that these collections of code are considered to be a "package" (as in, a unit of delivery) for the "Cargo" system. Cargo is a program to retrieve crates/packages. A crate "may also refer to a compressed package fetched from a registry."

Source of Crates

So where does someone get a crate? Who is creating these crates?

A crate comes from a registry. The Rust docs define a registry as "a service that contains a collection of downloadable crates that can be installed or used as dependencies for a package," and that the "default registry in the Rust ecosystem is crates.io."

So unless you have setup your own crate registry, or you have configured your Rust installation to utilize a custom one, you are going to be getting your crates from crates.io.

Who contributes to crates.io? Well, you can log into crates.io using a GitHub account. Interesting to note, Microsoft owns GitHub. So the they are essentially the gate keeper. Or rather, "custodian" as has been said in a somewhat different context. Anyone should be able to submit a crate, given that you can obtain access to the site via GitHub.

Security

Is crates.io secure? Although "[s]afety is one of the core principles of Rust," the crates.io Usage Policy doesn't seem to give any guarantees. But, they "would like to ensure that cargo and crates.io have secure implementations." The policy also explains that the "crates.io team and the Security Response working group are not responsible for the disclosure of vulnerabilities to specific crates, and if any issues are found, you should seek guidance from the individual crate owners and their specific policies instead."

To answer the question is crates.io secure?, I would say, who knows. However, take a look at this forum response:

For the most part, caveat emptor applies,
and you need to be responsible for your own safety:

Anyone can publish a crate under a new name on crates.io
and AFAIK there is no mechanism to prevent typosquatting.

The only restriction on publishing a new version of a crate is
that it must be done by one of the crate owners. This is
protected via GitHub credentials, so a hijacking can only
occur if those credentials are compromised.

All published crate versions, however, are frozen. If you've
audited a particular version of a crate, you can rely on an
identical copy being delivered whenever you request that version.

It is this type of understanding that prompts the genesis of this article. The default Rust registry is akin to PyPI.org for Python and npmjs.org for npm/node.js. Both of which have had multiple instances of malicious packages flow through them, as reported here:

• 27 Malicious PyPI Packages with Thousands of Downloads Found Targeting IT Experts
• New Malicious PyPI Packages Caught Using Covert Side-Loading Tactics
• Watch Out: These PyPI Python Packages Can Drain Your Crypto Wallets
• Over 800 npm Packages Found with Discrepancies, 18 Exploit 'Manifest Confusion'
• Hackers Flood NPM with Bogus Packages Causing a DoS Attack

Has there been similar troubles within the Rust ecosphere? Well...check this out. And don't forget the recent XZ situation, where a possible state actor is a normal committer for a long time, but then they aren't.

Imagine that the majority of the population believes that Rust is safe & secure. Then imagine that one or more commonly trusted dependencies is infiltrated, similar to the XZ situation, or maybe some other curious string of events. Then imagine that large organizations with a wide distribution of their software incorporates the malicious dependencies.

You never know, but it's good to consider these situations, should they arrive and cause massive problems.

BSD

So what does any of this have to do with any BSD operating system? Let me explain the connection.  This is not a comparison of Rust vs. BSD operating systems.  This is highlighting a concern about the supply chain, and providing contrast by giving the example of a powerful piece of software with a very different supply chain.

In this example, I just want to mention the base install of OpenBSD. Here are some tools that come out of the box, approved by the operating system maintainers:

• pf - Simple syntax firewall
• httpd - Simple syntax HTTP server
• smtpd - Simple syntax SMTP server
• relayd - Simple syntax proxy server
• vi - editor
• tmux - terminal multiplexer
• acme-client - for SSL certificates
• unbound - DNS server
• bgpd - Routing daemon
• dhcpd - DHCP server

As you can see, the vetted base installation of OpenBSD already provides many tools that require no additional dependencies to be installed. You install the operating system, and you get a platform that can route, proxy, serve up web/dns/routes/addresses, etc.

No, this doesn't provide a direct comparison to programming in Rust, however Rust is seen as a systems programming language that can construct similar tools that OpenBSD is already providing.

What qualifies code to reach the OpenBSD code base? Well, here are some excerpts from the openbsd.org website:

• "OpenBSD is thought of as the most secure UNIX-like operating system by many security professionals, as a result of the never-ending comprehensive source code audit."
• "OpenBSD is a full-featured UNIX-like operating system available in source and binary form at no charge."
• "OpenBSD integrates cutting-edge security technology suitable for building firewalls and private network services in a distributed environment."
• "OpenBSD attempts to minimize the need for customization and tweaking. For the vast majority of users, OpenBSD just works on their hardware for their application." (FAQ)

Plus, one of the goals of the platform, is to "Pay attention to security problems and fix them before anyone else does. (Try to be the #1 most secure operating system.)"

Conclusion

None of this proves anything, so it's all in the hands of the beholder. But this does allow me to highlight the concern I have had about Rust. I don't know that it is truly as safe as we assume it is. I am convinced that the borrow checker and the compiler rules do help with the internal consistency and security of a program. But the dependence on the largely anonymous crate registry must be considered.

Also, the glaring hole that is the crate registry also highlights a good reason to utilize powerful and flexible base installations of BSD operating systems. This doesn't mean that all BSD's are equal in their base install, but it provides food for thought.

Til we meet again.