[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, [email protected] wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <[email protected]> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <[email protected]> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83104] [Ruby trunk Bug#13970] Base64 urlsafe_decode64 unsafe use of tr.
From:
shane.hanna@...
Date:
2017-10-04 13:29:59 UTC
List:
ruby-core #83104
Issue #13970 has been reported by shanna (Shane Hanna).
----------------------------------------
Bug #13970: Base64 urlsafe_decode64 unsafe use of tr.
https://bugs.ruby-lang.org/issues/13970
* Author: shanna (Shane Hanna)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
A lot of the base64 module lacks duck typing or nice errors.
For example the `urlsafe_decode64` function never checks `str` is something that behaves like a string and will respond to `tr`.
If you pass `nil` by mistake you end up with the dreaded "can't call method on (n)" rather than an informative error.
~~~ ruby
def urlsafe_decode64(str)
# NOTE: RFC 4648 does say nothing about unpadded input, but says that
# "the excess pad characters MAY also be ignored", so it is inferred that
# unpadded input is also acceptable.
str = str.tr("-_", "+/")
if !str.end_with?("=") && str.length % 4 != 0
str = str.ljust((str.length + 3) & ~3, "=")
end
strict_decode64(str)
end
~~~
Raising an error or silently failing if the argument doesn't respond to `tr` (or `to_s.tr`) both seem preferable to errors raised by the internal implementation but I'm wondering if there is a preferred approach in Rubys stdlib?
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>