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.
