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
Stabilisation of rand_core crate #386
Comments
@dhardy Is does the releases, so I can only give my idea. There is already a pre-release of @dhardy: Would it make sense to release |
Yes, I think releasing 0.1.0 soon should be fine. Doc updates and optimisations can potentially land as a point release anyway so no issues there. Lets open a PR to bump the version numbers (and changelog/readme), then if nothing comes up for a couple of days I'll make that the release — unless you want to do the |
rand_core 0.1.0 is released 🎉. |
Hooray! Thanks a bunch @pitdicker and @dhardy! |
Hi! I'm sorry for creating an issue when this isn't one, but I wasn't sure how else to get in contact. Feel free to close. (Also my work email is isis@torproject.org and I'm in most of the Mozilla IRC rust channels as isis.)
In tor, we have C wrappers around OpenSSL's CSPRNG as well as some syscalls (when available). In order to avoid accidentally producing multiple CSPRNGs with the same state (we're using both C and Rust in the codebase right now, with some implementations duplicated/rewritten and others wrapped), we'd like to simply wrap our C code (tracking ticket). It seems like the best way to do this would be to implement traits from
rand_core
, especially since it's difficult for us to pull in extra dependencies (and we're not ready to switch over to any of your Rust implementations just yet, since we can't yet make Rust a mandatory compilation requirement).Do you have any ideas when you might stabilise
rand_core
? Or perhaps put out a pre-release? Is there any way I can help with this process?Thanks! and keep up all the great work!
The text was updated successfully, but these errors were encountered: