[#67346] Future of test suites for Ruby — Charles Oliver Nutter <headius@...>
I'll try to be brief so we can discuss all this. tl;dr: RubySpec is
19 messages
2015/01/05
[#67353] Re: Future of test suites for Ruby
— Tanaka Akira <akr@...>
2015/01/05
2015-01-06 7:18 GMT+09:00 Charles Oliver Nutter <headius@headius.com>:
[#67444] [ruby-trunk - Feature #10718] [Open] IO#close should not raise IOError on closed IO objects. — akr@...
Issue #10718 has been reported by Akira Tanaka.
3 messages
2015/01/09
[#67689] Keyword Arguments — Anthony Crumley <anthony.crumley@...>
Please forgive my ignorance as I am new to MRI development and am still
5 messages
2015/01/20
[#67733] [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5 — normalperson@...
Issue #10761 has been updated by Eric Wong.
4 messages
2015/01/21
[#67736] Re: [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5
— Eric Wong <normalperson@...>
2015/01/22
normalperson@yhbt.net wrote:
[#67772] Preventing Redundant Email Messages — Jeremy Evans <code@...>
For a long time, I've wondered why I sometimes receive redundant email
5 messages
2015/01/23
[ruby-core:67597] [ruby-trunk - Feature #10740] Base64 urlsafe methods are not urlsafe
From:
mame@...
Date:
2015-01-15 03:46:48 UTC
List:
ruby-core #67597
Issue #10740 has been updated by Yusuke Endoh.
My point is so simple: lib/base64 should comply with RFC 4648 as far as possible. Please explain your proposal based on RFC 4648 instead of RFC 6920 (that is NOT a spec of Base64), the behavior of the other libraries, etc. If you think RFC 4648 is unreasonable, please tell it to IETF.
Tony Arcieri wrote:
> According to RFC4648 this is allowed.
I know. RFC 6290 makes such an exception. But there is no reason why THIS library does so. Note that this library is general-purpose, not for a specific use case such as an URL.
Scott Blum wrote:
> Otherwise, you have the bizarre situation where:
>
> `Base64.urlsafe_decode64(SecureRandom.urlsafe_base64(len) # raises if len % 3 != 0`
The situation itself is unfortunate.
I noticed that RFC 4648 does not mention the case where the padding lacks. It just says that the library MAY ignore extra paddings, though.
> If more than the allowed number
> of pad characters is found at the end of the string (e.g., a base 64
> string terminated with "==="), the excess pad characters MAY also be
> ignored.
So, it might be acceptable to tolerate unpadded input. Of course, we must still care about a compatibility issue.
--
Yusuke Endoh <mame@ruby-lang.org>
----------------------------------------
Feature #10740: Base64 urlsafe methods are not urlsafe
https://bugs.ruby-lang.org/issues/10740#change-51018
* Author: Scott Blum
* Status: Feedback
* Priority: Normal
* Assignee: Yusuke Endoh
----------------------------------------
Base64.urlsafe_decode64 is not to spec, because it currently REQUIRES appropriate trailing '=' characters.
Base64.urlsafe_encode64 produces trailing '=' characters.
'=' is not web safe, and is not recommended for base64url. Some specs even disallow.
Suggested fix:
~~~
# Returns the Base64-encoded version of +bin+.
# This method complies with ``Base 64 Encoding with URL and Filename Safe
# Alphabet'' in RFC 4648.
# The alphabet uses '-' instead of '+' and '_' instead of '/'
# and has no trailing pad characters.
def urlsafe_encode64(bin)
strict_encode64(bin).tr("+/", "-_").tr('=', '')
end
# Returns the Base64-decoded version of +str+.
# This method complies with ``Base 64 Encoding with URL and Filename Safe
# Alphabet'' in RFC 4648.
# The alphabet uses '-' instead of '+' and '_' instead of '/'.
# Trailing pad characters are optional.
def urlsafe_decode64(str)
str = str.tr("-_", "+/")
str = str.ljust((str.length + 3) & ~3, '=')
strict_decode64(str)
end
~~~
---Files--------------------------------
base64-urlsafe-encode64-search-result.txt (19.9 KB)
--
https://bugs.ruby-lang.org/