[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:60076] [ruby-trunk - Feature #9439] Remove OpenSSL from stdlib

From: tenderlove@...
Date: 2014-01-24 23:52:00 UTC
List: ruby-core #60076
Issue #9439 has been updated by Aaron Patterson.


 On Fri, Jan 24, 2014 at 09:05:18PM +0000, usa@garbagecollect.jp wrote:
 > Issue #9439 has been updated by Usaku NAKAMURA.
 > 
 > 
 > I would like to clarify the problem.
 > 
 > As already stated, RubyGems uses OpenSSL.
 > To say strictly, RubyGems uses OpenSSL for https, signing, and its verification.
 > Therefore, the option which we can take is as follows:
 > (1) Maintain the present condition. 
 > (2) Remove OpenSSL and RubyGems together.
 > (3) Prepare the alternate features of https, signing, and its verification after removing OpenSSL.
 > (4) Remove the dependence to these features from RubyGems after removing OpenSSL.
 > (5) Mixture of (3) and (4).  That is, remove the dependence to some features from RubyGems, and prepares substitutes about another features.
 > 
 > To my understanding, Shyouhei is taking a position on (4).
 > That is, changing RubyGems to use plain http in default, and write substitutes for about signing and its verification (with GPG?).
 > 
 > There may be also a position in which (a part of) the features which OpenSSL offers is still required as a part of Ruby, even if RubyGems sets aside.
 > I understand that Fabian said that the https support itself is required.
 > 
 > How do you think, everyone?
 
 Can we take a less extreme approach?  We should convert openssl to a gem
 that ships with Ruby (like json, minitest, psych, etc).  Then in case of
 security issues in OpenSSL, we can just release the gem independently of
 Ruby itself.  Such a case has already happened with the json gem.
 
 I've done the initial work to make openssl a gem that ships with Ruby.
 The patch is here:
 
   https://github.com/tenderlove/ruby/commit/fd96a5b1123ba1e56081ef2741a456096b4c4d12
 
 It installs to my machine as a gem:
 
   https://dl.dropbox.com/s/km9msdsb0uuq3mj/ruby__bash__16136_20140124_105412.png
 
 The downside is that the openssl extension uses Ruby internals
 ([ruby-core:60063]), so we can't actually ship a gem until it is
 decoupled from Ruby internals.
 
 Personally, I prefer that we continue to ship with openssl.  However,
 even if I am in the minority, openssl must become a gem in order to
 satisfy backwards compatibility requirements.  I would like to continue
 to download my gems over SSL, use net/http in SSL mode, use securerandom
 OpenSSL, etc. :-)
 
 -- 
 Aaron Patterson
 http://tenderlovemaking.com/

----------------------------------------
Feature #9439: Remove OpenSSL from stdlib
https://bugs.ruby-lang.org/issues/9439#change-44581

* Author: Zachary Scott
* Status: Open
* Priority: Normal
* Assignee: 
* Category: lib
* Target version: current: 2.2.0
----------------------------------------
Regarding [ruby-core:59943], I agree with nobu that we should remove OpenSSL from ruby.

It's become too hard to maintain, and would better serve our users to encourage the use of a different implementation.

Another benefit of removing OpenSSL is the impact backport fixes have on the release management team.

Although I haven't yet determined the extent of work required to remove it (ie: tooling, tests, etc). We can discuss them here.



-- 
http://bugs.ruby-lang.org/

In This Thread

Prev Next