Hash: SHA1


The report originator is copied in the recipients list for this message.

The situation is as follows: the user types "wget
http://foo.com/file-i-want";. Wget asks the HTTP server for the
appropriate file, and gets a 302 redirection to the URL
ftp://spag:[EMAIL PROTECTED]". Wget will then issue to the log output, the line:

  Location: ftp://spag:[EMAIL PROTECTED]/mickie/file-you-want

with the password in plain view.

I'm uncertain that this is actually a problem. In this specific case,
it's a publicly-accessible URL redirecting to a password-protected file.
What's to hide, really?

Of course, the case gets more interesting when it's _not_ a
publicly-accessible URL. What about when the password is generated from
one the user supplied? That is, the original request was
http://spag:[EMAIL PROTECTED]/file-i-want, which resulted in a redirect
using the same username/password? Especially if it was an HTTPS request
rather than plain HTTP. A case could be made that it should be hidden in
that case.

On the other hands, in cases like the _original_ example given above,
I'd argue that hiding it could be the wrong thing: the user now has no
idea how to directly access the file, avoiding the redirect the next
time around.

Redirecting to a password-protected file on a different host or using a
different scheme seems broken to me in the first place, and I'm sorta
leaning towards not bothering about it. What are your thoughts, list?

Note: Saint Xavier has already written a fix for this, so it's not
actually a question of whether it's worth the bother, just whether it's
actually desired behavior.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to