Submitted by abayer on Mon, 2010-08-02 07:00
As you may have noticed, thanks to the link on this and the other pages here at hudson-labs.org, the Hudson development community has recently introduced ci.hudson-labs.org, 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.
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.
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!
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.