On 02/03/18 03:23, Huxing Zhang wrote: > Hi Mark, > > Thanks for the information. > In that case, I am +1 for secur...@dubbo.apache.org. > > Further question: if the venerability report is related to some > project Dubbo depends on, what kind of action should Dubbo security > team take? > > Should we accepted, update to the fixed version, and then announce it?
Typically (the process can and does vary based on circumstances) we'd redirect the reporter to the project with the vulnerability. Once that project has fixed it, we'd update the dependency. Once that project announces the vulnerability with a CVE reference, we'd announce that we were vulnerable using the same CVE reference. Figuring out where the root cause lies for a given vulnerability - particularly across projects - can get 'interesting'. On a related topic it is perfectly possible to depend on a project that has a known vulnerability without being vulnerable (e.g. because we don't use the affected functionality). Mark > > On Thu, Mar 1, 2018 at 6:24 PM, Mark Thomas <ma...@apache.org> wrote: >> On 01/03/18 02:59, Echo Wang wrote: >>>> >>>> 1) priv...@dubbo.apache.org >>> >>> >>> +1 >> >> With my mentor hat on: >> >> No. >> >> All security vulnerability reports need to be visible to the ASF >> security team and if they are reported directly to the private@ list >> that doesn't happen. >> >> The podling needs to choose which of the following addresses it wishes >> to publish for security reports and then make sure that the chosen >> address is clearly signposted: >> >> 1. secur...@dubbo.apache.org >> 2. secur...@apache.org >> >> If the podling chooses the first, the podling will need to request that >> that list is set up by INFRA. All security@<project>.apache.org lists >> are automatically copied to the ASF security team. >> >> If the podling chooses firstname.lastname@example.org (the ASF wide security address), >> that team will then forward reports to priv...@dubbo.apache.org >> >> Now is probably also a good time for the project community to review the >> security vulnerability handling process: >> >> http://www.apache.org/security/committers.html >> >> Mark >