pankajkoti commented on code in PR #30960: URL: https://github.com/apache/airflow/pull/30960#discussion_r1186802452
########## dev/README_RELEASE_HELM_CHART.md: ########## @@ -715,6 +730,7 @@ Don't forget to thank the folks who tested and close the issue tracking the test Updating issue templates in `.github/ISSUE_TEMPLATE/airflow_helmchart_bug_report.yml` with the new version + Review Comment: ```suggestion ``` ########## .github/SECURITY.rst: ########## @@ -52,3 +52,75 @@ before disclosing it publicly. The `ASF Security team's page <https://www.apache.org/security/>`_ describes how vulnerability reports are handled, and includes PGP keys if you wish to use that. + + +Handling security issues in Airflow +----------------------------------- + +The security issues in Airflow are handled by the Airflow Security Team. The team consists +of selected PMC members that are interested in looking at, discussing about and fixing the +security issues, but it can also include committers and non-committer contributors that are +not PMC members yet but have a vital interest in the security of the project and have been +approved by the PMC members in a vote. You can request to be added to the team by sending +a message to [email protected], however, the team is not open to everyone and you need +to prove that you have a vital interest in the security of the project and that you are known +and trusted by at least some members of the PMC to request to be added to the team. Requests +coming from people generally unknown to the PMC members will be rejected. + +There are certain expectations from the members of the security team: + +* They are supposed to be active in assessing, discussing about, fixing and releasing the + security issues in Airflow. While it is perfectly understood that as volunteers, we might have + periods of lower activity, prolonged lack of activity and participation will result in removal + from the team, pending PMC decision (the decision on removal can be taken by LAZY CONSENSUS among + all the PMC members on [email protected] mailing list). + +* They are not supposed to reveal the information about pending and not-fixed security issues to anyone + (including their employers) unless specifically authorised by the security team members, specifically + if diagnosing and solving the issue might involve the need of external experts - for example security + experts that are available through Airflow stakeholders. The intent about involving 3rd parties has + to be discussed and agreed up at [email protected]. + +* They have to have an `ICLA <https://www.apache.org/licenses/contributor-agreements.html>`_ signed with + Apache Software Foundation. + +* The security team members might inform 3rd parties about fixes, for example in order to asses if the fix + is solving the problem or in order to assess it's applicability to be applied by 3rd parties, as soon + as PR solving the issue is opened in the public airflow repository. + +* In case of critical security issues, the members of the security team might iterate on a fix in a + private repository and only open the PR in the public repository once the fix is ready to be released, + with the intent of minimising the time between the fix being available and the fix being released. In this + case the PR might be sent to review and comment to the PMC members on private list, in order to request + an expedited voting on the release. The voting for such release might be done on the private list and + should be made public at the devlist as soon as the release is ready to be announced. + +* The security team members will assign themselves to solve certain issues and keep the status in the + security tool provided by the Apache Software Foundation security team where they allocate CVEs to + the issues and maintain information about the status, PRs, finders for the issues and link it to + the discussions started on the private list. + +* The security team members working on the fix might be mentioned as remediation developers in the CVE + including their job affiliation if they want to. + +* Community members acting as release managers are by default members of the security team and unless they + want to, they do not have to be involved in discussing and solving the issues. They are responsible for + releasing the CVE information (announcement and publishing to security indexes) as part of the + release process. This is facilitated by the security tool provided by the Apache Software Foundation. + +Releasing Airflow with security patches +--------------------------------------- + +Apache Airflow uses strict `SemVer <https://semver.org>`_ versioning policy, which means that we strive for +any release of a given ``MAJOR`` Version (version "2" currently) to be backwards compatible. When we +release ``MINOR`` version, the development continues in the ``main`` branch where we prepare the next +``MINOR`` version, but we release ``PATCHLEVEL`` releases with selected bugfixes (including security +bugfixes) cherry-picked to the latest released ``MINOR`` line of Apache Airflow. At the moment we +release a new ``MINOR`` version we stop releasing ``PATCHLEVEL`` releases for the previous ``MINOR`` version. Review Comment: ```suggestion bugfixes) cherry-picked to the latest released ``MINOR`` line of Apache Airflow. At the moment, when we release a new ``MINOR`` version, we stop releasing ``PATCHLEVEL`` releases for the previous ``MINOR`` version. ``` ########## .github/SECURITY.rst: ########## @@ -52,3 +52,75 @@ before disclosing it publicly. The `ASF Security team's page <https://www.apache.org/security/>`_ describes how vulnerability reports are handled, and includes PGP keys if you wish to use that. + + +Handling security issues in Airflow +----------------------------------- + +The security issues in Airflow are handled by the Airflow Security Team. The team consists +of selected PMC members that are interested in looking at, discussing about and fixing the +security issues, but it can also include committers and non-committer contributors that are +not PMC members yet but have a vital interest in the security of the project and have been +approved by the PMC members in a vote. You can request to be added to the team by sending +a message to [email protected], however, the team is not open to everyone and you need +to prove that you have a vital interest in the security of the project and that you are known +and trusted by at least some members of the PMC to request to be added to the team. Requests +coming from people generally unknown to the PMC members will be rejected. + +There are certain expectations from the members of the security team: + +* They are supposed to be active in assessing, discussing about, fixing and releasing the + security issues in Airflow. While it is perfectly understood that as volunteers, we might have + periods of lower activity, prolonged lack of activity and participation will result in removal + from the team, pending PMC decision (the decision on removal can be taken by LAZY CONSENSUS among + all the PMC members on [email protected] mailing list). + +* They are not supposed to reveal the information about pending and not-fixed security issues to anyone + (including their employers) unless specifically authorised by the security team members, specifically + if diagnosing and solving the issue might involve the need of external experts - for example security + experts that are available through Airflow stakeholders. The intent about involving 3rd parties has + to be discussed and agreed up at [email protected]. + +* They have to have an `ICLA <https://www.apache.org/licenses/contributor-agreements.html>`_ signed with + Apache Software Foundation. + +* The security team members might inform 3rd parties about fixes, for example in order to asses if the fix + is solving the problem or in order to assess it's applicability to be applied by 3rd parties, as soon + as PR solving the issue is opened in the public airflow repository. Review Comment: ```suggestion as a PR solving the issue is opened in the public airflow repository. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
