Thanks for the detailed response Daniel.
>And even once the issue is fixed, there's overhead in coordinating release of the fix, writing and publishing the advisory, blog, and warnings, sending notifications, etc.
Perhaps we could create a type of Certified or Supported tag to plugins. Plug-ins under this tag/category would
* Use an ~recent LTS version
* Have security issues patches applied by the security team in 15 running days if there is no response from the maintainer
* Be released by the security team if a patch has been approved/reviewed but there was no response or availability of the plug-in maintainer
As a plugin developer, I would feel bad for others pushing changes and releasing the plug-in without notifying me; but if we had this category, then I think users/build engineers would favour to install plug-ins listed there, and as a plugin maintainer I would accept the items listed above as a way to show users updates would be released in a faster way.
Maybe this, combined with number of installations, could be a better indicator of how well maintained and production-ready the plug-in is (e.g. I would probably submit a plug-in to this category after I had confidence its API was ready and I had enough tests, fixed enough bugs, etc). Just food for thought.
>It's not enough to just assign an issue in SECURITY to plugin maintainers
Using what was suggested above, we would still assign the issue to them, but the security team could also work on a fix and propose the fix. Then the author of the plug-in could simply approve or provide further feedback.
> (...) (well, for me -- maybe I just suck at this)
I believe we worked on the active-choices plug-in issue, where we had to include the security script plug-in (SECURITY-255?). So having worked directly with you in the Jenkins security team, and having already dealt with CVE's in other libraries/projects in some companies, I must say that from the moment the issue was assigned to me, until we had the review, release schedule, and finally the review, everything was very professional and simple - from a plugin maintainer POV.
I felt quite bad for having a security issue in my code, but at no moment I felt like I was being blamed or pressured to release it as fast as possible (just to not disclose or leak anything about the issue at hand and carefully test the fix :). So kudos and thank you and all those involved in the security team! You definitely do not suck at this.
Not the most active contributor, but will take a look to see if I can enlist, and maybe try to help in some way :)
Cheers
Bruno
________________________________
From: Daniel Beck <
m...@beckweb.net>
To:
jenkin...@googlegroups.com
Sent: Tuesday, 11 April 2017 10:55 PM
Subject: Re: Yesterday's security advisory
--
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-de...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/6EA3819C-6BB0-4FB6-898F-DB09549F61B2%40beckweb.net.
For more options, visit
https://groups.google.com/d/optout.