On Mon, Jan 18, 2010 at 4:52 PM, Santiago Gala <[email protected]>wrote:
> 2010/1/18 ๏̯͡๏ Jasvir Nagra <[email protected]>: > > Hi, > > > > I have some questions regarding our procedures for responsible disclosure > of > > security bugs in Shindig. Instructions from Apache on how to disclose > > security issues in a project are given here: > > http://apache.org/security/committers.html. > > > > 1. Does Shindig have a private list of individuals who respond to > security > > issues? > > If it is not there I think we will need one after promotion to TLP. > I'm not sure if currently we are covered by the generic incubator > security, or just have no representatives in the respective security > lists. I used to be in some of the security lists due to effort in > portals.apache.org. I'm not sure anymore if I'm there. But > infrastructure should now. > > > 2. Is there a published list of past security issues so that people > > deploying Shindig can ensure their versions are patched against known > > security bugs? > > > > Anecdotally, Shindig security issues emailed to [email protected] have > > fallen through the cracks in the past. I'd like us to adopt a policy > which > > ensures that all reported vulnerabilities are eventually fixed and > disclosed > > Do you have concrete examples? The typical policy is sending email to > [email protected], where it will be dispatched to the appropriate > security lists if needed, or just forwarded to private if it is not so > sensitive.... > Just one concrete one - there was an bug with how features were tamed and exposed to cajoled gadgets. The issue was sent to [email protected]. Come to think of it now - it may have made it to shindig-private. I am mostly looking for clarification on what the procedure should be and to ensure its in working order. > > I agree that having private issue reports is a good part of it, but > omitting the use of the standard security infrastructure can have bad > consequences too, such as the security alert not propagating > eventually to all the required parties. > > I would keep external tools out of the loop, and even avoid issue > trackers for sensitive security info. A patch inlined in a text email > is usually enough. In any case, for security rreports coming from, > say, linux distributions sometimes the private issue is already there, > and we get a summary of it. > That works for me. > > > and which gives those who deploy Shindig to have a reasonable amount of > time > > to update. The documentation for JIRA suggests that it can be configured > to > > create private security issues but > > http://issues.apache.org/jira/browse/SHINDIG is not configured this way. > > For security patches under review, the codereview tool supports keeping > an > > issue private to the creator and reviewer until the patch has been > > submitted. > > > > Regards > > Jasvir > > >
