Recent Blog Posts

We just released Jenkins 1.638 and 1.625.2 which contain important security fixes, including a fix for the zero-day vulnerability published on Friday. Please see the security advisory for more information. Want to be kept up to date on Jenkins security releases, including advance notice on scheduled security updates? Subscribe to the jenkinsci-advisories mailing list!

Updated 2015-11-11 15:00 UTC: We have released Jenkins 1.638 and 1.625.2 which contain a fix for this vulnerability. See the security advisory for more information about these releases. Updated 2015-11-06 03:55 UTC: Included a updated mitigation script which doesn’t have a Jenkins boot race condition Earlier today we received numerous reports about a previously undisclosed " zero day" critical remote code execution vulnerability and exploit in Jenkins core. Unfortunately the vulnerability was not disclosed to us ahead of its publication so we’re still working on more thorough fix. In the meantime however, we wanted to inform you of the issue and provide a workaround which will help prevent this exploit from being used against public Jenkins installations, for future reference this issue is being tracked privately as SECURITY-218 in our issue tracker. The attack is mounted through the Jenkins CLI subsystem, so the work-around is to remove/disable the CLI support inside of the running Jenkins server. Using the following Groovy script you can disable the attack vector in your Jenkins installations by navigating to “Manage Jenkins” and then to “Script Console”, or just go to https://your-jenkins-installation/script. This only addresses the current running Jenkins process, in order to make the workaround persist between restarts of the Jenkins server, add the script below to $JENKINS_HOME/init.groovy.d/cli-shutdown.groovy (create the directory if necessary, and the file). import jenkins.*; import jenkins.model.*; import hudson.model.*; // disabled CLI access over TCP listener (separate port) def p = AgentProtocol.all() p.each { x -> if (x.name.contains("CLI")) p.remove(x) } // disable CLI access over /cli URL def removal = { lst -> lst.each { x -> if (x.getClass().name.contains("CLIAction")) lst.remove(x) } } def j = Jenkins.instance; removal(j.getExtensionList(RootAction.class)) removal(j.actions) in order to make the workaround persist between restarts of the Jenkins server, add the script below to $JENKINS_HOME/init.groovy.d/cli-shutdown.groovy (create the directory if necessary, and the file). The latest version of this script can be found in this GitHub repository. As previously announced on the jenkinsci-advisories mailing list we’re preparing a security release for this upcoming Wednesday which will include patches for both the latest and LTS lines of Jenkins core. The Jenkins Security team is working to include a fix for this previously undisclosed exploit in or before this planned security release. If you have questions about this exploit, join us in the #jenkins channel on Freenode or ask on the jenkinsci-users@ mailing list. For security researchers and hobbyists, if you believe you have found a security vulnerability in Jenkins, we have some disclosure guidelines on this wiki page which will help us mitigate any discovered issues as quickly and safely as possible. Be sure to subscribe to the jenkinsci-advisories mailing list ( jenkinsci-advisories), it’s the fastest way to get updates by the Jenkins Security team.

It is great to see the pick up of local activities through hosted JAMs. In October, the Jenkins community hosted Atlanta JAM and Bay Area JAM. Many thanks to our sponsors: Ericsson, CloudBees, Blazemeter, NetRoadShow. Here’s a summary of what was discussed: Atlanta JAM - Jenkins workflow and Docker to reduce friction in DevOps efforts. Bay Area JAM- Performance testing strategies, incorporating performance tests into Jenkins workflows and the metrics that matter most for troubleshooting and diagnosing issues. A look forward to November and December: Hacksgiving Barcelona, Spain JAM Toulouse,France JAM As usual, if you’re interested in becoming an organizer or sponsor, here’s how to get started. If you’ve heard of a great Jenkins talk out there, shoot us an email with speaker info to jenkinsci-jam@googlegroups.com so we can invite him/her to our next meetups.

