June 20, 2018·4 min read·engineeringrubymaintenancesecurity

Ruby confirms the end of support for the 2.2 series

The June 20 notice confirms that Ruby 2.2 support ended on March 31. Its maintenance history explains why the final patch is not a substitute for moving to a supported branch.

A working Ruby application can outlive the maintenance commitment of its interpreter. The Ruby team's June 20, 2018 announcement confirms that all support for Ruby 2.2 ended on March 31, 2018. June 20 is the publication date of the notice. It does not extend the branch's lifetime into June. The project will no longer backport bug fixes or security fixes to 2.2, and it will not issue another patch release.

I find Ruby approachable for larger object-oriented applications, particularly compared with traditional Perl. That readability is a reason to maintain an application carefully. It does not remove the interpreter's dependence on an active maintenance branch.

Security maintenance already restricted the branch

The transition began a year earlier. The Ruby 2.2.7 announcement on March 28, 2017 reported about 70 bug fixes and then ended normal maintenance. Subsequent backports would cover security fixes only. The team scheduled that security phase for one year and recommended planning an upgrade.

Normal maintenance and security maintenance therefore offered different promises. An application remaining on 2.2 after that transition could still receive a security patch, but an ordinary defect no longer qualified for a backport. The absence of a fix on that branch did not imply that the defect was unimportant to its users. It followed the announced restriction on what the maintainers would carry back.

This history also explains why an upgrade should not depend on a new feature becoming attractive. The branch could reach its maintenance deadline while an application remained satisfactory in daily use. Its functionality and the project's willingness to maintain its runtime were already separate questions.

The final patch had specific security work to do

Ruby 2.2.10, released on March 28, 2018, included several security fixes. Its announcement expected it to be the last release of the series, with a narrow exception for a serious regression in that release. It repeated that security maintenance would finish at the end of March.

That release is useful evidence of what the remaining maintenance covered. Its advisories concern bundled libraries as well as the interpreter's string handling. A program does not need to change its own Ruby source to benefit from a correction in those components. Conversely, leaving the program untouched does not establish that the runtime remains safe to deploy.

The WEBrick response-splitting advisory describes a failure involving external input inserted unchanged into an HTTP response. Newline characters could make a client interpret the header as finished and accept injected response content. Ruby 2.2.9 and earlier were among the affected versions.

This is a conditional vulnerability, not a claim that every application using an affected interpreter exposes the same attack. The response must contain the attacker-controlled input in the relevant way. Nevertheless, the correction belongs in the bundled HTTP implementation, so the branch needs someone to supply it to applications that depend on that implementation.

A different boundary appears in CVE-2018-6914. The tmpdir method Dir.mktmpdir accepted a directory-name prefix containing relative directory components such as ../. If a program used external input as that prefix, inappropriate permissions or process privileges could permit creation in unintended locations. The tempfile library was also affected because it used tmpdir internally.

This example makes the surrounding application relevant without transferring the entire problem to application code. The input path and permissions affect exposure, while the library correction addresses the unsafe handling of that prefix. Ruby 2.2.9 and earlier appear in this advisory too. The final patch supplied fixes for these known issues before maintenance closed.

Choosing a branch means choosing its maintenance phase

The June notice recommends Ruby 2.5 or 2.4. Both are in normal maintenance at this date, with ordinary bug-fix backports and urgent releases for critical security issues. Ruby 2.3 remains in security maintenance, so it receives security fixes but not ordinary bug fixes. These are materially different destinations for an application leaving 2.2.

The March patch announcements illustrate the distinction in available releases. Ruby 2.4.4 and Ruby 2.5.1 both include bug fixes and security fixes. They also link the WEBrick and temporary-file advisories addressed in the final 2.2 release. A supported series carries a broader ongoing maintenance commitment even when a particular security correction appears across several branches on the same day.

I regard the support phase as part of the runtime choice for a long-lived application. Ruby's readable syntax helps with understanding application behavior, but it cannot provide future backports. Installing 2.2.10 addresses the fixes documented in that release. Moving to a maintained series establishes a route for subsequent project fixes, which the closed 2.2 branch no longer offers.