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]
<mailto:[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 <http://keys.gnupg.net>
--recv-key 3F51E16F
------------------------------__------------------------
[1] http://shiningpanda.com/__shiningpanda-ci-clap-de-fin.__html
<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 jenkinsci-dev+unsubscribe@__googlegroups.com
<mailto:jenkinsci-dev%[email protected]>.
For more options, visit https://groups.google.com/d/__optout
<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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
