Ruby Issue Tracking System: Issueshttps://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112016-10-01T17:49:01ZRuby Issue Tracking System
Redmine Ruby master - Feature #12802 (Open): Add BLAKE2 support to Digesthttps://redmine.ruby-lang.org/issues/128022016-10-01T17:49:01Zbascule (Tony Arcieri)bascule@gmail.com
<p>BLAKE2 is a fast, modern hash function, based on improvements to the BLAKE function, which was a SHA3 finalist. BLAKE2 performs about twice as fast in software as SHA3 winner Keccak:</p>
<p><a href="https://blake2.net/" class="external">https://blake2.net/</a></p>
<p>BLAKE2 has received an informational RFC 7693 from the IETF:</p>
<p><a href="https://tools.ietf.org/html/rfc7693" class="external">https://tools.ietf.org/html/rfc7693</a></p>
<p>It was added to the Python standard library in Python 3.6:</p>
<p><a href="https://docs.python.org/3.6/library/hashlib-blake2.html" class="external">https://docs.python.org/3.6/library/hashlib-blake2.html</a></p>
<p>If there's interest in supporting BLAKE2 in the Ruby standard library, I can put together a patch.</p> Ruby master - Feature #12008 (Open): Immutable object graphs (a.k.a. deep freeze)https://redmine.ruby-lang.org/issues/120082016-01-19T22:54:29Zbascule (Tony Arcieri)bascule@gmail.com
<p>Hi there. I know some sort of "#deep_freeze" construct has been proposed many times before. I proposed it in this blog post in 2012: <a href="https://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads" class="external">https://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads</a></p>
<p>I have also read this issue: <a href="https://bugs.ruby-lang.org/issues/2509" class="external">https://bugs.ruby-lang.org/issues/2509</a></p>
<p>This is an area I have thought a lot about as I deal with many people's multithreaded Ruby programs and shared state mutation bugs / data races. I would like Ruby to support an option to fix this problem, and have guaranteed immutable state for entire object graphs rather than individual objects.</p>
<p>The main problem, as I understand it, is existing proposals wish to recurse entire object graphs and deep freeze all their contents. This is particularly problematic with things like Proc.</p>
<p>I propose a simpler #deep_freeze where it is opt-in by individual classes.</p>
<p>It should also be shallow instead of recursive: individual objects should only traverse their local references, determine if they are <em>already</em> #deep_freeze(d), and if not, bail out. No need for recursion.</p>
<p>The basic idea being: to #deep_freeze an object, it can only refer to other #deep_freeze(d)/frozen objects. We do not attempt to walk the entire object graph/aggregate and freeze all the children recursively. Instead merely <em>check</em> that all of the children are <em>already</em> #deep_freeze(d)/frozen, and if they aren't, bail out.</p>
<p>This has many beneficial properties:</p>
<ul>
<li>We rely on explicit support from objects to support #deep_freeze. If they don't, bail out. No weird behaviors recursing references and running into crazy Proc object fractals</li>
<li>We only need an object-local view of the world to determine if we're #deep_freeze-able. The check is little more than walking <em>local</em> object references (i.e. ivars in most cases) and if everything checks out, setting a flag</li>
<li>We get guarantees that entire object graphs/aggregates are completely frozen all the way down</li>
</ul>
<p>This requires programmers build up deep frozen object aggregates by starting at the leaves and building more and more complicated aggregates out of deeply frozen pieces.</p>
<p>I think the changes that have gone into Ruby 2.3 are making this easier and more realizable. I would like to continue this trajectory and provide real guarantees for Rubyists about which objects reference object graphs that are truly immutable.</p>
<p>I think immutable state has huge benefits for a lot of areas, most notably concurrency and security.</p> Ruby master - Bug #11968 (Closed): OpenSSL extension only supports weak (512-bit, 1024-bit) Diffi...https://redmine.ruby-lang.org/issues/119682016-01-07T19:11:22Zbascule (Tony Arcieri)bascule@gmail.com
<p>The following D-H groups are enabled per default:</p>
<p><a href="https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/pkey.rb" class="external">https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/pkey.rb</a></p>
<p>These use 512-bit and 1024-bit primes respectively. These are considered weak in 2015 by all present methods of evaluating D-H group size as a security parameter:</p>
<p><a href="http://www.keylength.com/" class="external">http://www.keylength.com/</a></p>
<p>Weak D-H groups like this were recently implicated in the Logjam attack:</p>
<p><a href="https://weakdh.org/" class="external">https://weakdh.org/</a></p>
<p>512-bit D-H keys in particular can be trivially attacked by commodity hardware. I have put in a PR to the openssl gem to remove the 512-bit group:</p>
<p><a href="https://github.com/ruby/openssl/pull/44" class="external">https://github.com/ruby/openssl/pull/44</a></p>
<p>However, the 1024-bit group is weak as well. The recommendation of the Logjam paper authors is to upgrade to a 2048-bit group at the minimum.</p> Ruby master - Misc #11904 (Rejected): Why was Thread.exclusive deprecated?https://redmine.ruby-lang.org/issues/119042015-12-28T06:31:40Zbascule (Tony Arcieri)bascule@gmail.com
<p>initialize a mutex because the mutex must be initialized in a thread-safe context where it's not possible for multiple caller threads to initialize the mutex concurrently.</p>
<p>One use case is here: this is an idempotent native function invoked via FFI. The contract is that it can be called repeatedly, but only by one thread at a time (concurrent calls from multiple threads can potentially corrupt its internal state):</p>
<p><a href="https://github.com/cryptosphere/rbnacl/blob/master/lib/rbnacl.rb#L88" class="external">https://github.com/cryptosphere/rbnacl/blob/master/lib/rbnacl.rb#L88</a></p>
<p>Thread.exclusive is useful because it provides an implicit mutex you can ensure is initialized correctly before any other threads start.</p>