You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hawq.apache.org by Amy Bai <ab...@pivotal.io> on 2017/02/10 11:05:24 UTC
Proposal for handling of security vulnerabilities in Apache HAWQ
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
security@apache.org.
If reported to security@apache.org, the security team will forward
the report (without acknowledging it) to the HAWQ’s private list
<pr...@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
<https://cve.mitre.org/cve/editorial_policies/cd_abstraction.html>.
5.The HAWQ team agrees the fix on the HAWQ's private list
<pr...@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 <pr...@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.
Notes:
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/.
Regards,
Amy
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Hi Amy!
first of all -- thanks for the taking a stab at this. In general, for a young
community like yourself you probably would want to keep this process
as simple and close to an ASF one as possible:
https://www.apache.org/security/#reporting-a-vulnerability
A few comments in-line:
On Fri, Feb 10, 2017 at 3:05 AM, Amy Bai <ab...@pivotal.io> wrote:
> The proposal contains two parts: 1) the steps to report security
> vulnerabilities if anyone in the community find it at first time;
Keep in mind that while you absolutely should suggest preferred
ways of how your community would expect to receive those kinds
of security reports be prepared to get them via all sorts of weird
channels.
IOW, don't make any part of your handling process be dependent
on how things are reported.
With that in mind, please make sure to document the steps you
expect reporters to follow and make sure to link that page from:
https://www.apache.org/security/projects.html
(you can let me know what the link is and I'll do the update to
the above page).
If you want a good example of what the page needs to look
like, here's a few:
http://tomcat.apache.org/security.html
http://kafka.apache.org/project-security.html
> 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
> security@apache.org.
>
> If reported to security@apache.org, the security team will forward
> the report (without acknowledging it) to the HAWQ’s private list .
>
> 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.
I would suggest that if the team decides that the reported problem does NOT
pose a security risk you still need to create a JIRA for that and post
an explanation
there.
> 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 .
>
> 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 .
>
> 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 , 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.
So far this looks exactly what:
https://www.apache.org/security/#vulnerability-handling
https://www.apache.org/security/committers.html
any reason you would want to maintain your own version of these steps?
Why not just link to these documents.
Now, of course, the community here still has to agree to play by those
rules -- but that's a separate issue.
Thanks,
Roman.
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Amy Bai <ab...@pivotal.io>.
Hi Roman,
Thanks for your comments. I have added HAWQ security reports section in HAWQ
wiki page
<https://cwiki.apache.org/confluence/display/HAWQ/Contributing+to+HAWQ>according
to your comments. Please feel free to review the changes and add the
security mailing list for hawq in
https://www.apache.org/security/projects.html.
Regards,
Amy
On Mon, Feb 13, 2017 at 9:20 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Feb 10, 2017 at 5:35 PM, stanly sheng <st...@gmail.com>
> wrote:
> > 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 ?
>
> True, but that's the only way to deal with this. This is why you MUST
> commit
> and immediately do a release. In fact, your release artifacts should really
> be staged when you're doing a commit so you can push a release out ASAP.
>
> Thanks,
> Roman.
>
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Amy Bai <ab...@pivotal.io>.
Hi Roman,
Thanks for your comments. I have added HAWQ security reports section in HAWQ
wiki page
<https://cwiki.apache.org/confluence/display/HAWQ/Contributing+to+HAWQ>according
to your comments. Please feel free to review the changes and add the
security mailing list for hawq in
https://www.apache.org/security/projects.html.
Regards,
Amy
On Mon, Feb 13, 2017 at 9:20 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Feb 10, 2017 at 5:35 PM, stanly sheng <st...@gmail.com>
> wrote:
> > 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 ?
>
> True, but that's the only way to deal with this. This is why you MUST
> commit
> and immediately do a release. In fact, your release artifacts should really
> be staged when you're doing a commit so you can push a release out ASAP.
>
> Thanks,
> Roman.
>
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Feb 10, 2017 at 5:35 PM, stanly sheng <st...@gmail.com> wrote:
> 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 ?
True, but that's the only way to deal with this. This is why you MUST commit
and immediately do a release. In fact, your release artifacts should really
be staged when you're doing a commit so you can push a release out ASAP.
Thanks,
Roman.
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Feb 10, 2017 at 5:35 PM, stanly sheng <st...@gmail.com> wrote:
> 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 ?
True, but that's the only way to deal with this. This is why you MUST commit
and immediately do a release. In fact, your release artifacts should really
be staged when you're doing a commit so you can push a release out ASAP.
Thanks,
Roman.
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by stanly sheng <st...@gmail.com>.
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 <ab...@pivotal.io>:
> 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
> security@apache.org.
>
> If reported to security@apache.org, the security team will forward
> the report (without acknowledging it) to the HAWQ’s private list
> <pr...@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
> <https://cve.mitre.org/cve/editorial_policies/cd_abstraction.html>.
>
> 5.The HAWQ team agrees the fix on the HAWQ's private list
> <pr...@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 <pr...@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.
>
>
> Notes:
>
> 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/.
>
>
> Regards,
>
> Amy
>
--
Best Regards,
Xiang Sheng
Re: Proposal for handling of security vulnerabilities in Apache HAWQ
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Hi Amy!
first of all -- thanks for the taking a stab at this. In general, for a young
community like yourself you probably would want to keep this process
as simple and close to an ASF one as possible:
https://www.apache.org/security/#reporting-a-vulnerability
A few comments in-line:
On Fri, Feb 10, 2017 at 3:05 AM, Amy Bai <ab...@pivotal.io> wrote:
> The proposal contains two parts: 1) the steps to report security
> vulnerabilities if anyone in the community find it at first time;
Keep in mind that while you absolutely should suggest preferred
ways of how your community would expect to receive those kinds
of security reports be prepared to get them via all sorts of weird
channels.
IOW, don't make any part of your handling process be dependent
on how things are reported.
With that in mind, please make sure to document the steps you
expect reporters to follow and make sure to link that page from:
https://www.apache.org/security/projects.html
(you can let me know what the link is and I'll do the update to
the above page).
If you want a good example of what the page needs to look
like, here's a few:
http://tomcat.apache.org/security.html
http://kafka.apache.org/project-security.html
> 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
> security@apache.org.
>
> If reported to security@apache.org, the security team will forward
> the report (without acknowledging it) to the HAWQ’s private list .
>
> 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.
I would suggest that if the team decides that the reported problem does NOT
pose a security risk you still need to create a JIRA for that and post
an explanation
there.
> 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 .
>
> 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 .
>
> 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 , 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.
So far this looks exactly what:
https://www.apache.org/security/#vulnerability-handling
https://www.apache.org/security/committers.html
any reason you would want to maintain your own version of these steps?
Why not just link to these documents.
Now, of course, the community here still has to agree to play by those
rules -- but that's a separate issue.
Thanks,
Roman.