[ruuda]

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

[pregnenolone]

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16

You're still pulling a lot of dependencies. At least they're pinned though.

[mayama]

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others.

https://lib.rs/crates/rbw

[embedding-shape]

326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

Takes what, maybe 15 seconds to compile on a high-core machine from scratch? Isn't the end of the world.

Worse is the scope to have to review all those things, if you'd like to use it for your main passwords, that'd be my biggest worry. Luckily most are well established already as far as I can tell.

[dijit]

Why are you talking about compile times in a thread about supply chain security.

326 packages is approximately 326 more packages than I will ever fully audit to a point where my employer would be comfortable with me making that decision (I do it because many eyes make bugs shallow).

It's also approximately 300 more than the community will audit, because it will only be "the big ones" that get audited, like serde and tokio.

I don't see people rushing to audit `zmij` (v1.0.19), despite it having just as much potential to backdoor my systems as tokio does.

[elAhmo]

"326 seems large, but not abnormal" was the state of JS in the past as well.

Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.

[seanw444]

It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.

[embedding-shape]

That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.

[jeroenhd]

I doubt Microsoft's kernel/system Rust code is pulling in a lot of crates. The Linux kernel sure isn't, and Android's Bluetooth stack doesn't seem to either.

Using crates is a choice. You can write fully independent C++ or you can pull in Boost + Qt + whatever libraries you need. Even for C programs, I find my package manager downloading tons of dependencies for some programs, including things like full XML parsers to support a feature I never plan to use.

Javascript was one of the first languages to highlight this problem with things like left-pad, but the xz backdoor showed that it's also perfectly possible to do the same attack on highly-audited programs written in a system language that doesn't even have a package manager.

[atdt]

What exactly would you have done differently?

Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.

[cromka]

Same here.

[Ferret7446]

> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

That's a damning indictment of Rust. Something as big as Chrome has IIRC a few thousand dependencies. If a simple password manager CLI has hundreds, something has gone wrong. I'd expect only a few dozen

[gtest]

> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

How many are third-party?

[xvedejas]

Does this take into account feature flags when summing LOC? It's common practice in Rust to really only use a subset of a dependency, controlled by compile-time flags.

[saghm]

My experience has been that while there's significant granularity in terms of features, in practice very few people actively go out of their way to prune the default set because the ergonomics are kind of terrible, and whether or not the default feature set is practically empty or pulls in tons of stuff varies considerably. I felt strongly enough about this that I wrote up my only blog post on this a bit over a year ago, and I think most of it still applies: https://saghm.com/cargo-features-rust-compile-times/

[gsnedders]

Also just unit tests in the source files, which again aren’t included in the binary via compile-time flags!

[traderj0e]

For a given tool, I'd expect the Rust version to have even more deps than the JS version because code reuse is more important in a lower-level language. I get the argument that JS users are on average less competent than Rust users, but we're talking about authors who build serious tools/libs in the first place.

[saghm]

> At least they're pinned though.

Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it.

The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.

[LegionMammal978]

> The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.

Not quite: "1.2.3" = "^1.2.3" = ">=1.2.3, <2.0.0" in Cargo [0], and "1.2" = "^1.2.0" = ">=1.2.0, <2.0.0", so you get the "1.x.x" behavior either way. If you actually want the "1.2.x" behavior (e.g., I've sometimes used that behavior for gmp-mpfr-sys), you should write "~1.2.3" = ">=1.2.3, <1.3.0".

[0] https://doc.rust-lang.org/cargo/reference/specifying-depende...

[saghm]

I don't know how I got this wrong because I literally went and looked at that page to try to remind myself, but I somehow misread it, because you're definitely right. This probably isn't the first time I've gotten this wrong either.

From thinking it through more closely, it does actually seem like it might be a little safer to avoid specifying the patch version; it seems like putting 1.2.3 would fail to resolve any valid version in the case that 1.2.2 is the last non-yanked version and 1.2.3 is yanked. I feel like "1.2.3" meaning "~1.2.3" would have been a better default, since it at least provides some useful tradeoff compared to "1.2", but with the way it actually works, it seems like putting a full version with no operator is basically worse than either of the other options, which is disappointing.

[tombh]

Are we talking about `cargo build` here? Because my understanding is that if a lockfile is present and `Cargo.toml` hasn't changed since the lockfile was created then the build is guaranteed to use the versions in the lockfile.

If however `Cargo.toml` has changed then `cargo build` will have to recalculate the lockfile. Hence why it can be useful to be explicit about `cargo build --locked`.

[subarctic]

Is there a plan to change this? I don't see why --locked shouldn't be the default

[saghm]

I haven't heard anything about this, but I really wish it was there by default. I don't think the way it works right now fits anyone's expectations of what the lockfile is supposed to do; the whole point of storing the resolved versions in a file is to, well, lock them, and implicitly updating them every time you build doesn't do that.

[wycats]

As one of the original authors of Cargo, I agree. lockfiles are for apps and CLIs are apps. QED.

[saghm]

Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.0 years of Rust, whereas at this point I think it's more common for me to see than not.

Do you think it's an actively bad practice, completely benign, or something in between where it makes sense in some cases but probably should still be avoided in others? Offhand, the only variable I can think of that might influence a different choice is that maybe closed-source packages been reused within a company (especially if trying to interface with other package management systems, which I saw firsthand when working at AWS but I'm guessing is something other large companies would also run into), but I'm curious if there are other names nuances I haven't thought of

