Feature #12328: Show warnings about vulnerable and no longer supported Ruby versions.

• Status: Third Party's Issue
• Assignee: -
• Target version: -

[Cezary (Cezary Baginski)]

Problem

Users are often still using unsupported Ruby versions and developers and unknowingly supporting them.

Impact

Developers and maintainers are often "forced" to work extremely hard and support outdated Rubies in fear of backlash from the community. Also, it may take years until projects can comfortably adopt new Ruby features (e.g. Ruby 2.3 features).

Opportunity

Ruby now has "somewhat" SemVer-compatible versioning. This may help promote newer Ruby features without users being scared of migration headaches.

Suggestion

The last release of every unsupported Ruby should show a warning that upgrading Ruby is highly recommended.

Implementation

This could be turned off depending on the warning level. End-users don't really need to see the warning during runtime. (It's more important for developers and maintainers to know first, and adding extra output by default would break Ruby API).

Alternatives

a) The packaging (OS, distribution, RVM, rbenv, Ruby build system) could show the warning upon installation or building. But since this is usually automated, few developers and users would get a chance to see the warning.
b) News updates on ruby-lang.org are extremely helpful, but sadly not read or tracked often enough by users and developers.

Examples

Example of this working in practice (for a user):

1. User installs latest Ruby 1.8.7
2. Ruby is in verbose mode or the warning level is set.
3. User runs their application.
4. User sees a warning that Ruby 1.8.7 is no longer supported and that migrating to Ruby 2.2 is recommended. (With possible link to post on ruby-lang.org).
5. User can upgrade to a newer Ruby or turn off warnings

Example of this working in practice (for a developer/maintainer):

1. Developer uses tool to install Ruby during development/testing
2. Tool installs latest Ruby at given version (e.g. latest patch-level of Ruby 1.9.3).
3. Developer has ruby warnings enabled.
4. Developer sees the warning about Ruby no longer supported (EOL).
5. Developer updates codebase (removing old code, using newer language features) and documentation.
6. Developer releases new version of their library which drops support for Ruby 1.9.3.
7. User cannot update library until they upgrade their version of Ruby to one supported by library.
8. User and Developer can discuss backporting options to ease migration.
9. Either user upgrades to newer Ruby (so Developer has more time and fun to work on new features), or Developer gets appreciated for hard work to support outdated Ruby.

Obstacles

Some software maintainers are very disturbed when their builds/tests for outdated Rubies fail. Even if the reason is a good one and doesn't affect end-users. I don't know how to educate and encourage them in a polite and effective way.

References:

My draft/rant about how backward-compatibility hurts the community: https://gist.github.com/e2/ac32569852cbd31f7da637500174d907 (feedback and improvements are most welcome, even if non-technical!)

[nobu (Nobuyoshi Nakada)]

I doubt that users/developers will install latest versions.
We often see the tickets for older releases.

[hsbt (Hiroshi SHIBATA)]

I'm also maintaining to ruby-build.

We have the plan to warn to EOLed version of Ruby. ref. https://github.com/rbenv/ruby-build/issues/742

But no one implements this feature. If you submit patch to ruby-build, I will merge it :)

[Cezary (Cezary Baginski)]

Migrating from Ruby 1.9.3 to Ruby 2.2 is trivial.
But, people still remember that moving from Ruby 1.8.7 to 1.9.3 was difficult and risky.

Ruby is used for so many important projects nowadays. People should be educated to upgrade Ruby more often.
When people don't learn to upgrade, library maintainers get angry at other developers for using newer features.
Also, many people mistakenly think that "security patches only" means "supported".
So even a warning just for "spreading news" among developers is a big improvement.

Would expiry dates make sense?

E.g. Ruby 2.0.0-p648 (December 16th 2015) could have a "hidden" warning that would have become active after February 24th 2016.
So in January 2016 - no warning. After February 2016 warning is always shown.

Is this a good idea? Or should Ruby output be 100% unaffected by system date?

[normalperson (Eric Wong)]

[e-mail] wrote:

Would expiry dates make sense?

E.g. Ruby 2.0.0-p648 (December 16th 2015) could have a "hidden" warning that would have become active after February 24th 2016.
So in January 2016 - no warning. After February 2016 warning is always shown.

Is this a good idea? Or should Ruby output be 100% unaffected by system date?

Expiry is a bad idea. Not every security bug (even major
ones) affect everyone using it; and some machines are completely
disconnected from the Internet and will never see external/bad
inputs.

Sometimes, I even use things like the datefudge command to
override system time for testing compatibility such as time
overflows.

I don't want a nanny scripting language.

[jeremyevans0 (Jeremy Evans)]

