Trait bounds for random functions in 1.1
#232
Comments
|
Here's my fix, for reference: stellar/slingshot#89 |
|
My feeling is that it would be better to revert #219 in 1.1.3, so that there's no potential for future problems. We will have to release a 2.0 eventually once the |
hdevalence
added a commit
that referenced
this issue
Feb 15, 2019
See discussion at #232 , copied below: `1.1` changed the trait bounds for `RistrettoPoint::random` and `Scalar::random`, see #222 and #219. These changes have two benefits: * they unlink us from the `rand` crate and make us depend only on `rand_core`; * they allow passing both owned and borrowed RNGs. The change was not supposed to be a breaking change, since the new bounds are strictly more general than the old ones (as every `RngCore` is an `Rng` and every `&mut RngCore` is an `RngCore`), so the new bound is satisfied in every situation where the old bound applied. The `1.1.0-pre.0` version didn't cause problems on the crates I tested it on, but there was an unexpected problem: https://github.com/interstellar/slingshot/blob/ce71c93a9a29ac3b4f69ce71feb987bd64d6c4ec/spacesuit/src/value.rs#L160-L161 broke, since it took a borrow as input and used it twice. So there was slight breakage. One option is to revert the changes (probably just the ones from #219) and release 1.1.3; another would be to fix up `slingshot` and leave the new bound.
Merged
|
Closing this since it was fixed in #233 |
pinkforest
pushed a commit
to pinkforest/curve25519-dalek
that referenced
this issue
Jun 27, 2023
GitHub Actions runners are not guaranteed to have the necessary CPU features in order for these tests to work. Uses a `--target x86_64-unknown-linux-gnu` directive when compiling so the `target_feature` flags don't apply to build scripts.
plotskogwq
added a commit
to plotskogwq/curve25519-dalek
that referenced
this issue
Aug 10, 2024
See discussion at dalek-cryptography/curve25519-dalek#232 , copied below: `1.1` changed the trait bounds for `RistrettoPoint::random` and `Scalar::random`, see #222 and #219. These changes have two benefits: * they unlink us from the `rand` crate and make us depend only on `rand_core`; * they allow passing both owned and borrowed RNGs. The change was not supposed to be a breaking change, since the new bounds are strictly more general than the old ones (as every `RngCore` is an `Rng` and every `&mut RngCore` is an `RngCore`), so the new bound is satisfied in every situation where the old bound applied. The `1.1.0-pre.0` version didn't cause problems on the crates I tested it on, but there was an unexpected problem: https://github.com/interstellar/slingshot/blob/ce71c93a9a29ac3b4f69ce71feb987bd64d6c4ec/spacesuit/src/value.rs#L160-L161 broke, since it took a borrow as input and used it twice. So there was slight breakage. One option is to revert the changes (probably just the ones from #219) and release 1.1.3; another would be to fix up `slingshot` and leave the new bound.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1.1changed the trait bounds forRistrettoPoint::randomandScalar::random, see #222 and #219.These changes have two benefits:
randcrate and make us depend only onrand_core;The change was not supposed to be a breaking change, since the new bounds are strictly more general than the old ones (as every
RngCoreis anRngand every&mut RngCoreis anRngCore), so the new bound is satisfied in every situation where the old bound applied.The
1.1.0-pre.0version didn't cause problems on the crates I tested it on, but there was an unexpected problem: https://github.com/interstellar/slingshot/blob/ce71c93a9a29ac3b4f69ce71feb987bd64d6c4ec/spacesuit/src/value.rs#L160-L161 broke, since it took a borrow as input and used it twice. So there was slight breakage.One option is to revert the changes (probably just the ones from #219) and release 1.1.3; another would be to fix up
slingshotand leave the new bound.The text was updated successfully, but these errors were encountered: