[#59445] [ruby-trunk - Bug #9335][Open] dynamic rescue regression in Ruby 2.1 — "fdr (Daniel Farina)" <daniel@...>
6 messages
2014/01/01
[#59448] [ruby-trunk - Bug #9335][Rejected] dynamic rescue regression in Ruby 2.1
— "nobu (Nobuyoshi Nakada)" <nobu@...>
2014/01/01
[#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
[#60513] [ruby-trunk - Bug #9343] [PATCH] SizedQueue#max= wakes up waiters properly
— normalperson@...
2014/02/05
Issue #9343 has been updated by Eric Wong.
[#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
[#59546] [ruby-trunk - Bug #9356] TCPSocket.new does not seem to handle INTR
— "charliesome (Charlie Somerville)" <charliesome@...>
2014/01/04
[#60863] [ruby-trunk - Bug #9356] TCPSocket.new does not seem to handle INTR
— shugo@...
2014/02/19
Issue #9356 has been updated by Shugo Maeda.
[#59517] [ruby-trunk - Bug #9357][Open] TracePoint's c_return traces return from call to 'trace' — "andhapp (Anuj Dutta)" <anuj@...>
5 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
[#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
[#59542] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/04
Eric Wong <[email protected]> wrote:
[#59543] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/04
Btw, I just pushed a few trivial fixes up (a few more failures below):
[#59545] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/04
OK, last update of the night :o I think everything is good on 32-bit...
[#59551] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/04
Eric Wong <[email protected]> wrote:
[#59565] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/06
Btw, I started working on cachelined-time branch on git://80x24.org/ruby
[#59566] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/06
Eric Wong <[email protected]> wrote:
[#59567] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Urabe Shyouhei <shyouhei@...>
2014/01/06
On 01/06/2014 12:02 PM, Eric Wong wrote:
[#59568] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Eric Wong <normalperson@...>
2014/01/06
Urabe Shyouhei <[email protected]> wrote:
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— SASADA Koichi <ko1@...>
2014/01/06
Intersting challenge.
[#59585] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Urabe Shyouhei <shyouhei@...>
2014/01/06
On 01/06/2014 04:52 PM, SASADA Koichi wrote:
[#59594] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Urabe Shyouhei <shyouhei@...>
2014/01/06
On 01/06/2014 06:11 PM, Urabe Shyouhei wrote:
[#59605] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— SASADA Koichi <ko1@...>
2014/01/06
(2014/01/06 23:10), Urabe Shyouhei wrote:
[#59630] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed
— Urabe Shyouhei <shyouhei@...>
2014/01/07
On 01/07/2014 07:36 AM, SASADA Koichi wrote:
[#59564] [ruby-trunk - Bug #9365][Open] Sporadic TypeError (wrong argument type Thread (expected VM/thread)) from IO#close (via Net:HTTP) — "ggiesemann (Geoffrey Giesemann)" <geoffwa@...>
6 messages
2014/01/05
[#60151] [ruby-trunk - Bug #9365] Sporadic TypeError (wrong argument type Thread (expected VM/thread)) from IO#close (via Net:HTTP)
— geoffwa@...
2014/01/28
Issue #9365 has been updated by Geoffrey Giesemann.
[#59728] Ruby 2.1.0 in Production: known bugs and patches — Aman Gupta <[email protected]>
Last week, we upgraded the github.com rails app to ruby 2.1.0 in production.
6 messages
2014/01/13
[#59733] Re: Ruby 2.1.0 in Production: known bugs and patches
— "Martin J. Dürst" <duerst@...>
2014/01/13
Hello Aman,
[#59770] bug report did not propagate to ruby-core — Mean Login <meanlogin@...>
https://bugs.ruby-lang.org/issues/9416
4 messages
2014/01/15
[#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 <[email protected]>
2014/01/15
On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <[email protected]> =
[#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 <[email protected]>
2014/01/16
On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <[email protected]> =
[#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 <[email protected]>
2014/01/17
On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <[email protected]> =
[#59860] Re: About unmarshallable DRb objects life-time
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2014/01/18
Em 17-01-2014 19:53, Eric Hodel escreveu:
[#59915] Re: About unmarshallable DRb objects life-time
— Eric Hodel <[email protected]>
2014/01/20
On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <[email protected]> =
[#59929] Re: About unmarshallable DRb objects life-time
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2014/01/21
Em 20-01-2014 21:51, Eric Hodel escreveu:
[#59937] Re: About unmarshallable DRb objects life-time
— Eric Hodel <[email protected]>
2014/01/21
On 21 Jan 2014, at 02:01, Rodrigo Rosenfeld Rosas <[email protected]> =
[#59974] Re: About unmarshallable DRb objects life-time
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2014/01/22
Em 21-01-2014 19:36, Eric Hodel escreveu:
[#59807] [ruby-trunk - misc #9421] [Open] [PATCH] doc/contributing.rdoc: allow/encourage other git hosts — normalperson@...
Issue #9421 has been reported by Eric Wong.
5 messages
2014/01/16
[#59882] [ruby-trunk - Feature #9428] [Rejected] Inline argument expressions and re-assignment — matz@...
Issue #9428 has been updated by Yukihiro Matsumoto.
4 messages
2014/01/20
[#59896] Re: [ruby-trunk - Feature #9428] [Rejected] Inline argument expressions and re-assignment
— "Martin J. Dürst" <duerst@...>
2014/01/20
On 2014/01/20 11:32, [email protected] wrote:
[#59909] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — shyouhei@...
Issue #9425 has been updated by Shyouhei Urabe.
4 messages
2014/01/20
[#59917] Re: [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops
— Eric Wong <normalperson@...>
2014/01/21
[email protected] wrote:
[#60229] [ruby-trunk - Feature #9427] [Feedback] [PATCH] io.c: remove socket check for sendfile — akr@...
Issue #9427 has been updated by Akira Tanaka.
3 messages
2014/01/29
[#60377] Re: [ruby-cvs:51920] nobu:r44775 (trunk): socket.c: suppress warnings — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2014/01/31
[ruby-core:60089] [ruby-trunk - Bug #9424] ruby 1.9 & 2.x has insecure SSL/TLS client defaults
From:
shyouhei@...
Date:
2014-01-25 05:33:20 UTC
List:
ruby-core #60089
Issue #9424 has been updated by Shyouhei Urabe. B Kelly wrote: > Interesting. I feel I must be communicating unclearly. > > I'm not someone who blamed Debian. (It's my preferred Linux distro.) Indeed, the > Debian maintainer who removed lines of code affecting the OpenSSL PRNG first > posted on the OpenSSL mailing list explaining his situation and asked if it was > OK to remove the code. > > As I wrote in an earlier post, I think the details of what transpired in the > Debian/OpenSSL blunder are interesting. > > Particularly, I think the details show it's difficult to point fingers at a specific > person or part of the process in the Debian/OpenSSL situation. Mistakes were made; > and yet the actions taken at each discrete step in the process seemed fairly > reasonable. > > And in that /particular/ sense I recognize the parallels being drawn to the > debate here about hardening the OpenSSL defaults for Ruby. > > My position has simply been that I regard the following scenarios as categorically > distinct: > > 1. "I don't know what these lines of code in OpenSSL do, but Valgrind complains. > Is it OK if I remove them?" > > 2. "SSLv2, TLS compression, and certain specific ciphers are regarded by the > security community as weak or exploitable. Is it reasonable and beneficial to > Ruby users if we exclude them from our defaults?" > > To me, there appears to be a vast distance between #1 and #2. My recent posts on > this thread have been in part an attempt to understand the opposing view by > eliciting responses from those who disagree. > > > Regards, > > Bill Alright, I see you are not blaming Debian people. Thank you. But I see "I don't know what these lines of code in OpenSSL do, but Valgrind complains." is a completely valid reason to fix something. In fact I have just read the patch denbian introduced and still see no problem on it. So I can't draw a line between #1 and #2. They are equally true. And the history tells the patch was wrong; how can you say #2 is OK? Recap. Ruby is not just requested to have a particular patch. Ruby is requested to act as a sanity proxy over OpenSSL to prevent it from going mad. Without any patch you CAN operate Ruby safely already, right? But you say that's not sufficient. You request us to provide Ruby that you CANT fail. Then how can we say it's safe? I see no way but OpenSSL itself to get sane. No one else can be perfect. I believe the person behind Debian's failed patch was far more skillfull than me, perhaps anyone on this thread. That helped nothing. Those patches proposed here SEEMS to provide adequate defaults to OpenSSL and so what? I think that doesn't finish this story. Because no one can say those patches are ultimate solutions. And the request here is for us to provide ultimate solution for users. If not, Ruby provides something already. That's not a good option maybe, but that also applies to the patches here. ---------------------------------------- Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults https://bugs.ruby-lang.org/issues/9424#change-44591 * Author: Jeff Hodges * Status: Assigned * Priority: Normal * Assignee: Martin Bosslet * Category: ext/openssl * Target version: current: 2.2.0 * ruby -v: ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin12] * Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- Ruby 1.9, 2.0, and 2.1 use insecure defaults for SSL/TLS client connections. They have inherited or overridden configs that make the OpenSSL-controlled connections insecure. Note: both OpenSSL's and Ruby's defaults in all tested versions are currently insecure. Confirmation of the issues with Ruby's TLS client can be done with the code in [1]. Ruby is using TLS compression by default. This opens Ruby clients to the CRIME attack[2]. Ruby also uses a variety of insecure cipher suites. These cipher suites either use key sizes much smaller than the currently recommended size, making brute forcing a decryption easy, or do not check the veracity of the server's certificate making them susceptible to man-in-the-middle attacks[3][4]. Ruby also appears to allow SSLv2 connections by default. It does so by first trying to connect with a SSLv2 client hello with a higher SSL/TLS version inside of it which allows SSLv2 servers to work. SSLv2 was broken in the 1990s and is considered unsafe. These issues expose Ruby users to attacks that have been known for many years, and are trivial to discover. These defaults are often build specific, and are not the same across platforms, but are consistently poor (the code in [1] can evaluate the build). A patch from a core developer on the security@ list is attached. However, the patch does not correct the suspect SSLv2 configuration. It is believed that Ruby 1.8 is also a concern, but, since it was obsoleted, it's not been investigated. A report similar to this was sent to [email protected] four days ago. The Ruby core developers have been unable to patch these problems in a timely manner for it for what I and others believe are concerning reasons. This ticket is being made to allow engineers outside of the small group that are on security@ to protect themselves from these attacks. [1] https://gist.github.com/cscotta/8302049 [2] https://www.howsmyssl.com/s/about.html#tls-compression [3] https://www.howsmyssl.com/s/about.html#insecure-cipher-suites [4] TLS_DHE_DSS_WITH_DES_CBC_SHA - small keys TLS_DHE_RSA_WITH_DES_CBC_SHA - small keys TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - MITM TLS_ECDH_anon_WITH_AES_128_CBC_SHA - MITM TLS_ECDH_anon_WITH_AES_256_CBC_SHA - MITM TLS_ECDH_anon_WITH_RC4_128_SHA - MITM TLS_RSA_WITH_DES_CBC_SHA - small keys TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA - MITM TLS_SRP_SHA_WITH_AES_128_CBC_SHA - MITM TLS_SRP_SHA_WITH_AES_256_CBC_SHA - MITM ---Files-------------------------------- ruby_ssl.patch (1.08 KB) change_ssl_defaults.diff (1.24 KB) -- http://bugs.ruby-lang.org/
