Dogfooding Hudson - We're Looking for Slaves!

As you may have noticed, thanks to the link on this and the other pages here at, the Hudson development community has recently introduced, the official Hudson-on-Hudson instance. We're currently building Hudson proper, the Hudson core RC branch, individual builds for the various Hudson plugins and Gerrit, as well as various libraries and infrastructure jobs Hudson depends on.

Hudson 1.368 Released!

Regular readers will recognize that I've been slacking off quite a bit lately with my release announcements, my apologies. With the release of 1.368 on Sunday, which fixed a few fairly important bugs, I figured I'd dusty off my blogging fedora and give this a shot.

This release has three bug fixes in it which were causing some issues for some users, particularly those deploying Hudson inside the recently released Tomcat 7.0 (see issue 6738).

Hudson users utilizing the JDK auto-installation feature between different platforms may have been affected by issue 6880 which was also fixed in this release.

Bringing up the rear is the fix to issue 7004 which detailed a few discrepencies between the /buildWithParameters and the /build remote APIs.

If you're not affected by these issues, you may want to wait for the soon-to-be-released 1.369 which has even more juicy bug fixes in it (with a dash of enhancements) to upgrade.

Continuous Deployment on the new Digg

In my capacity as Build Guy at Digg, I've written up a blog post on our new continuous deployment/code review/pre-tested commit workflow. We're using a combination of Hudson, Git and Gerrit, Selenium and more to make sure that every change going to Digg's new site has been thoroughly tested.

Read the whole post, with all the juicy details over on Digg's Technology Blog!

Security Fix! Hudson 1.365 Released

The Hudson team has released Hudson 1.365 which contains a critical security fix! A security advisory released yesterday by InfraDNA goes on to explain the hole with more detail:

This vulnerability allows an attacker to read arbitrary files in the server file system whose path names are known, by sending malicious HTTP GET requests. While such access is still subject to the normal access control enforced by the operating system, Hudson can still leak "secrets" possessed by Hudson

The vulnerability inside of Hudson affects Hudson instances running inside the embedded Winstone container, instances behind Glasshfish or Jetty (for example) are not subject to this vulnerability. Instances running behind a reverse proxy such as mod_proxy or Nginx.

Hudson system administrators should subscribe to either the security advisories RSS feed or the advisories@ mailing list

You can go grab the latest .war file straight from our OSL mirror or if you're using a native package, use your package manager to upgrade.

So you've found a vulnerability, now what?

Hudson, like all web applications, is not immune from vulnerabilities that could open up attack vectors for malicious use. What puts Hudson in a league of its own compared to others is its ability to execute arbitrary commands on slave machines, or in the case of the EC2 plugin, execute arbitrary commands "in the cloud." In light of all this, Hudson is quite secure and offers a variety of mechanisms to reduce the potential for exploits.

Despite Hudson's security track record, you've managed to find a vulnerability in Hudson, and decide to don your white hat and inform the Hudson team. First off, let me commend you on your brilliant decision to report the vulnerability, you are truly a leader among men.

Generally immediate public disclosure of vulnerabilities is frowned upon as it doesn't give us much time to react, investigate and patch the hole. For this reason there is the "SECURITY" project in Hudson's JIRA. The SECURITY project is a more locked down section of JIRA than the other projects and allows you to submit issues and have them reviewed by the Hudson core developers who can assess the vulnerability.