https://bugzilla.mindrot.org/show_bug.cgi?id=2849
Damien Miller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Damien Miller <[email protected]> --- (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@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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
