Skip to content

Conversation

@dsherret
Copy link
Contributor

There are times when I go to use a crate in Wasm and some dependency of a dependency uses this crate for randomness, but I'm not using the functionality that needs the randomness. Providing a custom backend doesn't work because then it creates a wasm export and I want my wasm interface clean. For scenarios like this, it's useful to be able to just have this crate not provide any randomness at all.

Copy link
Member

@dhardy dhardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The given impl isn't a no-op, and pretending that we randomized dest is not okay for any other dependency needing a securely-generated random key. It is a security hazard.

(This comment is also not an approval of the idea of adding a no-op backend.)

Comment on lines +7 to +12
pub fn fill_inner(dest: &mut [MaybeUninit<u8>]) -> Result<(), Error> {
for byte in dest {
byte.write(0);
}
Ok(())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should fail, reliably.

@dsherret
Copy link
Contributor Author

dsherret commented May 17, 2025

The given impl isn't a no-op

Do you have a suggestion for a better name?

and pretending that we randomized dest is not okay for any other dependency needing a securely-generated random key. It is a security hazard.

There are cases where it's completely fine. It doesn't seem like it's pretending when it's in the description?

@dsherret
Copy link
Contributor Author

dsherret commented May 17, 2025

Maybe a better solution would be to have an implementation that does a runtime panic or error? Again, in my case this code is never hit/run. I just need it to compile for wasm32-unknown-unkown without creating a bunch of bloat or changing the wasm module's interface.

@dsherret
Copy link
Contributor Author

I opened #667 as an alternative.

@dhardy
Copy link
Member

dhardy commented May 18, 2025

There are cases where it's completely fine. It doesn't seem like it's pretending when it's in the description?

It's not about what this backend claims to do; it's about what getrandom claims to do:

getrandom is a Rust library for retrieving random data from (operating) system sources.

It is assumed that the system always provides high-quality, cryptographically secure random data, ideally backed by hardware entropy sources. This crate derives its name from the Linux getrandom syscall but is cross-platform, roughly supporting the same set of platforms as Rust’s std library.

Who knows if someone might accidentally build deployment code using this backend?

Your alternative looks more acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants