unsubscribe

["NADELLA, RAO S" <rn...@att.com>]

unsubscribe

-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Sunday, February 12, 2017 5:20 PM
To: user@hawq.incubator.apache.org
Cc: dev@hawq.incubator.apache.org
Subject: Re: Proposal for handling of security vulnerabilities in Apache HAWQ

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.