The big issue I've seen is when there are security issues with plugins, the plugin developer is not brought into the mix quickly enough, or at all and the person who files the issue gets tired of waiting for the issue to be fixed and just files a normal issue. Something needs to be done to involve plugin developers quickly, even if they don't have access to the security area. On Oct 7, 2014 5:23 PM, "Kohsuke Kawaguchi" <[email protected]> wrote:
> On 10/02/2014 08:59 AM, R. Tyler Croy 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. >> > > Yes, this is true, and the time it takes us to address those issues are > longer than we like. > > What we started doing (maybe about a half year ago?) was to form the > "Jenkins CERT" team, who has access to all the issues in the otherwise > private SECURITY project, has access to all the pending fixes as they are > developed, and has a dedicated private email list for discussion. > > As Stephen was saying, we didn't see the uptake in the participation to > fixing issues from people outside the usual suspects (Jesse, Stephen, > myself, etc), but the invitation is open to anyone who wants to help. The > only criteria currently is that you have the core commit access (which > means filing CLA), which comes from the fact that you'll be making changes > in the core. > > But we actually came a long way in handling them, ranging from a branching > strategy, coordinating with LTS release testing, and so on. > We also recently approved in the project meeting to get GitHub private > repos for the Jenkins CERT team. I think it'll improve our ability to > cooperate. > > I think we clearly need to document this better, though. I don't think > even you were aware of this, and that speaks something. > > > > * 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. >> > > I covered this above, it's certainly more than just myself already. Jesse > does the heavy lifting of the fixes in many cases. > > > * 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, 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. >> > > Hopefully our documenting the Jenkins CERT team bit more helps attract > vendors that are affected. Shining Panda seems to have stopped the CI > service [1], though. That's too bad. > > > The other struggle we haven't touched on is how to coordinate and deliver > security fixes to plugins. A part of this is fairly mechanical, such as > adding plugin developers to individual JIRA issues selectively. > > > > 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 >> ------------------------------------------------------ >> >> > [1] http://shiningpanda.com/shiningpanda-ci-clap-de-fin.html > -- > Kohsuke Kawaguchi http://kohsuke.org/ > > -- > 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. > -- 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.
