open-uri: URI.open status
On the one hand, Ruby 2.5's NEWS stated:
URI.open method defined as an alias to open-uri's Kernel.open. open-uri's Kernel.open will be deprecated in future.
I believe there were good reasons for that decision.
On the other hand,
- no movements in this direction were done since 2.5
URI.openis excluded from
open-uri's docs, and the main library's documentation doesn't mention this option as preferred or even existing.
I'd like to know what the real status of this library and its migration to (safer)
Should a patch be provided to change the library's docs accordingly?
Maybe even change the code (still leaving
Kernel.open option, but just as an alias, moving the implementation away from that method)?
Updated by jeremyevans0 (Jeremy Evans) 4 months ago
- Assignee set to akr (Akira Tanaka)
- Status changed from Open to Assigned
- File deprecate-open-uri-kernel-open.patch deprecate-open-uri-kernel-open.patch added
While the conversion from
URI.open is simple, this is likely to break a lot of existing Ruby code. However, I can see the security advantages of deprecating this, as having
open implicitly open URIs is a security footgun. For that reason, I am in favor of the deprecation and eventual removal.
akr is the maintainer of
open-uri, so I'm assigning this to him. In case he decides to deprecate this, attached is a patch for the deprecation. It makes
URI.open in cases where
URI.open would handle it, warning in that case. To avoid warning when calling
Kernel.open with a
Pathname instance, it does not delegate to
URI.open if the object responds to