Preceding some of last week’s Jenkins 2.0 discussions, there had been some threads on whether we should move Jenkins to require Java 8. The introduction of Java 8 last year brought performance improvements and highly desirable API changes, which make developing Java-based applications (arguably) much easier than before. The release was followed earlier this year by the end-of-life announcement for Java 7; the writing is on the wall: upgrade to Java 8. I wanted to answer the question "does it even make sense to force an upgrade to Java 8?" There are plenty of technical discussions that we can have in the community on whether or not this is the right approach, but my goal was to try and measure the current Jenkins install base for Java 8 preparedness. While we do not currently (to my knowledge) collect Java runtime versions in our anonymous usage statistics, we do have access logs from our mirror redirector which might provide some insight. With some access logs data, I went through the millions of requests made to Jenkins infrastructure in 2015 and started filtering out the user agent which made those requests. NOTE: This data is totally not scientific and is only meant to provide a coarse insight into what versions of Java access Jenkins web infrastructure. When Jenkins hits the mirror network, it’s not overriding the default user agent from the Java runtime, so many of the user agents for the HTTP request are something like Java/1.7.0_75. This indicates that the request came from a Java Runtime version 1.7.0 (update 75). Looking at the major JVM versions making (non-unique) requests to Jenkins infrastructure we have: 1.8.0 : 21,278,960 1.7.0 : 27,340,214 1.6.0 : 4,148,833 This breaks down across various updates as well, which is also particularly interesting to me because many of these Java versions have long since had security advisories posted against them. image:https://web.archive.org/web/*/https://agentdero.cachefly.net/continuousblog/jvm-versions-with-updates.png As I mentioned before, this is not a rigorous analysis of the access log data and is also not filtered by unique IP addresses. What I found most interesting though is that the Java 8 upgrade numbers are actually fairly strong, which I didn’t expect. I expect that piece of the pie will continue to grow. Hopefully so much so that we’re able to move over to Java 8 before the end of 2016!

This week we have featured a number of proposals for what we would like to see in " Jenkins 2.0", the vision of which is to make Jenkins users more efficient, productive and happy. We started with some more internally facing changes and have slowly progressed from the "inside-out" to today’s topic: improving the out of the box user experience. That is to say, the experience that a brand-new Jenkins user has when getting started with the server. Just to recap, so far we’ve reviewed: Introducing a policy for API deprecation Splitting Groovy out of 'core' Pipeline as code front and center User experience improvements (part one) The subject of today’s proposal is captured in JENKINS-31157 , which, like yesterday’s proposal, contains a few issues linked from it with more details. At a high level, the problem aiming to be solved is: When a new user installs Jenkins, they are greeted with the main, empty, dashboard which suggests that they "create jobs." This makes no mention of plugins or the configuration options that are relevant to helping the user make Jenkins match their needs. In past and current versions of Jenkins, if you know what you’re looking for it’s relatively easy to move around the interface. If you’ve never used Jenkins before, it can be very challenging to find your way around or even know what it is possible to do with Jenkins. The proposed changes aim to address this initial confusion: Instead of changing the post-install defaults, which may not properly represent the user’s needs, the first-time user experience should help guide the user through configuration and plugin installation quickly so they can use Jenkins for their needs. Effectively it should be as easy as possible for a user to arrive at a good configuration for their usage. Jenkins contributor Tom Fennelly, who has led this discussion on the mailing lists in the past, has posted a good prototype screencast of what some of this might entail: Providing Feedback We’re asking you to read the issues linked from JENKINS-31157 and comment and vote on those issues accordingly. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. This concludes this week’s blog series highlighting some of the Jenkins 2.0 proposals we felt were important to discuss with the broader Jenkins user audience. Many of these, and other minor proposals, can be found on the Jenkins 2.0 wiki page.

