Skip to content
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

doc: document security fix policy #7991

Merged
merged 1 commit into from
Mar 24, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/RELEASE_ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@

We're happy to announce go-ipfs X.Y.Z, bla bla...

As usual, this release includes important fixes, some of which may be critical for security. 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. See our [release process](https://github.com/ipfs/go-ipfs/tree/master/docs/releases.md#security-fix-policy) for details.

## 🗺 What's left for release

<List of items with PRs and/or Issues to be considered for this release>
Expand Down
8 changes: 8 additions & 0 deletions docs/releases.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor

@schomatis schomatis Mar 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).


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.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably expand on this. This comes down to:

  1. Patch releases take a lot of time/effort.
  2. 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.
  3. We definitely can't backport security fixes immediately because it would effectively turn the issue into a zero-day.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Performing a Release

The release is managed by the `Lead Maintainer` for `go-ipfs`. It starts with the opening of an issue containing the content available on the [RELEASE_ISSUE_TEMPLATE](./RELEASE_ISSUE_TEMPLATE.md) not more than **48 hours** after the previous release.
Expand Down