To the people that like to make the argument that it’s the developers’ individual responsibility to regularly check their dependencies and transient dependencies…
… explain to me how many hours per month you dedicate to this task yourself. Now go look at this list. This isn’t even “code”, it’s a utility.
Tell me again how “this is fine”.
Large standard libraries exist for a reason, and this is it: so that we can have one dependency instead of thousands. So that reviewing non-standard dependencies is tractable. So that upgrades don’t break because of NP-complex rules violations even computers can’t resolve let alone humans.
This isn’t a great article, tbh. Most of the complexity is from compiling the Rust compiler (and its “large standard library”) from source. Of course that’s going to be a complicated affair, because a production-quality compiler is not a simple bit of code. Normally this would just be a binary package, but it looks like MacPorts didn’t have said package for the author’s platform at the time.
Second, the upgrade didn’t fail at all. The author has misinterpreted the log. This is understandable given the wording (“Unable to uninstall…Uninstall forced”), but all it’s saying is that it is forcibly uninstalling a package that’s being depended on, because the depending package is also being upgraded. The upgrade process completes fully, despite taking a very long time.
I would agree with you had I (the author) intentionally wanted to install Rust, but I didn’t. This was a Python dependency randomly bringing all of Rust along with it and that is insane no matter how you slice it.
My real-world example of this is that the ASP.NET Session State module for SQL Server pulls in basically half of the Azure client libraries… in case you’re using Azure SQL with Azure Entra identity authentication.
Don’t use those things? Tough! Your 500 kB web app now has 500 MB of dependencies shovelled into it whether you like it or not.
But this was only necessary because the binary packages for py310-cryptography did not exist on MacPorts for your platform at the time you did the upgrade. MacPorts therefore had to build from source, and that necessitates installing the compiler. Nowadays, with the appropriate binary package on macports.org, installing the Rust compiler should no longer be necessary. For example, I have successfully installed the py310-cryptography module just now off of MacPorts without rust being installed. Rust binary packages intentionally do not rely on a language runtime (only libc), whereas Rust source packages will naturally need to rely on the Rust compiler.
Building from source is always going to be more painful than installing a binary package; I have packages in MacPorts that can take hours to build from source (binaries not available, usually due to using an uncommon mix of feature flags). It's misleading to suggest, however, that the little package you installed carries 393 dependencies, when those are the dependencies of the compiler rather than the package itself.
I think we agree that MacPorts is doing the best it can here.
In my view[1], the issue is a package in one language introducing a dependency on an entirely different, uncommon, language runtime and toolchain. Until relatively recently (at least with respect to the post), the cryptography package did not require Rust at all. A secondary issue is the amount of dependencies actually involved in building a cryptography package. How many of those dependencies are compiler dependencies or not is not relevant to my mind; the cryptography package still transitively depends on them by way of the compiler (and by way of the package manager) and any one of those dependencies could probably read my SSH keys or do $deity knows what else to my computer.
[1]: I agree this isn't particularly well expressed by the post, nor perhaps by these comments here, but now I have to run get a haircut!
To be completely clear: most of the long install process and crazy list of crate dependencies is due to building the Rust compiler toolchain and Cargo tool from source, which MacPorts does when it cannot find corresponding binary packages. As far as I can tell, MacPorts is now shipping binary packages for the latest version of Rust (https://packages.macports.org/rust/), so this issue probably won’t crop up for most users. It’s likely that a package for the latest Rust wasn’t available at the time the post was made (or in any case, not for Darwin 22 on ARM64).
Is there a C replacement language that's lightweight and provides just enough guardrails to avoid buffer overflows? Or some sort of static analysis on top of modern C++ that can give you Rust-like safety?
People have been developing “safer” C/C++ extensions for literally decades. Very few of them have caught on, and those that did are usually in niche applications. Rust is the best shot at a safe C/C++ replacement language.
Buffer overflows should be relatively easy to avoid in modern code, but some C programmers insist on doing handrolled calculations for buffer sizes that wind up being wrong (the WebP vuln was a great example of this), and not having buffer length checks because they assume their calculations are right (it’s faster!).
But buffer overflows are a small part of the vulnerability space. For instance, memory allocation bugs, like double free/use-after-free are much more insidious with large codebases, and harder to detect due to problems like unclear or undocumented ownership. C doesn’t provide any mechanism for communicating ownership or lifetime information for all but the simplest objects, leaving this up to the programmer to manage.
A kludgy as very long shell scripts are (thought to be), I probably have a better chance of being able to go through all the that code and understand it than a dozen(+) Python libraries. And if there's an update/s, a diff of one shell script easier to parse than multiple libraries that may be updated.
I ran into this on FreeBSD when cryptography started using a rust core for its work. Suddenly my jails needed a full rust build environment just to install this one package. It was a frustrating day.
Every time I upgrade that jail/venv I cry a little inside.
… explain to me how many hours per month you dedicate to this task yourself. Now go look at this list. This isn’t even “code”, it’s a utility.
Tell me again how “this is fine”.
Large standard libraries exist for a reason, and this is it: so that we can have one dependency instead of thousands. So that reviewing non-standard dependencies is tractable. So that upgrades don’t break because of NP-complex rules violations even computers can’t resolve let alone humans.