Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust’s dependencies are starting to worry me

vincents.dev

Post reply on HN
Print view View original

51–60 of 593 posts

Re: Rust’s dependencies are starting to worry me

#51

Post by gxt »

You can audit your dependencies for crates with security vulnerabilities reported to the RustSec Advisory Database, also block unmaintained crates, and enforce your license requirements using SPDX expressions with cargo-audit and cargo-deny.

You can ensure that third-party Rust dependencies have been audited by a trusted entity with cargo-vet.

And you should have taken a look at where those 3M locs come from, it's usually from Microsoft's windows-rs crates that are transitively included in your dependencies through default features and build targets of crates built to run on windows.

Re: Rust’s dependencies are starting to worry me

#52

Post by echelon »

bigstrat2003 wrote: post #37
echelon wrote: post #12

Earlier quoted context omitted.

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional lib…

> We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Python's standard library is a strength, not a weakness. Rust should be so lucky. It's wonderful to have basic functionality which is guaranteed to be there no matter what. Many people work in environments where they can't just YOLO download packages from the Internet, so they have to make do with whatever is in the stdl…

> Python's standard library is a strength, not a weakness. Rust should be so lucky.

Rust is luckier. It has the correct approach. You can find every battery you need in crates.io.

Python has had monstrosities like urllib, urllib2, http, etc. All pretty much ignored in favor of the external requests library and its kin. The standard library also has inconsistencies in calling conventions and naming conventions and it has to support those *FOREVER*.

The core language should be pristine. Rust is doing it right. Everything else you need is within grasp.

Re: Rust’s dependencies are starting to worry me

#53

Post by cogman10 »

wofo wrote: post #27
neilv wrote: post #19

In the past (not in Rust, but other languages), for important systems, I've instituted policies of minimizing dependencies from these language-specific package repositories, and for the ones you do use, having to copy it to our own repos and audit each update before use. But that's not practical for all situations. For example, Web frontend developer culture might be the worst environment, to the point you often can'…

There are some voices trying to address this security risk (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810 ). However, for some reason (probably culture) there isn't much momentum yet to change the status quo.

The rust RFC process has, frankly, become somewhat of a CF.

There's literally 1000s of RFCs for rust with only a small handful that are integrated. Having this forest, IMO, makes it hard for any given proposal to really stand out. Further, it makes duplicate effort almost inevitable.

Rust's RFC process is effectively a dead letter box for most.

Re: Rust’s dependencies are starting to worry me

#54

Post by [deleted] »

jaas wrote: post #42
echelon wrote: post #12

Earlier quoted context omitted.

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional lib…

I don't think an additional standard library layer, whatever you call it, has to have the same tight controls on backwards compatibility and evolution that the actual standard library has. IMO the goal of creating it should be to improve supply chain security, not to provide an extremely stable API, which might be more of a priority at lower levels but chokes off the kind of evolution that will be needed. I think wha…

[deleted]

Re: Rust’s dependencies are starting to worry me

#55

Post by delusional »

schmichael wrote: post #41

We need a term like “Mature” or similar for dependencies that are done. Mature dependencies have two characteristics: 1. Well defined scope 2. Infrequent changes Nomad has many of these (msgpack, envparse, cli, etc). These dependencies go years without changing so the dependency management burden rapidly approaches zero. This is an especially useful property for “leaf” dependencies with no dependencies of their own.…

I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects.

If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.

Re: Rust’s dependencies are starting to worry me

#56

Post by echelon »

pjmlp wrote: post #25
echelon wrote: post #12

Earlier quoted context omitted.

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional lib…

Python's garbage works everywhere there is a full CPython implementation, I see that as an advantage.

I develop for Linux, Mac, and Windows. Multiple architectures and OSes. I rarely see platform issues with Rust. It's typically only stuff at the edge, like CUDA libraries, that trip up cross-platform builds.

Rust, as a systems language, is quite good at working on a variety of systems.

Re: Rust’s dependencies are starting to worry me

#57

Post by csomar »

lolinder wrote: post #39
csomar wrote: post #26

> when checking a rust security advisory mentioning that dotenv is unmaintained This is a problem with all languages and actually an area where Rust shines (due to editions). Your pulled in packages will compile as they previously did. This is not true for garbage collected languages (pun intended). > Out of curiosity I ran toeki a tool for counting lines of code, and found a staggering 3.6 million lines of rust ....…

> This is not true for garbage collected languages JavaScript is backwards compatible going back effectively forever, as is Java. Rust's unique system is having a way to make breaking changes to the language without breaking old code, not that they prioritize supporting old code indefinitely. The libraries are a different story—you're likely to have things break under you that rely on older versions of libraries when…

> The libraries are a different story—you're likely to have things break under you that rely on older versions of libraries when you update—but I don't see Rust actually having solved that.

No language can fix that. However, I've lost count of the times my Python/JavaScript interpretation fails because of something in one of the dependencies. Usually, it's not a JS/Python problem but rather has to do with a Node/Python version update. It always boils down to the "core" issue which is the runtime. That's why I like that Rust give me a "fixed" runtime that I download/compile/package with my program.

> Node and V8 are open source, which makes the code just as auditable and modifiable as the 3.6 million lines of Rust. Which is to say, both are equally unapproachable.

I've recently patched a weird bug under Tokio/Otel and can't imagine doing that with Node/V8 without it being a major hassle. It is relatively straightforward in Rust though requires maintaining your own fork of only the dependency/branch in question.

Re: Rust’s dependencies are starting to worry me

#58

Post by infogulch »

dralley wrote: post #6
demarq wrote: post #5

> Many call for adding more to the rust standard library much like Go This is the way.

There should be a second stdlib with relaxed stability guarantees. Don't fill the normal stdlib full of cruft that can never be changed again.

This is obviously the best solution for Rust. A 'metalibrary' library type would add a lot of value to the ecosystem as a nexus:

  - All included crates can be tested for inter-compatibility
  - Release all included crates under a single version, simplifying upgrades
  - Sample projects as living documentation to demo integrations and upgrades
  - Breaking changes can be held until all affected crates are fixed, then bump all at once
  - An achievable, valuable, local goal for code review / crev coverage metrics
There could be general "everything and the kitchen sink" metalibraries, metalibraries targeted at particular domains or industries, metalibraries with different standards for stability or code review, etc. It might even be valuable enough to sell support and consulting...

Re: Rust’s dependencies are starting to worry me

#59

Post by 1vuio0pswjnm7 »

"Not thinking about package management careful makes me sloppy."

Isn't the point of a memory safe language to allow programmers to be sloppy without repercussions, i.e., to not think about managing memory and even to not understand how memory works.

Would managing dependencies be any different. Does Rust allow programmers to avoid thinking carefully about selecting dependencies.

Re: Rust’s dependencies are starting to worry me

#60

Post by pjmlp »

echelon wrote: post #56
pjmlp wrote: post #25

Earlier quoted context omitted.

Python's garbage works everywhere there is a full CPython implementation, I see that as an advantage.

I develop for Linux, Mac, and Windows. Multiple architectures and OSes. I rarely see platform issues with Rust. It's typically only stuff at the edge, like CUDA libraries, that trip up cross-platform builds. Rust, as a systems language, is quite good at working on a variety of systems.

Starts already that Rust won't support architectures not available on LLVM, but on GCC, otherwise having a Rust frontend project for GCC wouldn't be a thing.

And the systems language remark, I am still looking forward when sorting ABI issues for binary libraries is finally something that doesn't need to go through solutions designed for C and C++.

Post reply on HN