Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature gate random state #97

Closed

Conversation

xu-cheng
Copy link

This is especially useful for no_std development, where we don't want to introduce the getrandom dependency.

After this change, one can choose to disable random-state feature and implement their own version of RandomState using whatever random source they choose. This also somewhat addresses #94 and avoids the need of using compile-time-rng in restricted platforms.

This is especially useful for no_std development, where we don't want to
introduce the getrandom dependency.

After this change, one can choose to disable random-state feature and
implement their own version of RandomState using whatever random source
they choose.

This also somewhat addresses tkaitchuck#94 and avoids the need of using
compile-time-rng in restricted platforms.
@xu-cheng
Copy link
Author

Noted that this would be a semver breaking change

@tkaitchuck
Copy link
Owner

Issue #94 asside, getrandom is no_std. So why would you want to avoid it in a no_std env?

@xu-cheng
Copy link
Author

xu-cheng commented Sep 2, 2021

getrandom is no_std

getrandom is not truly no_std. It works by invoking system call through libc. Moreover, it is designed in such a way that it is impossible to overwrite the random source. As a result, it will break in certain no_std environment, where we don’t want to link to any system library, such as sgx.

The PR would give the crate user more flexibility, where we can choose whether we want a default random source, i.e. getrandom, or choose to implement a custom one.

@xu-cheng
Copy link
Author

xu-cheng commented Sep 7, 2021

Any further comments?

@xu-cheng
Copy link
Author

Ping @tkaitchuck. Any chance to move this PR forward.

@tkaitchuck
Copy link
Owner

tkaitchuck commented Oct 11, 2021

@xu-cheng getrandom explicitly supports SGX environments through RDRAND. It seems like that would be the ideal solution there.
But if you really want to disable all randomness, I don't see any way to do this with cargo's feature rules and keep things in one crate. Because it doesn't allow mutually exclusive features or forced choices in feature flags.

From a build perspective this makes sense. If you have multiple libraries getting linked together and one requires randomization and the other absolutely cannot have it, there is no way to resolve it without one of them breaking the other.
I think the solution will have to involve multiple crates.

There are a couple of ways to go about this, one would be to re-factor the hashing algo out into its own crate independent of its invocation and then have different crates for invoking it. However I think it may make sense for them to diverge in their implementation. For example for SGX etc it probably makes sense to limit the instructions, and if randomness is not being used anyway the hashing algorithm can be significantly weaker as the data is being trusted already.

Barring some clever way to combine this with #94, I think the solution is to open an issue, or maybe just a comment on issue #58 and then I can create a new crate with a low-quality non-randomized hash.

@tkaitchuck
Copy link
Owner

tkaitchuck commented Aug 10, 2022

This feature is now available in v0.8.0

@tkaitchuck tkaitchuck closed this Aug 10, 2022
@xu-cheng xu-cheng deleted the feature-gate-random-state branch August 10, 2022 06:59
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