openssh bugs - Apr 2018 - [Bug 2849] New: OpenSSH 7.7p1 uses login_name value instead of user@hostname

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

            Bug ID: 2849
           Summary: OpenSSH 7.7p1 uses login_name value instead of
                    user at hostname
           Product: Portable OpenSSH
           Version: 7.6p1
          Hardware: amd64
                OS: Windows 10
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: mark.earl.waite at gmail.com

OpenSSH bug 2385 notes that the observed order of evaluation of the
login_name is:
>      1.   user specified before @ character in hostname string
>      2.   login_name specified using -l switch
>      3.   User option provided as a parameter to -o switch
>      4.   User option in matching Host block from per-user config
~/.ssh/config
>      5.   User option in matching Host block from systemwide config
/etc/ssh/ssh_config
> If there is nothing from above specified, username on local terminal is
used.
That matches the behavior of OpenSSH 7.6 and earlier.

OpenSSH 7.7p1 has changed the order of evaluation of the login_name. 
It is now evaluated as:

     1.   login_name specified using -l switch
     2.   user specified before @ character in hostname string
     3.   User option provided as a parameter to -o switch
     4.   User option in matching Host block from per-user config
~/.ssh/config
     5.   User option in matching Host block from systemwide config
/etc/ssh/ssh_config
If there is nothing from above specified, username on local terminal is
used.

The order of evaluation change exposed an inconsistency in the Jenkins
git plugin which was inadvertently relying on the earlier order of
evaluation.  

See JENKINS-50573 for the details of the Jenkins bug.

See Git for Windows issue 1616 for the details investigated by Johannes
Schindelein of the Git for Windows project.  Johannes also references a
possible fix in the Git for Windows issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

--- Comment #1 from Mark E Waite <mark.earl.waite at gmail.com> ---
See proposed patch from Johannes Schindelin at
https://github.com/openssh/openssh-portable/pull/91

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
OpenSSH 7.7 makes it first-match-wins, which is how all other
command-line  and configuration file options are processed. The
previous behaviour was at best undefined and certainly inconsistent
with everything else.

Why is jenkins specifying contradictory username options? That seems
like a more obvious bug.

-- 
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.

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

--- Comment #3 from Mark E Waite <mark.earl.waite at gmail.com> ---
I agree that the Jenkins behavior is incorrect.  It should use the
correct login_name.

However, please consider the other example cited by Johannes Schindelin
in https://github.com/openssh/openssh-portable/pull/91 before you
decide to retain the new OpenSSH 7.7p1 command line argument precedence
behavior.

He notes in the pull request that the new behavior now takes the first
argument value even if later arguments provide a replacement value.  He
describes how that will harm existing uses of shell aliases that
provide a default value for login_name while still allowing the default
value to be overridden.  With OpenSSH 7.7p1, the override will be
ignored.

The OpenSSH 7.6p1 command line argument behavior is describing clearly
and accurately in OpenSSH bug 2348.  The patch from OpenSSH bug 2348
has not been included in the documentation, but it accurately describes
the behavior before OpenSSH 7.7.  I think it is a mistake to change the
behavior in OpenSSH 7.7 in this way.  It will break other users, not
just the Jenkins git plugin.

-- 
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.

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

--- Comment #4 from Mark E Waite <mark.earl.waite at gmail.com> ---
Sorry, I should have referenced OpenSSH bug 2385 in my previous
comment, not OpenSSH bug 2348.  OpenSSH bug 2348 is unrelated to this
bug.

-- 
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.

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

Johannes Schindelin <johannes.schindelin at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannes.schindelin at gmx.de

--- Comment #5 from Johannes Schindelin <johannes.schindelin at gmx.de>
---
Damien, are you sure you want to promote this behavior? Literally *all*
other command-line programs let command-line options be overridden.
Just a few examples:

ls --color --color=never
rm --interactive=never --interactive=always
git status --color --no-color

and the list goes on and on and on and on and on.

And for a good reason. Aliases are such an example, as I already
mentioned in the Pull Request. Besides, in English, and on the
command-line, we read from left to right. So if you read --color=always
--color=never, it is pretty obvious what the reader understands, no?
She would read "use color, always, oh wait, nevermind, never, ever use
color". And that's been the case for a long, long time.

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?

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 was quite a bit shocked to read what you had to say, to say the
least.

-- 
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.

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.

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

--- Comment #7 from Mark E Waite <mark.earl.waite at gmail.com> ---
Thanks for your comments.

While I disagree with the choice, I wholeheartedly support your right
and responsibility to make that choice.

I'll adapt the Jenkins git plugin to the new behavior of OpenSSH 7.7
and add tests to assure I detect it if the change is reverted in the
future.

I believe you'll hear the same report from other users in the future,
but those hypothetical future reports don't help my persuasion efforts
now.  I suspect you're confident that either they won't arrive, or if
they arrive they will be resolved as "WONTFIX".

Thanks again for your work on OpenSSH.  It is amazing software!

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

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

James Cloos <cloos at jhcloos.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cloos at jhcloos.com

--- Comment #8 from James Cloos <cloos at jhcloos.com> ---
I have to join the choir against this change.

The change is in direct opposition to posix.

All command line parsing must be last wins.

Shell aliases, functions and scripts all require that.

Last wins is also easier to program.  This change means you have to
check each option as to whether it already has been specified; last
wins means that is not needed.

It may be that last wins came into being because the early coders
didn't think of the possibility of specifying an option more than once.
 But even if so it is not standard and How Things Are Done?.

The distributions will all have to patch around this brokenness anyway.

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

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

--- Comment #9 from James Cloos <cloos at jhcloos.com> ---
I should have noted:

It is perfectly OK to say that command line wins over config files.

That is of course normal and expected.

But /within/ the command line last has to win over earlier.

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

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

Mark E Waite <mark.earl.waite at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|Windows 10                  |All
            Version|7.6p1                       |7.7p1
           Hardware|amd64                       |All

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Damien Miller <djm at mindrot.org> ---
Close RESOLVED bugs with the release of openssh-8.0

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

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

--- Comment #11 from Johannes Schindelin <johannes.schindelin at gmx.de>
---
> Close RESOLVED bugs with the release of openssh-8.0
Surely you meant openssh-7.9?

And I have to say that I am sad with the way this ticket was handled.
It is still a very counterintuitive change that was introduced, without
prior warning, and the behavior is still very much against pretty much
all other command-line software.

Just making sure you know that not everybody agrees with your decision.

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