Hi, jpbion@xxxxxxxxxx wrote on Wed, Oct 18, 2017 at 08:11:05AM -0700: > OpenSSH is a fantastic tool, but > I worry I will end up not being able to use it. For you as an end-user, it seems extremely unlikely to me that it might come to that. LibreSSL and OpenSSH both have carefully maintained portable releases that run on a wide variety of hardware and operating systems, so if all else fails, you can simply compile both for yourself. Besides, no matter which operating system you are using, it seems likely that the maintainers of the ports or packages on that system will find *some* way to continue providing pre-compiled packages to you. > The real point of my note is: I don't see OpenSSL and LibreSSL merging > any time soon. Unfortunately, i must admit that i fear you are right in that respect. As i explained previously, it is not quite easy to get even harmless uncontroversial patches, like collections of bug fixes in documentation, merged back from LibreSSL to OpenSSL, even if we are willing to spend some time sending patches to OpenSSL. So cooperation is certainly less than ideal, which is (a smaller) part of the reason why LibreSSL exists in the first place. > Even if libreSSL puts in opaque structures, what if the > two teams view ways to handle the issues of 2018, and beyond > differently? Is API comparability, a goal at the start, going > to remain a primary goal of both teams, especially if one of the > two teams make choices seen as ill-founded by the other? None of the teams will follow the other blindly, obviously, but providing those reasonable interfaces that application software actually uses in practice is an important goal of LibreSSL. OpenSSL has a long history of providing very large numbers of interfaces, of varying design quality, some of which are used a lot and some of which are used rarely in practice or hardly at all. LibreSSL will not be able to keep up with the speed at which OpenSSL keeps bloating the application programmer user interface, and it doesn't really want to, because making the user interface easier to understand and to use is among the project goals. But that need not necessarily become a problem. It only would if large numbers of important application projects would start large-scale use of new OpenSSL interfaces that LibreSSL considers so ill-designed that they cannot be added to LibreSSL. But frankly, if something seems *that* disgusting to LibreSSL developers, i hope that others will see the problems with it, too, and it won't get widespread use in application software - problem solved... In any case, it's of little use discussing all that now. All we can do is hope that everybody will stick to reasonable API design, and try to sort out *specific* problems if it ever happens that somebody makes a dubious decision. > As a result, i worry if it will be possible to maintain software, > over time, that supports both variants of SSL stack. Keeping that possible, at least for many years, and at the same time remaining reasonably compatible with BoringSSL as well, is among the goals of LibreSSL for sure. Of course, nobody can reasonably talk about the remote future, and i cannot answer for OpenSSL in any way. In the worst case, if OpenSSL would unfortunately choose to burn all bridges and become completely incompatible with its own past, that still wouldn't be a very big problem for OpenSSH. At that point, OpenSSH would simply be forced to require LibreSSL as a hard dependency and drop all support for OpenSSL, but you could still rely on OpenSSH, of course. Yours, Ingo _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev