On Thu, 26 May 2022, Demi Marie Obenour wrote: > I was thinking about the recent problems with the GSSAPI kex patch, > and I wonder if it would be best to merge GSSAPI kex into OpenSSH > upstream. My (admittedly dated) understanding is that the patch is > of high quality, and that the concerns are instead about the GSSAPI > implementation in use. However, I believe this is a non-issue for most > environments where GSSAPI kex would be useful: if someone can find > an RCE in the GSSAPI implementation, there are bigger problems (like > compromised domain controllers). The main problem is that (AFAIK) none of the maintainers suffciently know kerberos/GSSAPI nor use it regularly. The last time I used it was over 10 years ago and I don't even have a working test setup for it ATM. Additional impediments are consierable scepticism about the safety of the GSSAPI implementations (e.g. none of them include fuzz tests or are enrolled in oss-fuzz), the fact that this is definitionally highly sensitivew pre-auth attack surface and an upstream that removed Kerberos/GSSAPI from its base OS some years ago, Not speaking for any of the other developers, but I don't see any appetite or path to getting it merged. That's not to say that the situation couldn't be improved for those who want it. IMO getting a github project with the patches applied that is kept up to date and with a real set of regression tests would be a significant improvement over the status quo. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