I am against ruby emitting warnings just because it thinks there may be a newer ruby version available.

Cezary, if you want to only support newer versions of ruby in your gems, then just start using the newer features and set required_ruby_version in the gemspec as appropriate. If you are getting backlash from the community in doing so, the solution is not to modify the interpreter, but to stand your ground and tell the users that want to use your library on older ruby versions to fork the library.

Likewise, for other libraries that value backwards compatibility, you are free to fork the library and update it so that it only works on recent ruby releases. Then users of those libraries can decide to switch to your fork if they share your values.

IMO, dropping support for previous ruby releases is just a cost-benefit calculation. The benefit of dropping support for older rubies is the ability to use newer, non-backwards compatible ruby features (e.g. keyword arguments, Module#prepend), and the cost is that users that are forced to use older ruby versions are no longer able to use newer versions of the library. I think it's presumptuous to assume that just because you find the benefits outweigh the costs for your library, that all maintainers of other libraries would feel the same way about their libraries.

[Cezary (Cezary Baginski)]

Eric Wong wrote:

I don't want a nanny scripting language.

Thank you, Eric. I don't either. I agree expiry is a bad idea. Especially if the Ruby-core team ever decides to change dates.

You helped me realize some people are fully aware they're patching an unsupported Ruby version. Because they have no other choice.

So I thought about checking RUBY_VERSION+RUBY_PATCHLEVEL instead.(Only the last official patch would show a warning).
That way, if custom patches are added, the warnings won't show.
And distro/custom builds won't be affected either.

The problem is: only people who'd have those exact patch-level versions would see the message.

[Cezary (Cezary Baginski)]

TL;DR - I'm listing real-life situations such warnings would address. Mostly about how people behave and what they expect. Just to demonstrate how important and useful such warnings could be.

Jeremy Evans wrote:

I am against ruby emitting warnings just because it thinks there may be a newer ruby version available.

It's not about warning that e.g. Ruby 2.2.4 may be outdated, but that 2.1 will never get another bug fix (except for security).

A warning earlier is better than any "breakage" later. I agree warnings can be annoying. Then again, either people want important warnings (and this one important), or they can turn them off anyway with RUBY_OPT.

the solution is not to modify the interpreter, but to stand your ground and tell the users (...) to fork the library.

I agree about standing ground. It just is a huge emotional and time commitment to explain to every angry person one at a time. I probably just have to find better ways of explaining things.

Likewise, (...) you are free to fork the library and update it so that it only works on recent ruby releases.

That's true. I actually wish I'd done that earlier in some cases.

IMO, dropping support for previous ruby releases is just a cost-benefit calculation.

I agree. It's that the users complaining aren't usually making that calculation rationally. They don't assess the actual costs.

People with genuine needs ask for backports. (Which I don't mind). But they don't mindlessly upgrade every library expecting their Ruby to be supported, either. Upgrading anything is actually very dangerous in such situations.

Use cases for warnings:

1. Library maintainers with bad assumptions like "Ruby < 2.2 is still officially supported" or "Ruby doesn't follow SemVer" or "Ruby 2.2 is only 'recommended'" or "security fixes mean it's still supported" or "a Ruby version is part of a gem's API", etc. A Ruby warning helps explain that a broken Ci build is just a missing long-overdue Ruby upgrade. I'm happy to support urgent bugfixes being backported. I understand business needs. And people with those needs are usually very reasonable anyway, so they never complain anyway.

2. Users using vulnerable versions of Ruby who don't even know their version is vulnerable. To them, it's not just about new features or benefits - they simply get angry too if even their ancient Ruby 1.9.3 "no longer works". So what I don't have is some "official" statement explaining: "Ruby < 2.2 is not supported. Security patches are provided, but only as a last-resort measure. This means it is ok for developers to drop support for Ruby < 2.2, unless they have clients who's businesses need access to earlier versions while migrating. Migration should be straight-forward in most cases." It isn't like e.g. support for Ruby 1.9.3 was dropped suddenly yesterday.

3. The biggest danger is e.g. people building services with outdated+vulnerable Ruby versions from older virtual machine images/containers. I think this is more important than any "developer inconvenience" when working with already outdated Rubies. IMHO sticking to only supported Ruby versions actually shows professionalism in the Ruby community, even if it's "just" a warning.

4. Urgency. A warning (or deprecation) can be dismissed or turned off without taking any other action. Meanwhile, a sudden bug or misscommunicated version dependency causes a lot of stress and unplanned work. If I implement warnings/checking as part of my library, every "user affected" is an hour-long argument. Their reasoning is: "if Ruby isn't showing a warning, the library developer is just making things up and causing unnecessary problems".

5. Bugs in Ruby are the hardest to debug. They're just very time consuming if they occur. It's always the library that's suspect first, not an outdated Ruby version. So by staying up to date, professionals can avoid many hours wasted tracing "already-fixed-bugs" in their outdated Rubies.

6. "Complaint chain". Maintainers don't like users complaining so they prefer "everything to be supported". Same with developers - they don't like maintainers complaining. (But with a warning in Ruby, there's no "surprise"). This means everyone ends up using 1.8.7 until there's no other option but upgrading. (So it can take many years until developers can start using Ruby 2.3-only features without reimplmenting them also in "1.8.7-compatible" code).

7. Understanding versioning and dependencies takes advanced skills. Most users don't have those. (And it's why I don't blame those "angry" maintainers). It's more practical to show a warning than to expect developers to accurately declare versions without a single mistake. (It's very hard to test and there are no good tools to help, either). Upgrading Ruby simply helps solve those issues, because there's only "one version of Ruby supported at a time".

8. The whole idea of supporting "many interpreter versions" with one codebase is something exotic. E.g. you don't expect all unmodified Python 2.x sources to work on Python 3.x. Even today, you can see most projects "confused" about how to treat the existence of multiple Rubies: 1.9.3, 2.0, 2.1, 2.2, 2.3. That's already "5 versions" of Ruby to support. Some projects still insist on supporting 1.8.7. In a library codebase that looks ok. But to test it all, you need a build matrix 5^^X (X = factors to test on a single version). And that's not even counting patch-level versions of dependencies.

9. Having no more than "two official Rubies" helps everyone. And it's not "official" if "just" a library owner like me says so. It isn't "ok" to use Ruby < 2.2. It's a potentially dangerous business situation already. It's like driving a broken car. If life is tough, there may be no other choice. But if you don't know you're driving a broken car, a warning gives people a reason to upgrade before they complain about accidents they'll have later on.

10. Users rarely know about the benefits and gains. If they did, they'd upgrade sooner. (And they'red be less artificial demand for "backward-compatibility").

Changing the interpreter makes things easier to communicate. The earlier and more "official", the better.

So I believe having warnings like these would be an enourmous benefit to communicate good practices and understanding in the community.

(Which would allow more productive time spent improving and promoting Ruby).

[naruse (Yui NARUSE)]

I doubt such people who work extremely hard have a time to such warnings because there shall be already so many warnings.

[sawa (Tsuyoshi Sawada)]

Perhaps this can be requested as a feature of ruby gems. Those who want to be warned should set it in such a way. Then every time they do gem update, they are warned of an old Ruby version.

It makes sense because you need to be connected to the internet to get the latest information, and perhaps gem update is the only thing you do constantly to have connection on the internet.

I personally am not interested in such feature at all though.

[Cezary (Cezary Baginski)]

Yui NARUSE wrote:

I doubt such people who work extremely hard have a time to such warnings because there shall be already so many warnings.

I agree. If it is added only as a Ruby warning, people won't see it by default. If they enable warnings, they will see too many already.

[Cezary (Cezary Baginski)]

Tsuyoshi Sawada wrote:

Perhaps this can be requested as a feature of ruby gems. (...) It makes sense because you need to be connected to the internet to get the latest information, and perhaps gem update is the only thing you do constantly to have connection on the internet.

That's a very good idea! It seems like the best place for something like this.

I personally am not interested in such feature at all though.

It will be invisible to people with supported Ruby versions.

However, it is more code to review and maintain. So I'm not too happy about adding this to Ruby myself.
Also, "version-specific" code like this can be tricky - one mistake and a lot of users can be unhappy.

[Cezary (Cezary Baginski)]

Would it make sense for ruby-lang.org to provide an "API" for announcing which versions are supported and until when?

If such warnings were to be implemented in RubyGems, it be useful to have info about supported/unsupported Ruby versions in JSON or other machine-readable format.

If so, I see separate issues here:

1. Maintaining machine-readable information/"API" about supported/unsupported Rubies.
2. Downloading, parsing and showing warnings based on that information. (e.g. by RubyGems during gem update).

One issue is that sometimes RubyGems does have to work without Internet access (e.g. custom/private Gem servers).

[Cezary (Cezary Baginski)]

I think this can be closed because:

1. JSON/YAML file can be created on ruby-lang.org and cached on other sites if necessary (I'll propose a format on https://github.com/ruby/www.ruby-lang.org)
2. Tools like rbenv, RVM, RubyGems and Bundler can use that file for showing warnings (Once format is agreed on, actual functionality can be suggested)
3. No changes in Ruby core are needed.

My guess is that RubyGems team will be least likely to accept such functionality.

Thank you for your time and feedback!

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Third Party's Issue