Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112022-12-27T16:01:48ZRuby Issue Tracking System
Redmine Ruby master - Bug #19271 (Closed): irb ignores rbs and debughttps://bugs.ruby-lang.org/issues/192712022-12-27T16:01:48Zolivierlacan (Olivier Lacan)hi@olivierlacan.com
<p>Not sure this is a serious issue but when starting IRB this (potentially confusing) message is immediately printed:</p>
<pre><code>$ irb
Ignoring debug-1.7.1 because its extensions are not built. Try: gem pristine debug --version 1.7.1
Ignoring rbs-2.8.2 because its extensions are not built. Try: gem pristine rbs --version 2.8.2
irb(main):001:0>
</code></pre>
<p>This is on a fresh installation of Ruby 3.2.0 with an empty Gemfile in the directory.</p>
<p>I haven't run gem pristine on any gem since I hadn't installed any gems after installing Ruby 3.2.0 here but FYI:</p>
<pre><code>$ gem list | grep "rbs\|debug"
debug (1.7.1)
rbs (2.8.2)
</code></pre>
<p>This seems to suggest that C extensions weren't built for those gems when they were installed during the Ruby installation process. Just to be safe I checked and while I do use rbenv and ruby-build to compile and manage Rubies, I don't have a default gem installer set up so as far as I know these gems weren't installed by my system.</p> Ruby master - Feature #17282 (Third Party's Issue): Deprecate Digest::SHA1https://bugs.ruby-lang.org/issues/172822020-10-24T05:06:28Zolivierlacan (Olivier Lacan)hi@olivierlacan.com
<p>In light of the widespread deprecation of SHA1 due to collision risk it poses, should Ruby still expose it without a warning within Digest::SHA1?</p>
<p><a href="https://csrc.nist.gov/publications/detail/fips/180/1/archive/1995-04-17" class="external">FIPS PUB 180-1</a> which is referenced by the <a href="https://docs.ruby-lang.org/en/master/Digest/SHA1.html" class="external">Digest::SHA1 documentation</a> was withdraw on August 01, 2002, superseded by <a href="https://csrc.nist.gov/publications/detail/fips/180/2/archive/2002-08-01" class="external">FIPS 180-2</a> (which introduced SHA-256, SHA-384, and SHA-512), and later withdrawn and superseded multiple times until <a href="https://csrc.nist.gov/publications/detail/fips/180/4/final" class="external">FIPS 180-4</a> which recommends SHA3.</p>
<p>SHA3 isn't currently supported by the Digest class although there exists Ruby gem implementations:</p>
<ul>
<li><a href="https://github.com/johanns/sha3" class="external">https://github.com/johanns/sha3</a></li>
<li><a href="https://github.com/phusion/digest-sha3-ruby" class="external">https://github.com/phusion/digest-sha3-ruby</a></li>
</ul>
<p>References:</p>
<ul>
<li><a href="https://mailarchive.ietf.org/arch/msg/openpgp/Rp-inhYKT8A9H5E34iLTrc9I0gc/" class="external">https://mailarchive.ietf.org/arch/msg/openpgp/Rp-inhYKT8A9H5E34iLTrc9I0gc/</a></li>
<li><a href="https://csrc.nist.gov/news/2017/research-results-on-sha-1-collisions" class="external">https://csrc.nist.gov/news/2017/research-results-on-sha-1-collisions</a></li>
<li><a href="https://csrc.nist.gov/publications/detail/sp/800-131a/rev-1/archive/2015-11-06" class="external">https://csrc.nist.gov/publications/detail/sp/800-131a/rev-1/archive/2015-11-06</a></li>
<li><a href="https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final" class="external">https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final</a></li>
</ul>
<p>Quoting from NIST's piece on research regarding SHA1 collisions:</p>
<blockquote>
<p>NIST deprecated the use of SHA-1 in 2011 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack. To ensure that practitioners have secure and efficient hash algorithms to provide long-term security, NIST organized an international competition to select a new hash algorithm standard, SHA-3, which is specified in FIPS 202.</p>
</blockquote>
<p>My recommendation would be to print a deprecation warning when Digest::SHA1 is used to alert Ruby users that they should perhaps upgrade to a safer standard. SHA3 should perhaps be supported by Digest as well.</p> Ruby master - Bug #13196 (Closed): Improve keyword argument errors when non-keyword arguments givenhttps://bugs.ruby-lang.org/issues/131962017-02-05T20:18:00Zolivierlacan (Olivier Lacan)hi@olivierlacan.com
<p>Given the following method definition:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">def</span> <span class="nf">explode</span><span class="p">(</span><span class="n">code</span><span class="p">:)</span>
<span class="nb">puts</span> <span class="s2">"Boom!"</span>
<span class="k">end</span>
</code></pre>
<p>If a Ruby user doesn't provide any arguments when calling the <code>explode</code> method, the following helpful feedback is given:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">explode</span>
<span class="no">ArgumentError</span><span class="p">:</span> <span class="n">missing</span> <span class="ss">keyword: </span><span class="n">code</span>
</code></pre>
<p>But when a Ruby user mistakenly provides a regular argument, the exception message is obtuse and unhelpful:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">explode</span> <span class="s2">"1234"</span>
<span class="no">ArgumentError</span><span class="p">:</span> <span class="n">wrong</span> <span class="n">number</span> <span class="n">of</span> <span class="n">arguments</span> <span class="p">(</span><span class="n">given</span> <span class="mi">1</span><span class="p">,</span> <span class="n">expected</span> <span class="mi">0</span><span class="p">)</span>
</code></pre>
<p>This does not provide information to properly recover from the error. Worse, it's incorrect. It is not true that the method expected 0 arguments. The method expected 1 keyword argument.</p>
<p>Instead, Ruby should respond something like:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">explode</span> <span class="s2">"1234"</span>
<span class="no">ArgumentError</span><span class="p">:</span> <span class="n">missing</span> <span class="ss">keyword: </span><span class="n">code</span><span class="p">,</span> <span class="n">given</span> <span class="s2">"1234"</span> <span class="n">which</span> <span class="n">is</span> <span class="ow">not</span> <span class="n">a</span> <span class="n">keyword</span> <span class="n">argument</span><span class="o">.</span>
</code></pre>
<p>One could argue that this situation would call for a different error class, perhaps a <code>KeywordArgumentError</code> that would inherit from <code>ArgumentError</code>, but that would extend the scope of this feature request a bit too far in my mind.</p> Ruby master - Bug #12852 (Closed): URI.parse can't handle non-ascii URIshttps://bugs.ruby-lang.org/issues/128522016-10-18T20:10:50Zolivierlacan (Olivier Lacan)hi@olivierlacan.com
<p>Given a return URL path like: <code>/search?utf8=\u{2713}&q=foo</code>, <code>URI.parse</code> raises the following exception:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="no">URI</span><span class="p">.</span><span class="nf">parse</span> <span class="s2">"/search?utf8=</span><span class="se">\u</span><span class="s2">{2713}&q=foo"</span>
<span class="no">URI</span><span class="o">::</span><span class="no">InvalidURIError</span><span class="p">:</span> <span class="no">URI</span> <span class="n">must</span> <span class="n">be</span> <span class="n">ascii</span> <span class="n">only</span> <span class="s2">"/search?utf8=</span><span class="se">\u</span><span class="s2">{2713}&q=foo"</span>
</code></pre>
<p>This <code>\u{2713}</code> character is commonly used by web frameworks like Rails to enforce UTF-8 in forms: <a href="https://github.com/rails/rails/blob/92703a9ea5d8b96f30e0b706b801c9185ef14f0e/actionview/lib/action_view/helpers/form_tag_helper.rb#L823-L830" class="external">https://github.com/rails/rails/blob/92703a9ea5d8b96f30e0b706b801c9185ef14f0e/actionview/lib/action_view/helpers/form_tag_helper.rb#L823-L830</a></p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="s2">"</span><span class="se">\u</span><span class="s2">{2713}"</span>
<span class="o">=></span> <span class="s2">"✓"</span>
</code></pre>
<p>Is it unreasonable to expect non-ascii portion of URIs to be handled by URI.parse? The way to circumvent this issue is to call URI.encode on the URI string prior to passing it to URI.parse:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="no">URI</span><span class="p">.</span><span class="nf">parse</span> <span class="no">URI</span><span class="p">.</span><span class="nf">encode</span><span class="p">(</span><span class="s2">"/search?utf8=</span><span class="se">\u</span><span class="s2">{2713}&q=foo"</span><span class="p">)</span>
<span class="o">=></span> <span class="c1">#<URI::Generic /search?utf8=%E2%9C%93&q=foo></span>
</code></pre>
<p>By comparison, a library like Addressable parses this URI without issue.</p>
<pre><code>require "addressable/uri"
=> #<Addressable::URI:0x3feffa84158c URI:/search?utf8=✓&q=foo>
</code></pre>
<p>This is how Addressable implements parsing:<br>
<a href="https://github.com/sporkmonger/addressable/blob/a15b7045a09911bcc47b106200554809c879a5f6/lib/addressable/uri.rb#L75-L145" class="external">https://github.com/sporkmonger/addressable/blob/a15b7045a09911bcc47b106200554809c879a5f6/lib/addressable/uri.rb#L75-L145</a></p>
<p>PS: Tried under MRI 2.3.1 and 2.4.0-preview1</p> Ruby master - Bug #10984 (Closed): Hash#contain? to check whether hash contains other hashhttps://bugs.ruby-lang.org/issues/109842015-03-19T14:00:59Zolivierlacan (Olivier Lacan)hi@olivierlacan.com
<p>Comparing hashes seems like a common practice but there currently isn't a method to ask a<br>
hash instance whether it includes another hash instance.</p>
<p>The most intuitive method to reach for would be <code>Hash#include?</code> but it is in fact an alias to <code>Hash#has_key?</code></p>
<p>What I'm looking for can be achieved with:</p>
<pre><code>class Hash
def contain?(other)
self.merge(other) == self
end
end
</code></pre>
<p>Here's a simple demo of <code>#contain?</code> in use:</p>
<pre><code>{ a: true, b: false }.contain?({ a: true})
# => true
{ a: true, b: false }.contain?({ b: false})
# => true
{ a: true, b: false }.contain?({ a: false})
# => false
{ a: true, b: false }.contain?({ c: true})
# => false
</code></pre>
<p>One important note is that this method is <em>not checking for nested hash matches</em>.<br>
This may need to be addressed when the parameters include a nested hash perhaps.</p>
<p>Thanks to Terence Lee's help, nobu created a patch for this feature last year.<br>
I've only modified the name of the method from <a href="https://gist.github.com/nobu/dfe8ba14a48fc949f2ed" class="external">his original patch</a> and attached it to this issue.</p>