[#75225] [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7) — k@...
Issue #12324 has been reported by Kazuki Yamaguchi.
6 messages
2016/04/27
[#78693] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Eric Wong <normalperson@...>
2016/12/17
k@rhe.jp wrote:
[#78701] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Kazuki Yamaguchi <k@...>
2016/12/17
On Sat, Dec 17, 2016 at 01:31:12AM +0000, Eric Wong wrote:
[#78702] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Eric Wong <normalperson@...>
2016/12/17
Kazuki Yamaguchi <k@rhe.jp> wrote:
[ruby-core:75260] Re: [Ruby trunk Feature#12328] Show warnings about vulnerable and no longer supported Ruby versions.
From:
Eric Wong <normalperson@...>
Date:
2016-04-30 04:07:41 UTC
List:
ruby-core #75260
cezary.baginski@gmail.com 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. Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>