doc: document security fix policy #7991
Conversation
Stebalien
commented
Mar 18, 2021
Stebalien
commented
- All releases may contain unannounced security fixes.
- By default, security fixes will not be backported.
1. All releases may contain unannounced security fixes. 2. By default, security fixes will not be backported.
|
|
||
| By policy, the team will usually wait until about 2 weeks after the final release to announce any fixed security issues. However, depending on the impact and ease of discovery of the issue, the team may wait more or less time. It is important to always update to the latest version ASAP and file issues if you're unable to update for some reason. | ||
|
|
||
| Finally, unless a security issue is actively being exploited or a significant number of users are unable to update to the latest version (e.g., due to a difficult migration, breaking changes, etc.), security fixes will _not_ be backported to previous releases. |
There was a problem hiding this comment.
We should probably expand on this. This comes down to:
- Patch releases take a lot of time/effort.
- We fix lots of bugs that might theoretically be security fixes but it would take a significant amount of investigation to determine the potential impact. We really don't want anyone to continue to use older go-ipfs releases assuming that "everything's good" because security fixes get backported.
- We definitely can't backport security fixes immediately because it would effectively turn the issue into a zero-day.
There was a problem hiding this comment.
This just ties to our existing maintenance policy though, yes? Although it doesn't look like we have this written down anywhere. We only support the latest minor. We may, in the future support multiple versions, but that is a ways out. Any back porting is an exception to the rule, which I think this change already clarifies.
There was a problem hiding this comment.
Yeah, writing down our normal policy would be good too. But I do want to call this out so nobody thinks they're fine as long as they run the latest patch release.
| @@ -83,6 +83,14 @@ Patch releases will usually follow a compressed release cycle and should take 2- | |||
|
|
|||
| Some patch releases, especially ones fixing one or more complex bugs, may undergo the full release process. | |||
|
|
|||
| ## Security Fix Policy | |||
|
|
|||
| Any release may contain security fixes. Unless the fix addresses a bug being exploited in the wild, the fix will _not_ be called out in the release notes. Please make sure to update ASAP. | |||
There was a problem hiding this comment.
This should at least be encoded as a minor version update, I don't know how realistic it is to offload the responsibility of monitoring and updating to any release. (Minor version bump might be too much for the release cadence here, I just mean a signal that this update is relevant: maybe because it has security fixes, or some other protocol update.)
There was a problem hiding this comment.
A mailing list may be a better approach here for notification than relying on versioning. We could then link the opt in list in the security readme. I don't want to block this on that decision though.
There was a problem hiding this comment.
Patch releases may also include super-critical security releases, although I guess those will usually be announced (or really well hidden but that's difficult).