We have been featuring a few proposals this week for what " Jenkins 2.0" is going to include. Today we’ll be diving into the most noticeable changes being proposed for Jenkins 2.0: the User Experience (UX) improvements Thus far in this blog series we have reviewed proposals covering: Introducing a policy for API deprecation Splitting Groovy out of 'core' Pipeline as code front and center The UX improvements being proposed aren’t necessarily as uniform as the proposals from earlier in the week but represent a large amount of prototype and exploratory work done by folks like Tom Fennelly, Gus Reiber and a few others. Those following the dev list may have already seen some of these proposals in some of the "mega threads" that we have had discussing potential UI/UX improvements previously. The improvements proposed for 2.0 can be found under JENKINS-31156 . The most promising proposal under this issue is to update the plugin manager experience. Another very important proposal for 2.0 worth mentioning is the proposal to update UI work well on mobile devices. Providing Feedback We’re asking you to read the issues linked from JENKINS-31156 and comment and vote on those issues accordingly. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for tomorrow’s post covering the remainder of the proposed user experience changes!

We have been featuring a few proposals this week for what " Jenkins 2.0" is going to include, today we’re discussing my personal favorite, which I believe will have a tremendously positive impact for years to come (not to be too biased!): moving the "Pipeline as Code" support in Jenkins to the front and center. Thus far in this blog series we have reviewed proposals covering: Introducing a policy for API deprecation Splitting Groovy out of 'core' Today’s proposal comes from project founder Kohsuke Kawaguchi titled " Pipeline as code front and center " and represents perhaps the most important and dramatic shift we hope to make in Jenkins 2.0. This functionality has existed through the workflow plugin, which we have discussed at various Jenkins events before but if you’re not aware of some of the power behind it, check out this presentation from Jesse Glick : The proposal in JENKINS-31152 expands on the problem we aim to address: The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves. To address this, Kohsuke is proposing that we : Introduce a new subsystem in Jenkins that: lets you design a whole pipeline, not just a single linear set of tasks stores the said pipeline configuration as human-editable Jenkinsfile in your SCM makes it automatic to set up new pipelines when Jenkinsfile is added differentiates multiple branches in the same repository This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today. Kohsuke’s proposal is largely about bringing together a lot of already existing pieces together to provide a very compelling experience for new and existing users alike. I hope it is clear now why this proposal is so exciting to me. Providing Feedback We’re asking you to read the proposal in JENKINS-31152, which itself have some additional tickets linked under it, and provide feedback if you have it. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for a couple more posts covering proposals to improve the Jenkins interface and user experience!

As I mentioned in yesterday’s post, there’s been a lot of discussion recently about what " Jenkins 2.0" means. In a recent "Office Hours" session, Kohsuke Kawaguchi presented his vision for Jenkins 2.0 in a office hours session, the slides for which can be found in this Google Presentation. Roughly paraphrasing Kohsuke’s vision, 2.0 is primarily about making things better for the thousands of users out there. This week, we’ll be reviewing some key areas of the "Jenkins 2.0" proposal. Asking you, the user community, to provide feedback on these proposals, going from Jenkins internals to user interface. Thus far we’ve covered: Introducing a policy for API deprecation Today’s post involves a proposal originally from community member Jesse Glick who has proposed in JENKINS-29068 that Groovy be split out from the "core" Jenkins distribution. The linked issue expands on what the problem is here: Currently Jenkins embeds a distribution of Groovy into "core" for a variety of scripting and management tasks. This version of Groovy is locked into core in such a way that users cannot upgrade Groovy independently from Jenkins itself. If the Jenkins-bundled version were upgraded to a different major version, it may break users' custom scripts as well as plugins that use Groovy due to API changes. The proposal is relatively straight-forward and affects the many different users and use-cases for the embedded Groovy scripting support in Jenkins: For ease of maintenance and modularity it would be useful to split Jenkins' use of Groovy into a library plugin; different clients could request 1.x and 2.x simultaneously by using different versions of the library, etc. Stuff in core using Groovy that would need to either be put in this library (if infrastructure for other features) or put in another plugin depending on it (if first-class features themselves): I selected this proposal to feature on this blog, despite its rather technical underpinnings, it will affect core developers, plugin developers, power and casual users alike. I encourage everybody to read through the proposal and its potential impact on the issue tracker. Providing Feedback We’re asking you to read the proposal in JENKINS-29068 and provide feedback if you have it. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for the rest of the week as we keep with our theme of going "from the inside out" and help us make Jenkins 2.0 great!