Gate x448 work behind an "unstable-curve448" feature. #426
Conversation
|
I recognize that this might need a semver-incompatible version bump (to 0.15.0), if adopted, since the |
|
Thanks for digging into this! I haven't looked at the details of the PR yet, but wanted to put on the record that I am in favor of the general direction: I hope that x448 and ed448 will gain well maintained support (ideally under the rust crypto umbrella). But until then, considering x448 in rPGP to be of an experimental nature - and even to disable it by default - seems ok to me. |
|
need to add a CI check testing with the new feature, and should probably add some docs somewhere about it |
07df575 to
6873cdb
Compare
|
I've added an explicit feature
There are already tests that are marked with the I've also added a subsection to Let me know if you need anything else! |
207cfbf to
0503d99
Compare
|
I've adjusted the branch to now only create a single explicit feature |
|
@dignifiedquire this is a gentle nudge -- if you could review this and let me know if you think it needs anything else, i'd be grateful. |
The x448 crate hasn't had a release in over 2 years, while several of its dependencies are still rather unstable (in particular, ed448-goldilocks and rand_core have had at least one semver-incompatible bump since the x448 release, and ed448-goldilocks itself probably needs another release as well, since there are many useful cleanup changes pending there). This makes me think that x448 isn't quite ready for prime time in the existing rust ecosystem. Given that ed448 itself is also not supported yet, it seems like any work with Curve448 might be premature to make available by default. This patch proposes to put the x448 code behind a feature named "unstable-curve448". It will also make it easier to land the rest of the RFC 9580 work in debian, which is currently struggling with the unmaintained dependency chain here.
03fc539 to
590d0ac
Compare
|
I've just rebased and cleaned this up, please consider it for a future release! |
This way we avoid introdcing a separate "x448" feature. See https://doc.rust-lang.org/cargo/reference/features.html#optional-dependencies for more detailed discussion about dependency names.
590d0ac to
0528421
Compare
|
thanks for the feedback, @dignifiedquire ! let me know if there's any other cleanup that you want. |
|
just need ci to become greeener, then this is good to go, sorry for the delay |
|
do you want me to take any action to make the CI "become greener"? I'm not sure how to handle the cross-compilation or format "red" indicators, since i don't believe they are associated with the changes in this MR. Let me know what i can do to move this along. And, happy new year! 🎉 |
|
I think rebasing this branch on main might resolve (some of?) the CI issues |
|
I‘ll take it over tomorrow, don’t worry about it |
|
Finishing in #454 |
The x448 crate hasn't had a release in over 2 years, while several of its dependencies are still rather unstable (in particular, ed448-goldilocks and rand_core have had at least one semver-incompatible bump since the x448 release, and ed448-goldilocks itself probably needs another release as well, since there are many useful cleanup changes pending there).
This makes me think that x448 isn't quite ready for prime time in the existing rust ecosystem. Given that ed448 itself is also not supported yet, it seems like any work with Curve448 might be premature to make available by default.
This patch proposes to put the x448 code behind a feature named "unstable-curve448". It will also make it easier to land the rest of the RFC 9580 work in debian, which is currently struggling with the unmaintained dependency chain here.