(replies inline) On Thu, 02 Oct 2014, Stephen Connolly wrote:
> 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. Do you have any ideas on how we can improve the feedback times? Is it just a matter of getting more people involved in the SECURITY project? > > * 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 Here I was thinking I was on, or knew of, every Jenkins mailing list. Is there another list I'm not aware where security issues are discussed? On a related note, how are plugin developers who maintain plugins which have vulnerabilities disclosed against them looped into these conversations? > > * 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. See previous comments about non-public lists. I'm not sure we need to do any donkey work to feed updates to vendors relying on Jenkins, I think having a process where somebody can sign up for pre-release notifications for public Jenkins instances would be valuable. I would imagine that the Shining Panda folks, OpenStack, FreeBSD, ASF and a number of other organizations would gladly fill out a form to subscribe to early access to security notifications or fixes. > > 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) - R. Tyler Croy ------------------------------------------------------ Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F ------------------------------------------------------
pgppVg8ARWHMB.pgp
Description: PGP signature
