regression in 1.0.4: setting host clears the user

[HoneyryderChuck]

I have some code relying on the following logic:

require "uri"
uri = URI("socks4://user:@socksproxy:8080")
uri.user #=> "user"
uri.host = Resolv.getaddress("socksproxy") #=> "127.0.0.1"
uri.user #=> used to be "user", now it's nil

I understand that this was all done as a fix for a CVE to not expose passwords, but if no password is set, this resetting credentials just feels a bit odd. Also, the CVE seems more about preventing when merging two uris and leaking credentials from one to the other, and this patch does way more than that, i.e. resetting state when mutating. I don't think that they're the same.

[hsbt]

Yes, your understanding is correct.

Have you encountered any use cases where that behavior actually caused problems?

[HoneyryderChuck]

One of the gems I maintain started failing in CI due to this change (took me a few hours to figure out the why).

The behaviour it relies on is exactly like the one described in the snippet above: instantiate a URI object, resolve the host and replace it with the IP. I don't think is the credentials leakage scenario described in the CVE, and was quite surprising for me to find out that assigning a new host resets the user and pass.

[nobu]

The design of URI is XXX= checks the argument and consistency, and set_XXX does not.
You can bypass these checks by set_host, I think.

[HoneyryderChuck]

u = URI("https://user:pass@example.com")
u.set_host("user2")
#=> (irb):3:in '<main>': protected method 'set_host' called for #<URI::HTTPS:0x0000000123e42130> (NoMethodError)

[BiggerNoise]

Yes, your understanding is correct.

Have you encountered any use cases where that behavior actually caused problems?

Somewhat of an edge case, but yes, this is causing problems for us.

We have an app that calls docker containers and passes a connection string to the postgres database (not containered)
When running locally (development), we need to change that connection string from

postgresql://my_user_name:my_password@localhost:5432/the_db

to

postgresql://my_user_name:my_password@host.docker.internal:5432/the_db

Now when we set the host, the user and password are cleared.

I can work around the new behavior by simply saving off the user & password before setting the host in this case so it's not a big deal. Just wanted to give you another example where it is bringing some grief.

Happy to supply further details if needed.

[botandrose]

We were also bit by this at BARD. Our deployment library constructs a rsync command from an supplied ssh URI. It does this by duping the uri object, mutating it into a form amenable for rsync (setting the port to nil, among other things), and then calling .to_s on it. Setting the port to nil is what caused the ssh username to disappear from the uri. This seemed like an obvious bug, from my perspective. I'm very surprised to discover here that its intended behavior. FWIW.

[stereosupersonic]

we have the same issue after upgrading to 1.0.4