Hi Emmanuel, Emmanuel Deloget wrote on Thu, Oct 19, 2017 at 01:58:55PM +0200: > Let's restate the full goal here : > > * first, LibreSSL should integrate the OpenSSL 1.1 API I believe that is desirable in the long term, and i heard others talk about it in the past, too, but i won't be the one to make the decision if and when to do it. > * second, it should mark the replaced interface as deprecated That is not required to solve the OpenSSH problem. At some point, it may be desirable anyway because in many cases, opaque structs can be an improvement. > * third, make OpenSSH use the new interface > > That sounds like a manageable list of goals -- i.e. one that can prove > to be completed before the EOL of OpenSSL 1.0.2 in Dec. 2019. In OpenBSD, as a matter of principle, we never promise that some specific work will be completed by some specific date. Things are ready when they are ready: Carefully designed, implemented, and tested, taking whatever time is needed to do the job properly. In this specific case, while i do invest signifant time into the OpenSSL documentation now and then, i cannot order any of my colleagues around and won't attempt to do so. > First problem to overcome is that LibreSSL is released every 6 month, > so the work is probably going to be split on two or more releases. Not necessarily. Work on such a task is likely to be started right after a release, and if restructuring work of such a kind is started, there is usually an interest to not drag it out over a very long time, if that is feasible. No guarantee, obviously. > As a consequence, the transition work cannot start on OpenSSH > before the next LibreSSL release Not true. The transition work on OpenSSH can start as soon as all required interfaces are available in OpenBSD-current *and* the OpenSSH developers have time to work on it and want to. That said, it is likely that such a work would also be started shortly after an OpenBSD release, to have maximum headroom before the next OpenBSD release, in order to avoid shipping something that is only half-finished or half-tested. > * distributions that decided to phase out OpenSSL 1.0.2 in favor of > OpenSSL 1.1 will have to support an OpenSSH patch that will grow > smaller and smaller at each release. Once again, no, they shouldn't. They ought to build against OpenSSL-1.0 or LibreSSL until an OpenSSH release supporting 1.1 is available. A 3000+ line vendor patch is always a terrible idea, and even more so for an important piece of security software. > BTW, do you know any other software that uses the LibreSSL API the > same way OpenSSH is using it (i.e. LibreSSL is the primary target, > OpenSSL compatibility is of lesser importance)? Here is the list from the OpenBSD base system, only regarding libcrypto. Also checking the OpenBSD ports tree would be too much work, but usually, there is much more stuff in the ports tree than in the base system. program portable version acme-client(8) https://kristaps.bsd.lv/acme-client/ bc(1) dc(1) ftp(1) keynote(1) nc(1) openssl(1) x99token(1) dhcpd(8) httpd(8) https://bsd.plumbing/ iked(8) http://www.openiked.org/ ikectl(8) http://www.openiked.org/ isakmpd(8) ldapctl(8) ldapd(8) login_token(8) npppd(8) ntpd(8) http://www.openntpd.org/ ocspcheck(8) radiusctl(8) radiusd(8) relayd(8) https://bsd.plumbing/ sasyncd(8) smtpd(8) https://www.opensmtpd.org/ smtpctl(8) snmpd(8) spamd(8) spamlogd(8) syslogd(8) tcpdump(8) tokeninit(8) ypldap(8) tls_init(3) Yours, Ingo _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
