Add security policy, post-v1.0 MSRV bump policy - #367
Conversation
DJMcNab
left a comment
DJMcNab
left a comment
There was a problem hiding this comment.
One question I do have is what counts as a security backport. E.g. if one of our operations doesn't meet the specified semantics, that can be a security issue in a downstream crate (e.g. one doing cryptographic hashing, say). But then silently updating the implementation to have different semantics is a Hyrum's law nightmare.
I'd be tempted to specify "soundness" as the baseline boundary, and leave everything else unspecified. In a scenario where we do discover a method doesn't work as documented, I'd expect us to probably backport the deprecation and providing a new fixed method, rather than updating semantics. (Although I wonder how that works for core::ops impls!)
Aside from that concern, this looks great. And being overly vague with what counts as a security issue is fine - I don't expect this policy to ever come up in practice.
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
|
@LaurenzV I'd like to hear from you as well before we commit to this. |
LaurenzV
left a comment
LaurenzV
left a comment
There was a problem hiding this comment.
Overall fine from my side, trusting your judgement on this. 😄
| Future versions of Fearless SIMD might increase the Rust version requirement. This will be accompanied by a minor version bump. | ||
|
|
||
| If you require a fixed MSRV, we recommend using Cargo's [MSRV-aware resolver](https://doc.rust-lang.org/edition-guide/rust-2024/cargo-resolver.html) which will not select a version that fails to build. | ||
| We will provide [security backports](SECURITY.md) to older Rust versions released within the last 3 years. |
There was a problem hiding this comment.
What's the usual procedure for handling this? Do we create a new branch for each backported version?
There was a problem hiding this comment.
Yes, branch off the git tag for that version. Even if we don't do tags, cargo now includes the git commit state into archive published to crates.io, so we always know where to branch off.
3 participants
Based on the discussion in the relevant Zulip thread: #simd > v1.0.0