On 2 October 2014 16:59, R. Tyler Croy <[email protected]> wrote: > I already gave Kohsuke these opinions in person yesterday, but I don't > think > this is solely his problem so I wanted to bring it up on the dev mailing > list. > > It's important to me that this is a constructive discussion and we talk > about > how we can do things better moving forward. > > IMO there's a few problems with the way we have handled security > advisories in the > past: > > * Low feedback times to researchers who discover vulnerabilities. One > example > I found in core, the submitter of the SECURITY issue did not get > feedback > for one calendar month on the issue. This is a problem as some security > researchers are of the opinion that if they don't hear back from a > vendor > in a timely manner, they should disclose to the public in order to get > the > hole closed. >
Yep. No disagreement that this is an issue. > > * Lack of transparency to the Jenkins community into the SECURITY > project in > JIRA. I'm not of the opinion that SECURITY should be a publicly > visible > project in JIRA but we *must* come up with some criteria to give people > access that prevents Kohsuke from being the only one paying attention. > There is a mailing list of people... they all seem rather quiet a lot of the time... granted I am one of those people too... so tarring myself with the same brush > > * Vendor notification, by virtue of Kohsuke being a Cloudbees employee > they > were aware and able to update in a timely manner, but I do not believe > we > communicated with vendors like Shining Panda CI, If it is critical to them, then they should ask to be part of the security-cert list. I do not see anyone stopping responsible parties from being advised. OTOH if they are relying on us to do all the donkey work and then complaining that we are a little bit more prepared because of that donkey work... I have slightly less sympathy. In general I find the community involvement on the jenkins-cert list less vocal than I would like to see. There are some things I would expect to see more vocal responses to... > who rely on publicly > facing Jenkins instances, that there was a big release coming before > it was > publicly announced. I don't think we should tell all companies using > Jenkins before a public announcement, but I do think that maintaining a > list of companies and organizations that run Jenkins as a public > service > should get a few hours of lead time. > If you are on the cert list you would have had all of the LTS RC testing as foreknowledge... at least for the CVE-2014-3666 (if you have not upgraded your Jenkins to a version with the fix for that by the time you read this... stop what you are doing and upgrade it already) > > > I have some ideas on what we can do to improve this. As some of you may > know I > work for Lookout, a mobile security company, and I can probably rope in > members > of our research team if need be to provide insight from the security > research > perspective, the ones disclosing vulnerabilities, if you all have questions > there. > > > - R. Tyler Croy > > ------------------------------------------------------ > Code: <https://github.com/rtyler> > Chatter: <https://twitter.com/agentdero> > > % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F > ------------------------------------------------------ > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
