From: Max Zettlmeißl Subject: Re: [PATCH] ssh-add: Support @ in the user part of destination constraints To: Theo de Raadt Cc: tech@openbsd.org Date: Tue, 20 Aug 2024 06:12:44 +0200 My original email was initially longer, but I tend to explain my choices too much so I went with brief this time. Seems like longer would have been better. Here it is. On Tue, 20 Aug 2024 at 04:22, Theo de Raadt wrote: > > How do you justify your choice. Where is the documentation change? The OpenSSH client allows the @ character in usernames. Therefore the behaviour of `ssh-add` without my patch is the unexpected thing. It did not seem appropriate to me to document anything in the source code itself, I looked at the surrounding functions and obviously at the function itself to see whether there would be any affected documentation, which I did not find. Regarding the man page, I thought about mentioning it. But to be honest it came as quite the surprise to me that an '@' in the username was not supported, so especially pointing it out seemed strange to me. It's not like the man page contains a grammar for valid usernames. If I'd have to include it I would add "The user name may also contain @ characters." to the second paragraph under the -h option. Do you see any merit in that? I don't. > Your choice means all user-authentication layers are now exposed > to a login name with a '@' in it. Are they all prepared for that? > Maybe, but they have not been reviewed. I'm not sure I understand you correctly, but which user-authentication layers would specifically be connected to `ssh-add` and the host constraints that are part of the agent since 8.9? Using an '@' in a SSH username has been working for as long as I tried. So at least years. I do not see anything happening with this addition that could not happen before. I merely brought the behaviour of the `ssh-add` constraints and thereby the behaviour or SSH agent restrictions in line with the behaviour of the SSH client. Where you had to previously use a wildcard user / skip the user, you now can restrict the public key from being sent for a connection if the user does not match the expected identity. So instead of widening or modifying, this seems to strictly narrow down submitted identifiers and credentials. I can't see the issue here, but might be missing something about how the value is used. > Why does your username have a seperation character in it? Whatever > you are doing in that subsystem sounds like a serious mistake. I've > never heard of this problem before. It is only you. Ask Google. Their Cloud Source Repositories use an email address as the username.