When HAWQ team commit the fix, everyone can see the commits even no references. Will this make the security issue public if the fix is very simple ?
2017-02-10 19:05 GMT+08:00 Amy Bai <[email protected]>: > Hi hawq community, > > Please find below proposal which is to make a better channel in Apache HAWQ > community so that security vulnerabilities can be handled in a proper way. > Feel free to share your comments so that it can be improved. > > We would like to upload this proposal to Apache HAWQ wiki page > <http://hawq.incubator.apache.org> if it is good for Apache HAWQ > community > based on the feedback so that everyone can follow. > > > The proposal contains two parts: 1) the steps to report security > vulnerabilities if anyone in the community find it at first time; 2) the > way that the security vulnerabilities are handled and feedback to community > so that users can be aware of that. > > 1.The person discovering the issue, the reporter, reports the > vulnerability privately to [email protected] or > [email protected]. > > If reported to [email protected], the security team will forward > the report (without acknowledging it) to the HAWQ’s private list > <[email protected]> . > > 2.The HAWQ team sends an e-mail to the original reporter to acknowledge > the report. > > 3.The HAWQ team investigates report and either rejects it or accepts > it.If the report is rejected, the HAWQ team writes to the reporter to > explain why.If the report is accepted, the HAWQ team writes to report to > let them know it is accepted and that they are working on a fix. > > 4.The HAWQ team requests a CVE number from [email protected] by > sending an e-mail with the subject "CVE request for..." and providing a > short (one line) description of the vulnerability. More details about CVE > <https://cve.mitre.org/cve/editorial_policies/cd_abstraction.html>. > > 5.The HAWQ team agrees the fix on the HAWQ's private list > <[email protected]> . > > 6.The HAWQ team provides the reporter with a copy of the fix and a > draft vulnerability announcement for comment. > > 7.The HAWQ team agrees the fix, the announcement and the release > schedule with the reporter. Example > <http://markmail.org/message/w7mdjdxeqius7d6l> . > > 8. The HAWQ team commits the fix. No reference should be made to the > commit being related to a security vulnerability. > > 9. The HAWQ team creates a release that includes the fix. > > 10.The HAWQ team announces the release. The release announcement should > be sent to the usual mailing lists ([email protected], > [email protected], and [email protected]). > > 11.The HAWQ team announces the vulnerability. The vulnerability > announcement should be sent after the release announcement to the same > destinations as the release announcement plus the reporter, the HAWQ’s > private list <[email protected]> , > [email protected] and [email protected]. It is > strongly recommended that an appropriate reply-to (e.g. the project's user > mailing list) is set and that bcc is used for the external addressees. The > HAWQ’s security pages should also be updated. This is the first point that > any information regarding the vulnerability is made public. > > > Notes: > > a. Security mailing lists(e.g. [email protected]) should only be > used for reporting undisclosed security vulnerabilities in Apache HAWQ and > managing the process of fixing such vulnerabilities. > > We cannot accept regular bug reports or other security related > queries at these addresses. All mails sent to these addresses that does not > relate to an undisclosed security problem in an Apache HAWQ will be > ignored. > > b. All reports of vulnerabilities in running ASF services should be > sent to [email protected] only. > > c.There is not a team OpenPGP key. If you wish to encrypt your e-mail > to [email protected], please refer to reporting a vulnerability > <https://www.apache.org/security/> . > > d.There are several kinds of questions should not be send to the > security mail list. For more details, please refer to vulnerability > information section <https://www.apache.org/security/>. > > e.No information should be made public about the vulnerability until > it is formally announced at the end of this process. That means, for > example that a Jira issue must NOT be created to track the issue since that > will make the issue public. Also the messages associated with any commits > should not make ANY reference to the security nature of the commit. > > > If you don't understand how to deal with the vulnerabilities anyway, please > see https://www.apache.org/security/. > > > Regards, > > Amy > -- Best Regards, Xiang Sheng
