Hector Martin

The *point* of putting confidential information in the URL is to make it portable. So you can paste the URL into another app and it'll work. Yes, it's a tradeoff. But I don't expect the browser to deliberately leak them as non-discoverable xattrs on files.

RFC 3986 section 7.5: "URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies)."

RFC 3986 s 7.5 contnd: "A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public."

So as per the RFCs, if you put a password in a URL, it's because you intend it to be public. So curl's behavior is fine. (Curl has command line arguments for specifying non-public usernames and passwords.)

I'm sorry, when did we go from "logged in your browser history" to "public"? Your argument is bullshit. You're saying that just because a particular thing has some (known) security caveats it's fine to gratuitously introduce more undiscoverable ones to bite people in the ass.

Sorry, but ultimately it comes down to this: curl is following the RFCs, and you are not.

Sometimes the RFCs are bullshit. If people followed the RFCs to the letter anyone could DoS any server, because they require vulnerable implementations of things like TCP. This is one of those times.

There is a huge gap between "I'm deliberately putting a password in URIs so I can paste them in a command line in the privacy of my home" to "hey browser please attach my password invisibly to every file I download so I can unknowingly hand it to someone in a USB stick"