Hi Colin, Colin Watson wrote on Sun, Oct 15, 2017 at 10:51:46PM +0100: > Is it actually a requirement that an API compatibility layer be > maintained by the OpenSSL team, or could a hypothetical group of > external developers interested in breaking this stalemate fork > openssl-compat.tar.gz, stick it in a git repository somewhere, and start > making versioned releases and trying to address the other problems you > describe? At the risk of telling you something that you already know, OpenSSL is both a large and a complicated library, and even though some parts of the compatibility layer may seem relatively simple on first sight, that doesn't imply there are no non-obvious pitfalls, and if somebody who is only partly qualified or only understands parts of the code makes seemingly simple changes in code related to cryptography, that's exactly how some serious vulnerabilities in both OpenSSL and in some non-OpenBSD ports of OpenSSH were caused in the past. So the hypothetical group you wish for would also have to be qualified, and there are not very many people in the world who would qualify to lead such a group, i fear. There are certainly some inside the OpenSSL project; at least they are likely to know the code, to know how they changed it and what that implies, and likely already aware of some of the potential pitfalls. [ about the option of building OpenSSH against LibreSSL on Debian ] > This would be a pretty bad option for me as a distributor - it'd > mean I'd have to keep track of LibreSSL security updates. In the past, that has proven noticeably less stressful than keeping track of OpenSSL security updates, and i think it is safe to say that it would be orders of magnitude less stressful and less dangerous *for an outside party* than engineering and maintaining a compatibility library. Yours, Ingo _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
