feature gate random state #97
Conversation
xu-cheng
force-pushed
the
feature-gate-random-state
branch
4 times, most recently
from
b51b8b8
to
c01d485
Compare
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
force-pushed
the
feature-gate-random-state
branch
from
c01d485
to
6c08360
Compare
|
Noted that this would be a semver breaking change |
|
Issue #94 asside, getrandom is no_std. So why would you want to avoid it in a no_std env? |
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. |
|
Any further comments? |
|
Ping @tkaitchuck. Any chance to move this PR forward. |
|
@xu-cheng getrandom explicitly supports SGX environments through RDRAND. It seems like that would be the ideal solution there. 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. 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. |
|
This feature is now available in v0.8.0 |
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.