Version 0.4 has a large dependency footprint

[thomaseizinger]

I just received the first dependabot PR that brings in getrandom 0.4 into my dependency tree and I noticed that this comes with many new dependencies, all of which appear to be WASM related: firezone/firezone#12264

Has there been a consideration as to whether this can be feature-flagged? We don't compile anything to WASM and it would be nice to not have to track these dependencies in our lockfile.

[tarcieri]

I believe it’s effectively a cargo bug: rust-lang/cargo#10801

See this comment in particular: rust-lang/cargo#10801 (comment)

[josephlr]

@tarcieri is correct, running cargo tree gives:

getrandom v0.4.1 (/usr/local/google/home/joerichey/dev/rust/getrandom)
├── cfg-if v1.0.4
└── libc v0.2.182

and cargo tree --features=sys_rng gives:

getrandom v0.4.1 (/usr/local/google/home/joerichey/dev/rust/getrandom)
├── cfg-if v1.0.4
├── libc v0.2.182
└── rand_core v0.10.0

which is the dependency tree we expect.

Also, the optional wasm_js feature adding dependencies is not new, it has existed since at least getrandom 0.2, so nothing should have changed with the release of 0.4.

[thomaseizinger]

so nothing should have changed with the release of 0.4.

The diff in the linked PR says otherwise though. I believe cargo tree takes into account the current target, doesn't it? Hence why it doesn't show up there.

I understand the argument that it is effectively a limitation of cargo today that we can't specify the intended targets for a crate and thus, cargo has to add dependencies for all targets to the lockfile. I guess my question is, can this be worked around with optional dependencies? I'd assume the vast majority of crates depending on getrandom will never get compiled to WASM so pulling in all of these dependencies just for that case seems like a bad tradeoff?

[josephlr]

Sorry @thomaseizinger , this doesn't have anything to do with wasm_js or wasm32-unknown-unknown.

It's being caused by the wasip2/wasip3 target support, which in turn is caused by those crates depending on wit-bindgen. Note that this change was also part of getrandom 0.3.4 in #721. You just haven't see in in your crate becasue you're on 0.3.3 not 0.3.4.

So running cargo tree --target=wasm32-wasip2 gives:

getrandom v0.4.1 (/usr/local/google/home/joerichey/dev/rust/getrandom)
├── cfg-if v1.0.4
└── wasip2 v1.0.2+wasi-0.2.9
    └── wit-bindgen v0.51.0

and running cargo tree --target=wasm32-wasip3 gives:

├── cfg-if v1.0.4
└── wasip3 v0.4.0+wasi-0.3.0-rc-2026-01-06
    └── wit-bindgen v0.51.0

So there's only an additional dependency on one crate (wit-bindgen), which is a required dependency when targeting WASI targets (like depending on libc when targeting Unix targets).

[josephlr]

I understand the argument that it is effectively a limitation of cargo today that we can't specify the intended targets for a crate and thus, cargo has to add dependencies for all targets to the lockfile. I guess my question is, can this be worked around with optional dependencies? I'd assume the vast majority of crates depending on getrandom will never get compiled to WASM so pulling in all of these dependencies just for that case seems like a bad tradeoff?

I'm not sure what we can do here, we have to depend on wit-bindgen when targeting WASI targets, and these targets are officially supported by getrandom, so we are not going to break them.

I'm not sure what we can do here. As noted above, the only dependencies we use are wasip2, wasip3 and wit-bindgen (which seems fine to me). It seems like wit-bindgen is depending on wit-bindgen-rust-macro in your PR firezone/firezone#12264, which again seems.like a result of a Cargo bug if I'm understanding correctly,

[thomaseizinger]

I'm not sure what we can do here, we have to depend on wit-bindgen when targeting WASI targets, and these targets are officially supported by getrandom, so we are not going to break them.

One theoretically possible way of solving this is to make these dependencies optional (in addition to cfg gating them on the target) and thus require downstream binaries / applications to explicitly depend on getrandom and activate a hypothetical wasi feature flag in order to get a working getrandom implementation.

