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
