-[Participating in Community Activities](#Participating_in_Community_Activities)
-[Communication Methods in Community](#Communication_Methods_in_Community)
-[Community News and Events](#Community_News_and_Events)
-[Community Gatherings](#Community_Gatherings)
-[Community Events](#Community_Events)
-[Feedback](#Feedback)
...
...
@@ -96,7 +95,7 @@ Find a SIG you are interested in so that you can raise questions in the right pl
If you cannot locate the SIG that you are interested in using either of the preceding methods, send a help email to community@openEuler.org. You are advised to use [Question of Development Process] as the title in the email and write down features of the SIG or project you are looking for. We will help you.
If you cannot locate the SIG that you are interested in using either of the preceding methods, send a help email to <community@openEuler.org>. You are advised to use [Question of Development Process] as the title in the email and write down features of the SIG or project you are looking for. We will help you.
...
...
@@ -104,7 +103,7 @@ Find a SIG you are interested in so that you can raise questions in the right pl
### Assigning an Issue to Yourself <a name="Assigning_an_Issue_to_Yourself"></a>
-**Finding an issue list**: Click **Issues** to find the SIG issue list (for example, the issue list address of the community team is https://gitee.com/openEuler/community/issues).
-**Finding an issue list**: Click **Issues** to find the SIG issue list (for example, the issue list address of the community team is <https://gitee.com/openEuler/community/issues>).
-**Assigning an issue**: If you want to process one of the issues, you can assign it to yourself. Enter `/assign` or `/assign @yourself` in the comment box. The robot will assign the issue to you and your name will be displayed in the owner list.
-**Discussing an issue**: Participants communicate and discuss on each issue page. You can leave your opinions in the comment box.
...
...
@@ -143,7 +142,7 @@ If you want to download, modify, build, and validate the software packages provi
The coding language, development environment, and coding conventions used by projects may vary in each SIG. If you want to know and participate in the code contribution, find the contributor guide provided by the project for developers. This guide is generally provided as the `CONTRIBUTING.md` file on the SIG home page, alternatively, you can find it in the `README.md` file of the project. (For details about how to find the repository of the project, see [Finding Your Interests](#Finding_Your_Interests).)
In addition to these files, the SIG may provide other guidance information which is located in the specific community directory of SIG or project. If you do not find any related information or have any questions, submit an issue in the SIG or send the question to the mail list of the SIG to which the project belongs. If you do not receive any response for a long time, contact community@openeuler.org.
In addition to these files, the SIG may provide other guidance information which is located in the specific community directory of SIG or project. If you do not find any related information or have any questions, submit an issue in the SIG or send the question to the mail list of the SIG to which the project belongs. If you do not receive any response for a long time, contact <community@openeuler.org>.
...
...
@@ -178,7 +177,7 @@ openEuler is an open community. We hope that all participants in the community a
**For reviewers**, it is strongly recommended that you surpass yourselves, respect each other, and promote collaboration in accordance with the [Code of Conduct](https://gitee.com/openeuler/community/blob/master/code-of-conduct.md). [The Gentle Art Of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) puts forward a series of review focuses, explaining that the review is to promote the participation of new contributors and prevent the contributors from being overwhelmed by subtle errors at the beginning. Therefore, when you review PRs, focus on the following:
**For reviewers**, it is strongly recommended that you surpass yourselves, respect each other, and promote collaboration in accordance with the [Code of Conduct](https://gitee.com/openeuler/community/blob/master/code-of-conduct.md). ["The Gentle Art Of Patch Review"](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) puts forward a series of review focuses, explaining that the review is to promote the participation of new contributors and prevent the contributors from being overwhelmed by subtle errors at the beginning. Therefore, when you review PRs, focus on the following:
+ Is the idea of the contribution reasonable?
+ Whether the contribution architecture is correct?
...
...
@@ -190,7 +189,7 @@ Note: If your PR does not draw enough attention, you can seek help through the S
### Test <a name="Test"></a>
TBD
### Packaging Community Components <a name="Packaging_Community_Components"></a>
...
...
@@ -220,14 +219,8 @@ The openEuler community supports communication through mail lists, IRC, and vide
### Community News and Events <a name="Community_News_and_Events"></a>
The information about openEuler community and technical communication meetings and other community events can be found on the [openEuler News](https://openeuler.org/en/news.html) page.
### Community Gatherings <a name="Community_Gatherings"></a>
### Community Events <a name="Community_Events"></a>
The community holds developer conferences every year. You can contact us by sending emails to <dev@openEuler.org> or sending messages to [https://openeuler.org](https://openeuler.org). Join us!
...
...
@@ -235,4 +228,4 @@ The community holds developer conferences every year. You can contact us by send
# Feedback <a name="Feedback"></a>
If you have any questions about the developer guide or the development process, please feel free to contact us (community@openEuler.org), use [Question of Development Process] as the title, and write down your questions and doubts in the email. The openEuler community operation team will try the best to answer your questions.
\ No newline at end of file
If you have any questions about the developer guide or the development process, please feel free to contact us (<community@openEuler.org>), use [Question of Development Process] as the title, and write down your questions and doubts in the email. The openEuler community operation team will try the best to answer your questions.
The openEuler community attaches great importance to the community version security. The security committee of openEuler community is responsible for receiving, investigating, and disclosing security vulnerabilities related to the community. Researchers and industry organizations working on vulnerability prevention are encouraged to report the potential security vulnerabilities in the openEuler community to the security committee. The reported security issues or vulnerabilities will be quickly analyzed and resolved by the committee.
openEuler's security system scans CVE issues and submits CVE issues to the security committee of openEuler community. The issue title of a CVE issue must start with a CVE ID, followed by a brief description of the CVE issue, for example,
## Versions Supported
The vulnerability response process supports the LTS distribution of the openEuler community and its branch versions.
**CVE-2019-11255:** CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation
## Vulnerability Handling Process
Each security vulnerability is tracked and handled by a designated person. This person is a member of the security committee of openEuler community, who is responsible for tracking, resolving, and disclosing the vulnerability. The following flowchart shows the E2E vulnerability handling process.
<h4id="itm2">Security Group Distributes CVE Issues</h4>
We hope that you can report the potential vulnerability of an openEuler product to the openEuler community and work with us to resolve and disclose the vulnerability.
The security Group will distribute the CVE issues to the related repos. CVE issues contain the following information:
+ Detailed description of the vulnerability (the following information is provided by the CVE scanning tool)
### Reporting Channel
You can send the potential security vulnerabilities of an openEuler product to the e-mail of the openEuler security team (<securities@openeuler.org>). Given that the vulnerability information is sensitive, you are advised to use the <a href="security/public_key_securities.asc" download>public GPG key</a> of the security team to encrypt the e-mail.
The information of the security team members is described as follows:
+ [PRODUCT]: Information provided by CVE, including the vendor, developer, or project, and the name of the actual software or hardware that has the vulnerability
### Reporting Content
To quickly identify and verify suspected vulnerabilities, the reporting e-mail should include but is not limited to the following content:
+ [VERSION]: Including version, release date, or any discrepancies used by vendors, developers, or projects to distinguish release versions. It can also be described with a specific version number, version range, or "all versions before / after version number or date".
+ Basic information: including the modules affected by the vulnerability, triggering conditions of the vulnerability, and impact on the system after the vulnerability is exploited.
+ Technical details: including system configuration, fault locating method, description of exploit, POC, and method and procedure of fault reproduction.
+ Suggestions on resolving the vulnerability.
+ Organization and contact information of the vulnerability reporter.
+ Reporter's possible plan for vulnerability disclosure.
+ [PROBLEMTYPE]:
### E-mail Response
We will respond to the reporting of suspected security vulnerabilities through e-mail within 48 hours and keep the reporter informed of the vulnerability handling progress.
+ [REFERENCES]: related URL and reference descriptions
+ [DESCRIPTION]: Detailed description of the vulnerability, including description of the type of attack using the vulnerability; impact of the vulnerability; software components in the software product affected by the vulnerability, any attack vector that can exploit this vulnerability
## Vulnerability Severity Assessment
The Common Vulnerability Scoring System (CYSS) is widely used in the industry to assess vulnerability severity. Currently openEuler is using CVSS v3 to assess vulnerabilities, and such assessment focuses on the impact caused by the vulnerability in a preset attack scenario. The vulnerability severity assessment covers factors such as the exploit difficulty and the impact of vulnerability exploit on the confidentiality, integrity, and availability of the product. A score will be given after these factors are assessed.
+ [ASSIGNINGCNA]: assign the name of CNA
### Assessment Criteria
The CVSS v3 adopted by the openEuler community assesses the impact of a vulnerability based on the following variables:
+ Attack vector (AV): indicating the remoteness of an attack and how to exploit this vulnerability.
+ Attack complexity (AC): describing the difficulty in executing an attack and the conditions for a successful attack.
+ User interaction (UI): determining whether the attack requires users' participation.
+ Permission required (PR): recording the level of user authorization required for a successful attack.
+ Scope (S): determining whether an attack can affect components of different permission levels.
+ Confidentiality (C): measuring the impact of unauthorized information disclosure.
+ Integrity (I): measuring the impact of information tampering.
+ Availability (A): measuring the impact on data access or services for users affected by the vulnerability.
<h4id="itm3">Handle CVE Issues</h4>
### Assessment Principles
+ The severity of a vulnerability is assessed, not the risk of the vulnerability.
+ The assessment must be based on an attack scenario where the system confidentiality, integrity, and availability are affected by a successful attack.
+ When a security vulnerability has multiple attack scenarios, the attack scenario with the highest CVSS score (that is, with the greatest impact) shall prevail in the assessment.
+ When a library that is embedded or invoked has vulnerabilities, the assessment on its vulnerability severity should be based on an attack scenario, which is determined by the usage of the library in the product.
+ When a security defect does not trigger or affect the confidentiality/integrity/availability (CIA), the CVSS score is 0.
Maintainer identifies and distributes CVE issues. Solutions to CVE problems can be provided by contributors and submitted for review by the Maintainer or Committer. When submitting, please associate with CVE ISSUE and provide complete information in Issues:
### Assessment Procedure
Perform this procedure to assess a vulnerability:
- Is it a loophole? (**Am I vulnerable?**):
+ Describe the scenarios of the problem (including software and hardware and interaction scenarios)
+ Impact and scope of impact
+ How to confirm whether the version used contains the issue
+ Set a possible attack scenario and score based on this attack scenario.
+ Identify vulnerable components and affected components.
+ Select the value of the basic assessment indicator, and perform the vulnerability impact assessment based on the exploitable indicators (attack vector, attack complexity, permission required, user interaction, and scope) and affected indicators (confidentiality, integrity, and availability).
+ How to mitigate the impact of the vulnerability (**How do I mitigate the vulnerability?**)
+ Short-term mitigation plan
+ Long-term mitigation plan: such as patch installation address, installation method, etc.
+ Detailed description of the vulnerability (the following information is provided by the CVE scanning tool)
### Scoring Difference Between National Vulnerability Database (NVD) and CVSS
The CVSS scoring is determined by a series of factors, including the version number of an affected component and how it is provided and used, as well as the platform and software compilation mode. The NVD scoring takes into account all scenarios where vulnerabilities are exploited. This assessment mode is not suitable for the open source openEuler, which is built based on the upstream community and mainly applies to server scenarios. As a result, openEuler will score all common vulnerabilities and exposures (CVEs) based on their specific impact. For the same CVE, the scoring by openEuler may be different from that by NVD.
+ [CVEID]: Must include the corresponding CVE link
+ [PRODUCT]: Information provided by CVE, including the name of the vendor, developer, or project, and the name of the actual software or hardware that has the vulnerability
+ [VERSION]: Includes version, release date, or any discrepancies used by vendors, developers, or projects to distinguish release versions. It can also be described with a specific version number, version range, or "all versions before / after version number or date".
+ [PROBLEMTYPE]:
+ [REFERENCES]: related URL links and reference descriptions
+ [DESCRIPTION]: Detailed description of the vulnerability, including: description of the type of attack using the vulnerability; impact of the vulnerability; software components in the software product affected by the vulnerability; any attack vector that can exploit this vulnerability
+ [ASSIGNINGCNA]: assign the name of CNA
<h4id="itm4">CVE Issues Management Policy</h4>
+**Fast Way**: The openEuler rating is a serious security issue. The openEuler security team will start the fast track to provide solutions to the LTS versions involved and within the life cycle.
+**Common Integration**: For security issues that are important and affect the following, you can choose the following strategies based on the severity and scope of the problem:
+ There are security problems in the official version. Depending on the problem, the selection will be affected:
+ Strategy 1: Patches are released to all LTS & community versions involved and within the life cycle
+ Strategy 2: The patch is released to the latest LTS version & community version
+ Strategy 3: Patches are incorporated into the currently developed LTS version & community version (such issues will not issue a security bulletin)
+ Security issues that have not flown into the official version: handled as a development version of ISSUE and incorporated into the current development version. Such issues do not require a security announcement;
For the security of openEuler users, the openEuler community will not discuss, confirm, or disclose the security issues of an openEuler product until the vulnerability is investigated and resolved and the security announcement is issued. After a security vulnerability is resolved, the openEuler community will release a security announcement, with information including the technical details, CVE identifier, CVSS security score, and severity level of the vulnerability, as well as the affected and fixed versions. You can subscribe to security announcements of the openEuler community on the <ahref="https://mailweb.openeuler.org/postorius/lists/sa-announce.openeuler.org/"download>sa-announce</a>.
