Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb

Quoting [e-mail], on Sat, Feb 03, 2007 at 06:35:53PM +0900:
> James Edward Gray II wrote:
> > I've actually wished for it a couple of times and I wish it was
> > supported.  I always start with using open-uri, because I love that
> > interface, but sometimes something like this issue forces me to switch
> > to Net::HTTP.  It makes me sad.
> 
> Excuse me if you've already noticed; it's just FYI.  Open-uri's open
> method has a variety of options to be passed as the *rest parameter. 
> You can specify all the HTTP header, which proxy to use, and
> authentication info.  If you want a authentication you can write:
> 
> open uri, :http_basic_authentication => [user, passwd] do |io|
>     ...
> end

Whats really great about open-uri, is that it allows a description of a
resource to be passed around as a string, possibly passing through code
that doesn't even know that the string isn't a file name, before finally
being passed as an argument to open-uri. Sometimes you can even convince
a library that doesn't know about http to open and read an http
resource.

I guess it could have another syntax, maybe

   '{pass=secret;http://[e-mail]}'

allowing the URI to be "safe", but people are familiar with URIs.

I'm probably just being annoying, but I'll take another try at
explaining why I think the RFC is being misapplied in this context.

The RFC deprecates userinfo because the IETF is interested in protocols,
information exchanged between machines. URIs are not good ways to convey
authentication information over protocols, particularly over a network,
and most definitely a very, very bad idea in html.

IETF decisions are not always helpful when bits of IETF protocols, such
as URIs, are used outside of protocol context. Another example that
comes to mind is character set information being eliminated from
vCalendar when it was IETFized as iCalendar. They rightly point out that
character set information is already present in the MIME when calendars
are transported using HTTP or email, so is unnecessary to also have in
the calendar. But people store calendars on disk, without the MIME
wrapping. What you store on disk isn't the IETFs problem to solve, so
they removed a piece of vCalendar that was useful in that context.

In a similar spirit, they deprecated the parts of a URI that should not
be sent over a network, leaving application writers to argue with
library developers about why its useful in contexts the IETF isn't
concerned with, such as configuration files and command line arguments
to utilities.

Passwords must be stored in plaintext for a number of purposes, such as
unattended servers. It would be safer if an SSL enabled apache didn't
have the password for its RSA key stored in a configuration file, and
the administrator had to type it in by hand, and apache only stored it
temporarily in protected memory, but it would not be so practical. Its
nice to have your http server start without human intervention!

Similarly, a utility that I run as a cron job that uses http basic
authentication to scrape info from our bugtracker and mail it to myself
must know my password to access the resource. I can't pass the URI
directly to open-uri, apparently I have to do a little dance:

  uri = 'http://user:[e-mail]'
  p = URI.parse 'http://user:[e-mail]'
  open(uri, :http_basic_authentication => [p.user, p.password]).read

The problem with this is that if the open is being done down in a
library, I can't change it, in which case I have to alias Kernel.open to
something else, and wrap it.

I guess this allows us to say "its not ruby's fault, it is Sam's" when
my bugscraper gets slashdotted as an example of "ruby is insecure", but
how likely is that kind of FUD, really? I haven't seen any security
advisories against Mutt for using URIs with userinfo:

 mutt -f pop://hi:[e-mail]

How about this becomes part of open-uri if we do a specific require:

  require 'open-uri/things-we-warned-you-not-to-use'

Sam