From: shane.hanna@... Date: 2017-10-04T13:29:59+00:00 Subject: [ruby-core:83104] [Ruby trunk Bug#13970] Base64 urlsafe_decode64 unsafe use of tr. 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: