Hi, Regarding CVE-2018-15473: a few people have asked why we just committed a fix for this without any secrecy or treating it as a security problem. The reason is that I and the other OpenSSH developers don't consider this class of bug a significant vulnerability - it's a partial disclosure of non-sensitive information. We have and will continue to fix bugs like this when we are made aware of them and when the costs of doing so aren't too high, but we aren't going to get excited about them enough to apply for CVEs or do security releases to fix them. The following explains our reasoning. First, this isn't "user enumeration" because it doesn't yield the ability to enumerate or list accounts. It's an oracle; allowing an attacker to make brute-force guesses of account names and verify whether they exist on the target system. Each guess is moderately expensive, requiring 1 x TCP connection and a cryptographic key exchange, limited in concurrency by sshd's MaxStartups limit. Second, very little else in the Unix ecosystem tries to prevent this style of information disclosure. Many network daemons will still happily return "user not found" style messages, but more importantly: system libraries are simply not designed to consider this as a threat. They don't consider it a threat because usernames have long been considered the non-secret part of user identity, of limited use without actual authentication credentials. In the absence of the underlying system stack being designed with this in mind, the best applications like sshd can do is try to paper over the most obvious differences by avoiding behaviour divergences in our own code and adding some prophylactic timing delays, but it's a losing battle. Does getpwnam() offer invariant behaviour? How about libpam? And all the modules PAM invokes? How about libgssapi? (etc. ad nauseam). AFAIK few, if any of these, have been engineered to avoid behaviour differences between existing and non-existing users. I'm not just talking about gross timing differences, but any access patterns that can be discerned at a distance, including CPU usage or filesystem access. If someone brought the cryptanalyist's arsenal to bear against username validity then all these are on the table. Finally, and perhaps most importantly: there's a fundamental tradeoff between attack surface and fixing this class of bug. As a concrete example, fixing this one added about 150 lines of code to our pre-authentication attack surface. In this case, we were willing to do this because we had confidence in the additional parsing, mostly because it's been reviewed several times and we've conducted a decent amount of fuzzing on it. But, given the choice between leaving a known account validity oracle or exposing something we don't trust, we'll choose the former every time. -d