[SECURITY] Add Security Policy and Supported Versions page to website #10829
Conversation
There was a problem hiding this comment.
Hi @michaeljmarshall many thanks for your contribution!
Currently, the security section on Pulsar redirects to https://www.apache.org/security/. Is it required? Can we modify it？
Spark shows security issues on the security section, shall we take a similar approach? If so, the link of this security.md can be added on that page, just only keep an original file to reduce maintenance cost.
SECURITY.md
Outdated
| ## Using Pulsar's Security Features | ||
|
|
||
| You can find documentation on Pulsar's available security features and how to use them here: | ||
| https://pulsar.apache.org/docs/en/security-overview/. |
There was a problem hiding this comment.
| https://pulsar.apache.org/docs/en/security-overview/. | |
| https://pulsar.apache.org/docs/en/next/security-overview/. |
Suggest using the latest info
There was a problem hiding this comment.
Does this still apply? Why have we added the /next in the url? (Asking just so I can understand our website better.)
There was a problem hiding this comment.
Did you change this? IIRC the /next site is going towards the updated site which should roll out soon.
However since this page is now in the /docs part of the repository. It may need to duplication in /next/
There was a problem hiding this comment.
I am a bit confused about where to put the doc. This PR current puts the new page is in site2/docs. Are docs supposed to be copied to site2/website-next/docs too?
There was a problem hiding this comment.
I just saw your other comment about site2/docs/next. I didn't know about those docs.
@Anonymitaet - I believe it is required for us to point to the Apache security process. This wiki document references some details: https://github.com/apache/pulsar/wiki/Apache-Maturity-Model-Assessment-for-Pulsar#maturity-model-assessment. It looks like Apache Spark has two different "Security" links available in their top bar. One that goes to Apache's docs and one that goes to the Spark specific docs. They too follow the Apache protocol for security vulnerabilities, so we could follow their pattern here.
@sijie - sure, makes sense to me. I'll submit a new commit with the main contents of this PR on the pulsar website. |
|
@sijie and @Anonymitaet - do you have any other comments on the content? As far as where the information should be on the website, I am thinking we can add some information to the https://pulsar.apache.org/docs/en/security-overview/ and then I am thinking we can add a tab for "Supported Versions" in that same security section. I think it'd make sense to update the website for all versions that are "supported" as defined in this PR. |
|
@michaeljmarshall just my two cents: seems that the contents of Kafka Security Chapter: https://kafka.apache.org/documentation/#security Pls correct me if I'm wrong, thanks. |
I don't have strong feelings about its location and am happy to move it to another location. I was thinking it could belong in the Security chapter because security vulnerabilities only really affect users that are actually using the security features, and the only way to know that you are not subject to known security vulnerabilities is to run on the latest supported version for a given minor release. In looking at your screen shots from the Apache Spark website, they have similar information here: https://spark.apache.org/versioning-policy.html. That Also, I can see that they have a reference to the Apache security link in a location similar to our current set up:
@Anonymitaet - are you open to adding a new tab in the top banner named "Developers"? That could be a natural location for the supported version information as well as the listing our known security vulnerabilities. It could be very similar to the Apache Spark implementation. |
|
I spoke with @merlimat in the community meeting about this today. He mentioned that |
|
@michaeljmarshall thanks for your explanations, then I know why you want to add |
|
@Anonymitaet - great, thanks for the feedback. For anyone following this thread, I won't be able to follow up on this until next week. I expect to complete it then. |
|
I think that with updates to cover what are now our current versions and what's now EOL plus the url change this will be good to merge. |
|
@dave2wave - thank you for reminding me about this PR. I updated it so that it will live on the @sijie and @Anonymitaet - PTAL, thanks! |
michaeljmarshall
added
area/security
doc
There was a problem hiding this comment.
LGTM
The only concern is that pages like this, with dates, tend to become obsolete if the community does not care of them (like it is happening on bookkeeper.apache.org)
I suggest to update the Release Procedure to ask to the Release Manager to Update this page when needed
@eolivelli - yes, there is always a risk of these tables becoming out of date. I think the specificity that these tables provide is very valuable to users, though. I will update the release guide on the wiki once this PR is merged. |
michaeljmarshall
changed the title
michaeljmarshall
dismissed
sijie’s stale review
The policy information is now on the website, and the SECURITY.md file points to the webpage
michaeljmarshall
changed the title
michaeljmarshall
changed the title
|
@merlimat - PTAL. I added a note about linear upgrades based on our conversation in today's community meeting. |
|
@Anonymitaet - can you take a look at this PR? I'm not sure which directory I'm supposed to use for the webpage. Thanks. |
|
@michaeljmarshall I suggest copying the same changes to |
@Anonymitaet - thanks for letting me know. Is this documented anywhere? Is there a plan to resolve any conflicts? I am worried that I did not know about this nuance and may have only written docs to the |
michaeljmarshall
force-pushed
the
add-security-md
branch
from
c104bba to
7bc9af7
Compare
|
I copied the webpage doc to |
|
Merging this PR now. I responded to all feedback, and I posted the PR to the mailing list on Feb 1st. |
|
I just updated the release process on our wiki to guide the release manager to update the supported version template: https://github.com/apache/pulsar/wiki/Release-process. |
|
| ## Supported Versions | ||
|
|
||
| Feature release branches will be maintained with security fix and bug fix releases for a period of at least 12 months | ||
| after initial release. For example, branch 2.5.x is no longer considered maintained as of January 2021, 12 months after | ||
| the release of 2.5.0 in January 2020. No more 2.5.x releases should be expected at this point, even to fix security | ||
| vulnerabilities. | ||
|
|
||
| Note that a minor version can be maintained past it's 12 month initial support period. For example, version 2.7 is still | ||
| actively maintained. | ||
|
|
||
| Security fixes will be given priority when it comes to back porting fixes to older versions that are within the | ||
| supported time window. It is challenging to decide which bug fixes to back port to old versions. As such, the latest | ||
| versions will have the most bug fixes. | ||
|
|
||
| When 3.0.0 is released, the community will decide how to continue supporting 2.x. It is possible that the last minor | ||
| release within 2.x will be maintained for longer as an “LTS” release, but it has not been officially decided. | ||
|
|
||
| The following table shows version support timelines and will be updated with each release. | ||
|
|
||
| | Version | Supported | Initial Release | At Least Until | | ||
| |:-------:|:------------------:|:---------------:|:--------------:| | ||
| | 2.9.x | :white_check_mark: | November 2021 | November 2022 | | ||
| | 2.8.x | :white_check_mark: | June 2021 | June 2022 | | ||
| | 2.7.x | :white_check_mark: | November 2020 | November 2021 | | ||
| | 2.6.x | :x: | June 2020 | June 2021 | | ||
| | 2.5.x | :x: | January 2020 | January 2021 | | ||
| | 2.4.x | :x: | July 2019 | July 2020 | | ||
| | < 2.3.x | :x: | - | - | | ||
|
|
||
| If there is ambiguity about which versions of Pulsar are actively supported, please ask on the [users@pulsar.apache.org](mailto:users@pulsar.apache.org) | ||
| mailing list. |
There was a problem hiding this comment.
FYI @momo-jun @D-2-Ed @DaveDuggins
This is related to doc maintenance (doc life cycle)
…apache#10829) * Add SECURITY.md with explicit dates for version support * Add Security and Versioning Policy page to website * Clarify that a version can be supported longer than 12 months * Clean up; Add announcement section * Improve title for better clarity * Add note about upgrade compatibility * Copy doc to site2/website-next/docs The original context for this PR is on the dev mailing list here: https://lists.apache.org/thread.html/ra2db06e8da85bff67d8d588dc1e93d965f2e1d70c95bda2f08d14138%40%3Cdev.pulsar.apache.org%3E ### Motivation The Pulsar project does not explicitly declare version support time lines. By declaring support time lines, we can give our users more confidence that they will receive relevant security fixes before vulnerabilities are announced. Additionally, these time lines will guide the PMC when determining which branches need to receive security fixes. I decided to start with a 12 month support window instead of 18. If we use 18 months, 2.5.x should still technically be supported. Additionally, PIP-47 indicates that we should be doing 4 minor releases a year. If we tried to support releases for 18 months, that could mean a _lot_ of extra releases if there are security vulnerabilities discovered in all active branches. I am open to debate/feedback on this point. ### Modifications Add a `SECURITY.md` file and pages on the website. ### Release Process If this PR is accepted, I'll follow up with a change to the pulsar wiki to update the release process. Each minor and major release will require an update to the table in the `SECURITY.md` file. ### Other Changes It might be worth adding the content in this PR to a page on the pulsar website. I'm not sure where to add that yet, so I'd like to get feedback on this content before duplicating it to the website. ### Reference I used the Apache Spark version policy (https://spark.apache.org/versioning-policy.html) as a guide for creating this doc.
The original context for this PR is on the dev mailing list here: https://lists.apache.org/thread.html/ra2db06e8da85bff67d8d588dc1e93d965f2e1d70c95bda2f08d14138%40%3Cdev.pulsar.apache.org%3E
Motivation
The Pulsar project does not explicitly declare version support time lines. By declaring support time lines, we can give our users more confidence that they will receive relevant security fixes before vulnerabilities are announced. Additionally, these time lines will guide the PMC when determining which branches need to receive security fixes.
I decided to start with a 12 month support window instead of 18. If we use 18 months, 2.5.x should still technically be supported. Additionally, PIP-47 indicates that we should be doing 4 minor releases a year. If we tried to support releases for 18 months, that could mean a lot of extra releases if there are security vulnerabilities discovered in all active branches. I am open to debate/feedback on this point.
Modifications
Add a
SECURITY.mdfile and pages on the website.Release Process
If this PR is accepted, I'll follow up with a change to the pulsar wiki to update the release process. Each minor and major release will require an update to the table in the
SECURITY.mdfile.Other Changes
It might be worth adding the content in this PR to a page on the pulsar website. I'm not sure where to add that yet, so I'd like to get feedback on this content before duplicating it to the website.
Reference
I used the Apache Spark version policy (https://spark.apache.org/versioning-policy.html) as a guide for creating this doc.