[masklinn]

> It's not totally clear to me exactly when or why it became widespread

It’s not exactly a tough nut to crack: it changed 2-ish years ago after guidance (and cargo’s defaults) changed: https://blog.rust-lang.org/2023/08/29/committing-lockfiles/

[poly2it]

It should be fine to do this according to semver as long as the major version is above zero.

[saghm]

Sure, but according to semver it's also totally fine to change a function that returns a Result to start returning Err in cases that used to be Ok. Semver might be ae to project from your Rust code not compiling after you update, but it doesn't guarantee it will do the same thing the next time you run it. While changes like that could still happen in a patch release, I'd argue that you're losing nothing by forgoing new API features if all you're doing is recompiling the existing code you have without making any changes, so only getting patches and manually updating for anything else is a better default. (That said, one of the sibling comments pointed out I was actually wrong about the implicit behavior of Cargo dependencies, so what I recommended doesn't protect from anything, but not for the reasons it sounds like you were thinking).

Some people might argue that changing a function to return an error where it didn't previously would be a breaking change; I'd argue that those people are wrong about what semver means. From what I can tell, people having their own mental model of semver that conflicts with the actual specification is pretty common. Most of the time when I've had coworkers claim that semver says something that actively conflicts with what it says, after I point out the part of the spec that says something else, they end up still advocating for what they originally had said. This is fine, because there's nothing inherently wrong with a version schema other than semver, but I try to push back when the term itself gets used incorrectly because it makes discussions much more difficult than they need to be.

[vablings]

Wait, you're telling me that node deps are not pin by default. Every time you run your code you might be pulling in a new version.

No wonder...

[hombre_fatal]

Node deps are pinned: https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-j...

The problem is that you also want to update deps.

[bfivyvysj]

Why?

[NetMageSCW]

Because they could have a security flaw that might compromise your project or any users of it.

[vablings]

For any of my rust projects I really don't bump my deps unless dependabot shows a serious vulnerability or I want to use a new feature added. Outside of that my deps are locked to the last known good version i use.

[ramon156]

This + vaultwarden is an awesome self-hostable rust version of bitwarden. We might as well close the loop!

[yangikan]

Is there any downside to using the firefox builtin password manager?

[saghm]

Does it support autofill for other apps on mobile? I'd argue that putting passwords in your phone clipboard could itself be risky (although for someone who's extremely security conscious, maybe discouraging using apps isn't a downside)

[hsbauauvhabzb]

So uninstall Reddit? That app is spyware at best and malware at worst.

[saghm]

I'm guessing you meant to respond to the sibling comment rather than mine

[hsbauauvhabzb]

Yes, weirdly enough at the time there was no reply button, I thought HN comments had a maximum nested depth, but now it has a reply button and so does yours. Weird.

[saghm]

Ah, no worries! Replies seem to get throttled sometimes when the site detects a lot of nested replies quickly and it intentionally delays the ability to reply a bit. I've always assumed that it's intended as a way to try to mitigate threads that potentially are devolving into flamewars.

[bfivyvysj]

Reddit is always pasting clipboard.

[cromka]

It's a bit ironic that everyone considers Rust as safer while completely ignoring the heavily increased risk of pulling in malware in dependencies.

[pdimitar]

Different things. "Rust is safer" generally means memory safety i.e. no double-free, no use-after-free, no buffer-/under-flows, and the like. The safety you seem to have in mind is "minimal dependency count".

[guywithahat]

That’s my concern too. Rust has the same dependency concerns, which is how hackers get into code. VaultWarden has the same Rust dependency concern. Ironically we’re entering an age where C/C++ seems to have everything figured out from a dependency injection standpoint

[saghm]

Now all they need to figure out is how to actually make the C/C++ code that isn't from dependencies secure and they'll be all set

[koyote]

I wonder if this is going to push more software to stacks like .Net where you can do most things with zero third-party dependencies.

Or, conversely, encourage programming languages to increase the number of features in their standard libraries.

[saghm]

A few months ago I tried to build a .NET package on Linux, and the certificate revocation checks for the dependencies didn't complete even after several minutes. Eventually I found out about the option `NUGET_CERTIFICATE_REVOCATION_MODE=offline`, which managed to cause the build to complete in a sane amount of time.

It's hard for me to take seriously any suggestion that .NET is a model for how ecosystems should approach dependency management based on that, but I guess having an abysmal experience when there are dependencies is one way to avoid risks. (I would imagine it's probably not this bad on Windows, or else nobody would use it, but at least personally I have no interest in developing on a stack that I can't expect to work reliably out of the box Linux)

[mayama]

go and python exits with sane stdlib and are already used extensively

[infogulch]

Oh nice it works as an ssh-agent too. Definitely checking this one out.