[Bug 2849] OpenSSH 7.7p1 uses login_name value instead of user at hostname

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2849

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
(In reply to Johannes Schindelin from comment #5)
> Damien, are you sure you want to promote this behavior? Literally
> *all* other command-line programs let command-line options be
> overridden.

We've been promoting this behaviour for almost 20 years - configuration
has long been documented to be first-match-wins (see ssh_config(5)).
That "user@" was being treated differently was a bug.

> And even if this were not so, are you not even acknowledging that
> this is a backwards-incompatible behavior that was not announced,
> and that we already demonstrated to break existing setups?

Yes, it's backwards incompatible. I'm sorry I neglected to mention it
in the release notes, but the correction of the behaviour was
absolutely intentional.

> And even if you are reluctant to see it this way, how would you
> suggest Jenkins to do things when the URI is *a user-specified*
> value that may, or may not have a user name, and `jenkins` should be
> used as user name if the URI does not have one? Should Jenkins now
> scan the URI themselves?

I'm not sure I follow. OpenSSH < 7.7 didn't support URIs on the
command-line.

If you're talking about "user at host" (which isn't a URI and is trivial
to parse anyway) then yeah, if your software is specifying a fallback
username then it's pretty fundamental that it should check that one
hasn't already been specified elsewhere.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.