1. 13
  1.  

  2. 4

    This is a bit unsettling. Essentially what they published is a fork that’s not possible to integrate with the upstream and I also didn’t notice them engaging the community on the mailing lists. I may be wrong and I do notice the comment:

    However, to get the changes accepted back into OpenSSH, we need to do some work to make the code compliant with the rest of OpenSSH which is dependent on POSIX.

    I just hope they follow up instead of maintaining a fork.

    1. 8

      I think there’s something to be said for “make it work; make it right.”

      1. 1

        Only if having something that’s wrong is better than having nothing at all; which, while usually the case, is definitely most questionable for remote shell tools.

      2. 4

        Although Microsoft did give a gold donation to the OpenBSD Foundation see here - which is more than many other corporate users of OpenSSH.

        1. 2

          In a certain sense it’s actually pretty in line with the OpenBSD ethos: pull in the code, ruthlessly rip out things that duplicate native platform functionality and link the native platform functionality instead, then later think about whether this is going to be maintained as a permanent fork or reconciled with upstream.

        2. 2

          NTLM when? ;)

          Slightly glad it’s been Windows-ized, to be honest. A lazy Unix port wouldn’t be nice if they want to actually adopt it. Using LSA auth packages are interesting in that regard. I’m not sure how to get any interactive stuff working though - TERM is unset and I don’t know what to use for it.

          1. 1

            I’ll be curious to see if there’s any fallout from the conversion to Windows crypto APIs.

            1. 5

              We’ll see. To be fair, it’s not like OpenSSL is quality either.

              1. 3

                In fact, I believe that CryptoAPI has had fewer CVEs than OpenSSL proper this year, so there’s no inherent reason to believe that’ll be the cause of any drop in security. The bigger fallout I’d expect is either that they find oddities in how OpenSSL is getting used (not likely, in my opinion, due to LibreSSL and the regular OpenBSD audits), or that they introduce a fault during the conversion process.

                1. 2

                  The bigger fallout I’d expect is either that they find oddities in how OpenSSL is getting used (not likely, in my opinion, due to LibreSSL and the regular OpenBSD audits)

                  I’d actually think this is fairly likely.

                  The OpenBSD team often talks about the value of porting OpenBSD to less-used architectures because of the amount of bugs that are floated to the surface. True, they tend to be related to hardware oddities or misunderstandings, but I bet there’s going to be a fair few places where needing to transplant to a different API surfaces some misunderstandings - especially an API like OpenSSL’s libcrypto.