hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amy Bai <a...@pivotal.io>
Subject Proposal for handling of security vulnerabilities in Apache HAWQ
Date Fri, 10 Feb 2017 11:05:24 GMT
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 private@hawq.incubator.apache.org or

        If reported to security@apache.org, the security team will forward
the report (without acknowledging it) to the HAWQ’s private list
<private@hawq.incubator.apache.org> .

    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 security@apache.org 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

    5.The HAWQ team agrees the fix on the HAWQ's private list
<private@hawq.incubator.apache.org> .

    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 (dev@hawq.incubator.apache.org,
user@hawq.incubator.apache.org, and announce@apache.org).

    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 <private@hawq.incubator.apache.org> ,
oss-security@lists.openwall.com and bugtraq@securityfocus.com. 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.


     a. Security mailing lists(e.g. security@apache.org) 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 root@apache.org only.

     c.There is not a team OpenPGP key. If you wish to encrypt your e-mail
to security@apache.org, 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/.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message