[#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:59977] [ruby-trunk - Bug #9424] ruby 1.9 & 2.x has insecure SSL/TLS client defaults
From:
Martin.Bosslet@...
Date:
2014-01-22 12:12:01 UTC
List:
ruby-core #59977
Issue #9424 has been updated by Martin Bosslet. File change_ssl_defaults.diff added First some words why I (and others here) believe that it's not a good idea to deviate from OpenSSL defaults: Security is a delicate issue and typically consumers relying on a library like OpenSSL often do so because they don't want to be burdened with low-level decisions. Reasons can be manyfold, lack of domain knowledge, not wanting to take on that responsibility etc. Therefore, at least in my very own opinion, it should be the responsibility of the library itself to keep sane defaults and also to leave as few options as possible remaining for consumers to decide. There should be one central place where these defaults are kept, so anyone knows where to look when trying to analyze or update them. DRY principle and all that. This is why in an ideal world, everybody would rely on OpenSSL's defaults. Rolling your own defaults is dangerous: Even skilled developers like the Debian developers can get it wrong sometimes, with disastrous consequences. It hurts even more that in such cases everyone will start pointing fingers, asking: "Why didn't you stick to the library defaults???" Deviati ng from library defaults also comes with the burden that it forces you to keep a close eye on any changes regarding upstream defaults. Even the slightest change might completely break the security of any hand-rolled defaults, e.g. if a new parameter adds a new "dimension" or if the meaning of some existing parameter changed etc. Now you might say that this should be my/our duty anyway, but then I'd like to remind you that most of us work on Ruby in our leisure time and we might be on vacation, too busy with work - hell, even if you're paid to watch those changes it can still happen that you simply miss something. So obviously there are many reasons against maintaining your own defaults, from a theoretical as well as a practical point of view. But I do also agree that OpenSSL might sometimes react too slowly when it comes to updating their defaults. They might even have good reasons to leave some dubious defaults in there because they have to support a myriad of different platforms and environments. So I guess it's time for a compromise. Here's one I could live with: I would prefer a whitelisting approach instead of blacklisting as in the patch that was proposed. Blacklisting is never airtight, as it doesn't protect us from future shitty algorithms creeping in. I have prepared the attached patch which basically limits the TLS ciphers to AES in all its combinations that are currently considered secure. It should pass Jeff's test suite and only allows TLS in version 1.0 upwards - I can't see a reason for keeping SSL v3. @Jeff: Can you confirm this patch passes all your tests (in particular, it no longer allows the v2 handshake upgrade?) But again, I firmly believe doing this (our own defaults) is a bad idea. That's why I would like anyone who cares about Ruby's security to go the OpenSSL mailing list and ask them to update *their* defaults. That's something that everybody would benefit from, not just Ruby. I also believe that once (if?) OpenSSL defaults have been sanitized we should immediately discard our own custom settings in the following point release. What about Ruby users with old OpenSSL versions? I think it can not and should not be our goal to try to patch security holes in old versions of OpenSSL in Ruby's OpenSSL extension just so that Ruby users are relieved from having to upgrade. The closer we can stick to OpenSSL in Ruby OpenSSL, the better for everyone's security. Keeping your OpenSSL up-to-date is and will be mandatory in order to guarantee a safe-to-use Ruby OpenSSL extension. ---------------------------------------- Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults https://bugs.ruby-lang.org/issues/9424#change-44506 * 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/