That is not ideal of course but I am wondering if it is an okay trade-off considering that the vast majority of crates that depend on getrandom do not get compiled for WASI. For those cases, the dependency footprint would then be smaller.

The unfortunate consequence of the current design is that it creates noise because tools like dependabot, cargo-audit and cargo-deny all operate on the lockfile and don't know, whether a dependency is actually used by an application.

[tarcieri]

Those would be breaking changes.

I would also suggest enquiring on the upstream issue about getting cargo to omit these dependencies from Cargo.lock

[josephlr]

Those would be breaking changes.

@tarcieri is correct here.

I would also suggest enquiring on the upstream issue about getting cargo to omit these dependencies from Cargo.lock

Ya, this seems like a bug with Cargo or the tools being used. Even when targeting wasm32-wasip2, this library only depends on wasip2 and wit-bindgen, but firezone/firezone#12264 also ends up depending on wit-bindgen-rust-macro.

That is not ideal of course but I am wondering if it is an okay trade-off considering that the vast majority of crates that depend on getrandom do not get compiled for WASI. For those cases, the dependency footprint would then be smaller.

In the case where a crate is not compiling for wasm32-wasip2, the dependency footprint would be the same.

The unfortunate consequence of the current design is that it creates noise because tools like dependabot, cargo-audit and cargo-deny all operate on the lockfile and don't know, whether a dependency is actually used by an application.

@thomaseizinger this is incorrect. cargo audit allows you to specify the OS and Architecture to specifically solve this problem, see this config example. cargo deny is similar, see their documentation.

Long story short, this crate aims to support a very wide range of targets. That means depending on target-specific crates (like libc, r-efi, wasip2, etc...). When compiling for those targets, we unconditionally depend on those platform crates (which are all also dependencies of std). When compiling for any other targets, getrandom does not depend on those crates (and this is handled correctly by tools like cargo audit and cargo deny).

[pinkforest]

a lockfile (cargo generate-lockfile) does't know either 1) how and 2) for what it is compiled.

That's intentional for portability given people can install for different environments through --lockfile that isn't pinned regardless of conditional compilation.

Good luck getting them to support limiting (at binary level) targets / cfg's especially given a lockfile with all the cfg-target variant stuff can explode in size exponentially as it has to cover all the possibilities.

[thomaseizinger]

The unfortunate consequence of the current design is that it creates noise because tools like dependabot, cargo-audit and cargo-deny all operate on the lockfile and don't know, whether a dependency is actually used by an application.

@thomaseizinger this is incorrect. cargo audit allows you to specify the OS and Architecture to specifically solve this problem, see this config example. cargo deny is similar, see their documentation.

Oh! TIL.

Long story short, this crate aims to support a very wide range of targets. That means depending on target-specific crates (like libc, r-efi, wasip2, etc...). When compiling for those targets, we unconditionally depend on those platform crates (which are all also dependencies of std). When compiling for any other targets, getrandom does not depend on those crates (and this is handled correctly by tools like cargo audit and cargo deny).

I am aware that it is not being compiled and I guess it would be nice if cargo had a way of saying "exclude any dependencies for target XYZ because I am never going to compile for that". But as @pinkforest mentioned, I am not sure that will ever land in cargo. So the question kind of becomes, what could be a solution with the tools we have today to avoid dragging a lot of dependencies into the lockfile that never end up getting used in practice? And the only answer I can think of for that is "optional dependencies".

I am aware that it would be a breaking change and it is also not something that needs to happen immediately but maybe it could be considered for getrandom 0.5?

[newpavlov]

I am aware that it would be a breaking change and it is also not something that needs to happen immediately but maybe it could be considered for getrandom 0.5?

It's highly unlikely. getrandom aims to support all std targets "out of the box" whenever possible.

Your best option would be to push for inclusion of SysRng into std (see rust-lang/rust#130703). After it's implemented and stabilized we could use it in getrandom for std targets, thus reducing the visible dependency tree.

[briansmith]

I filed an issue specifically about removing the wit-bndgen dependency (and hopefully wasip2 and wasip3): #827.