I’ve gotten back into tinkering on a little Rust game project, it has about a dozen dependencies on various math and gamedev libraries. When I go to build (just like with npm in my JavaScript projects) cargo needs to download and build just over 200 projects. 3 of them build and run “install scripts” which are just also rust programs. I know this because my anti-virus flagged each of them and I had to allow them through so my little roguelike would build.
Like, what are we even suppose to tell “normal people” about security? “Yeah, don’t download files from people you don’t trust and never run executables from the web. How do I install this programming utility? Blindly run code from over 300 people and hope none of them wanted to sneak something malicious in there.”
I don’t want to go back to the days of hand chisling every routine into bare silicon by hand, but i feel l like there must be a better system we just haven’t devised yet.
Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.
Which is why you shouldn’t do that. Dependency nightmare is a real problem many developers face. More to the point they impose it on you as well if you are by any reason forced to use their software. Well established libraries are gateway to this. People are getting out of their way to complicate lives to themselves and massive amount of others just so they could avoid writing a function or two. Biggest absurdity I like to point out to people is the existence of is-number NPM package, which does that. It has 2300 dependent projects on it!!! Manifest file for said package is bigger than the source. And the author had the hubris to “release it under MIT”. How can you claim copyright on num - num === 0?
On all the projects I manage I don’t allow new dependencies unless they are absolutely needed and can’t be easily re-implemented. And even then they’d have to be already in the Debian respository since it’s a good and easy way to ensure quick fixes and patching should it be needed. Sometimes alternative to what we wanted to use already is in repo, then we implement using different approach. We only have few Python modules that are not available in repo.
Managing project complexity is a hard thing and dependencies especially have a nasty habit of creeping up. I might be too rigid or old-school or whatever you want to call it, but hey at least we didn’t get our SSH keys stolen by NPM package.
I do not get why people don’t learn from Node/NPM: If your language has no exhaustive standard library the community ends up reinventing the wheel and each real world program has hundreds of dependencies (or thousands).
Instead of throwing new features at Rust the maintainers should focus on growing a trusted standard library and improve tooling, but that is less fun I assume.
Easily, just look at the standard libraries of Java/Python and Golang! :-P
To get one thing out of the way: Each standard library has dark corners with bad APIs and outdated modules. IMHO it is a tradeoff, and from my experience even a bad standard library works better than everyone reinvents their small module. If you want to compare it to human languages: Having no standard library is like agreeing on the English grammar, but everyone mostly makes up their own words, which makes communication challenging.
My examples of missing items from the Rust standard library (correct me, if I am wrong, not a Rust user for many reasons):
Cross platform GUI library (see SWING/Tk)
Enough bits to create a server
Full set of data structures and algorithms
Full set of serialization format processing XML/JSON/YAML/CVS/INI files
HTTP(S) server for production with support for letsencrypt etc.
Things I don’t know about if they are provided by a Rust standard library:
Go like communication channels
High level parallelism constructs (like Tokyo etc.)
My point is, to provide good enough defaults in a standard library which everybody knows/are well documented and taught. If someone has special needs, they always can come up with a library. Further, if something in the standard library gets obsolete, it can easily be deprecated.
Python doesn’t have a production web server in its standard library. Neither does Java. Those are external programs or libraries. C# is the only language I know that comes with an official production grade server, and that’s still a separate package (IIS).
Golangs web server is production grade and used in production. (Of course everyone uses some high performance proxy like NGINX for serving static pages, that’s another story.)
Technically you are right that java has no production web server, which I don’t like, OTOH Java has standard APIs WebServers and Spring is the defacto standard for web applications. (I totally would not mind to move Spring into the OpenJDK.)
My point is simple: Instead of having Rust edtion 2020, 2021 etc. and tweaking the syntax ad infinitum, I’d rather have a community which invests in a good/broad standard library and good tooling.
The only platform widely used in production w/o a big standard library is Node.js/JavaScript, mostly for historical reasons and look at the problems that Node.js has for a decade now because of the missing standard library.
It’s a really wicked problem to be sure. There is work underway in a bunch of places around different approaches to this; take a look at SBoM (software bill-of-materials) and reproducible builds. Doesn’t totally address the trust issue (the malicious xz releases had good gpg signatures from a trusted contributor), but makes it easier to spot binary tampering.
Shameless plug to the OSS Review Toolkit project (https://oss-review-toolkit.org/ort/) which analyze your package manager, build a dependency tree and generates a SBOM for you. It can also check for vulnerabilitiea with the help of VulnerableCode.
Do you really need to download new versions at every build? I thought it was common practice to use the oldest safe version of a dependency that offers the functionality you want. That way your project can run on less up to date systems.
Most softwares do not include detailed security fixes in the change log for people to check; and many of these security fixes are in dependencies, so it is unlikely to be documented by the software available to the end user.
So most of the time, the safest “oldest safe” version is just the latest version.
to tell “normal people” about security? “Yeah, don’t download files from people you don’t trust and never run executables from the web. How do I install this programming utility? Blindly run code from over 300 people and hope none of them wanted to sneak something malicious in there.”
You’re starting to come to an interesting realization about the state of ‘modern’ programming and the risks we saw coming 20 years ago.
I don’t want to go back to the days […]
You don’t need to trade convenience for safety, but having worked in OS Security I would recommend it.
Pulling in random stuff you haven’t validated should feel really uncomfortable as a professional.
I’ve gotten back into tinkering on a little Rust game project, it has about a dozen dependencies on various math and gamedev libraries. When I go to build (just like with npm in my JavaScript projects) cargo needs to download and build just over 200 projects. 3 of them build and run “install scripts” which are just also rust programs. I know this because my anti-virus flagged each of them and I had to allow them through so my little roguelike would build.
Like, what are we even suppose to tell “normal people” about security? “Yeah, don’t download files from people you don’t trust and never run executables from the web. How do I install this programming utility? Blindly run code from over 300 people and hope none of them wanted to sneak something malicious in there.”
I don’t want to go back to the days of hand chisling every routine into bare silicon by hand, but i feel l like there must be a better system we just haven’t devised yet.
Debian actually started to collect and maintain packages of the most important rust crates. You can use that as a source for cargo
https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
Yeah they messed up once. It’s still miles better than just not having someone looking at the included stuff
You’d think this would be common sense…
Not the enterprise stuff; just the beta mayflies.
Which is why you shouldn’t do that. Dependency nightmare is a real problem many developers face. More to the point they impose it on you as well if you are by any reason forced to use their software. Well established libraries are gateway to this. People are getting out of their way to complicate lives to themselves and massive amount of others just so they could avoid writing a function or two. Biggest absurdity I like to point out to people is the existence of
is-numberNPM package, which does that. It has 2300 dependent projects on it!!! Manifest file for said package is bigger than the source. And the author had the hubris to “release it under MIT”. How can you claim copyright onnum - num === 0?On all the projects I manage I don’t allow new dependencies unless they are absolutely needed and can’t be easily re-implemented. And even then they’d have to be already in the Debian respository since it’s a good and easy way to ensure quick fixes and patching should it be needed. Sometimes alternative to what we wanted to use already is in repo, then we implement using different approach. We only have few Python modules that are not available in repo.
Managing project complexity is a hard thing and dependencies especially have a nasty habit of creeping up. I might be too rigid or old-school or whatever you want to call it, but hey at least we didn’t get our SSH keys stolen by NPM package.
THIS.
I do not get why people don’t learn from Node/NPM: If your language has no exhaustive standard library the community ends up reinventing the wheel and each real world program has hundreds of dependencies (or thousands).
Instead of throwing new features at Rust the maintainers should focus on growing a trusted standard library and improve tooling, but that is less fun I assume.
I thought they already had decent tooling and standard libraries?
It does, but the person you reply to apparently expects a standard library to contain an ECS and a rendering engine.
Can you give some examples of things missing from Rust standard library?
Easily, just look at the standard libraries of Java/Python and Golang! :-P
To get one thing out of the way: Each standard library has dark corners with bad APIs and outdated modules. IMHO it is a tradeoff, and from my experience even a bad standard library works better than everyone reinvents their small module. If you want to compare it to human languages: Having no standard library is like agreeing on the English grammar, but everyone mostly makes up their own words, which makes communication challenging.
My examples of missing items from the Rust standard library (correct me, if I am wrong, not a Rust user for many reasons):
Things I don’t know about if they are provided by a Rust standard library:
My point is, to provide good enough defaults in a standard library which everybody knows/are well documented and taught. If someone has special needs, they always can come up with a library. Further, if something in the standard library gets obsolete, it can easily be deprecated.
Python doesn’t have a production web server in its standard library. Neither does Java. Those are external programs or libraries. C# is the only language I know that comes with an official production grade server, and that’s still a separate package (IIS).
Rust has a set of recommended data structures in their standard libraries too: https://doc.rust-lang.org/std/collections/index.html
I don’t know what algorithms you are looking for so can’t answer here.
The rest I don’t think are included in Rust. Then again they aren’t included in most languages standard libraries.
Golangs web server is production grade and used in production. (Of course everyone uses some high performance proxy like NGINX for serving static pages, that’s another story.)
Technically you are right that java has no production web server, which I don’t like, OTOH Java has standard APIs WebServers and Spring is the defacto standard for web applications. (I totally would not mind to move Spring into the OpenJDK.)
My point is simple: Instead of having Rust edtion 2020, 2021 etc. and tweaking the syntax ad infinitum, I’d rather have a community which invests in a good/broad standard library and good tooling.
The only platform widely used in production w/o a big standard library is Node.js/JavaScript, mostly for historical reasons and look at the problems that Node.js has for a decade now because of the missing standard library.
It’s a really wicked problem to be sure. There is work underway in a bunch of places around different approaches to this; take a look at SBoM (software bill-of-materials) and reproducible builds. Doesn’t totally address the trust issue (the malicious xz releases had good gpg signatures from a trusted contributor), but makes it easier to spot binary tampering.
+1
Shameless plug to the OSS Review Toolkit project (https://oss-review-toolkit.org/ort/) which analyze your package manager, build a dependency tree and generates a SBOM for you. It can also check for vulnerabilitiea with the help of VulnerableCode.
It is mainly aimed at OSS Compliance though.
(I am a contributor)
Do you really need to download new versions at every build? I thought it was common practice to use the oldest safe version of a dependency that offers the functionality you want. That way your project can run on less up to date systems.
Most softwares do not include detailed security fixes in the change log for people to check; and many of these security fixes are in dependencies, so it is unlikely to be documented by the software available to the end user.
So most of the time, the safest “oldest safe” version is just the latest version.
So only protects like Debian do security backports?
Edit: why the downvote? Is this not something upstream developers do? Security fixes on older releases?
Backports for supported versions sure,.
That’s why there is an incentive to limit support to latest and maybe one previous release, it saves on the backporting burden.
Okay, but are you still going to audit 200 individual dependencies even once?
That’s what the “oldest safe version” is supposed to address.
Because everything is labeled safe and unsafe, right?
Your snark is tremendously conducive for a conversation. Go touch some grass.
I’m not familiar with rust but at least for java there’s a owasp plugin that tells you if you’re using an unsafe library.
supposed
You’re starting to come to an interesting realization about the state of ‘modern’ programming and the risks we saw coming 20 years ago.
You don’t need to trade convenience for safety, but having worked in OS Security I would recommend it.
Pulling in random stuff you haven’t validated should feel really uncomfortable as a professional.