[#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
[#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

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

Intersting challenge.

[#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 <[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]> =

[ruby-core:60017] Re: [ruby-trunk - Bug #9424] ruby 1.9 & 2.x has insecure SSL/TLS client defaults

From: Bill Kelly <billk@...>
Date: 2014-01-23 10:17:01 UTC
List: ruby-core #60017
[email protected] wrote:
>
> Rolling your own defaults is dangerous: Even skilled developers like the
> Debian developers can get it wrong sometimes, with disastrous consequences.

The Debian blunder has been referenced twice in this discussion, but I think
the comparison is not apt.

The Debian maintainer _removed lines of code_ from the OpenSSL PRNG
implementation. [1]

This is hardly in the same category as tightening the defaults to exclude
specific ciphers or protocol features already known to be weak or exploitable.


> It hurts even more that in such cases everyone will start pointing fingers,
> asking: "Why didn't you stick to the library defaults???"

As opposed to asking: "Why didn't you remove known weak ciphers and exploitable
protocol features from the defaults when you were warned about them???"


> 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 wonder.  In the blacklisting case, we're not required to make guesses about
the future.  We're merely switching off already-known weak or exploitable
features.

Whitelisting goes a step further, gambling that what we know today about the
subset of defaults considered superior will continue to hold true down the road.

It's not clear to me that's better than the more conservative step of simply
blacklisting specific defaults already known to be problematic.



Regards,

Bill


[1] The details are perhaps interesting: http://research.swtch.com/openssl



In This Thread

Prev Next