On Monday 22 October 2018 19:30:02 Alexander Bluhm wrote: > On Mon, Oct 22, 2018 at 11:10:49AM -0600, Theo de Raadt wrote: > > I understand the difficulty pointed out by the first questions. What > > bothers me is the last question. It indicates a desire to support many > > generations of software. Any attempt at that risks a mistake supporting > > today or tomorrow. As we've seen time and time again. > > Usually I only care about LibreSSL-current for OpenBSD. I add > defined(LIBRESSL_VERSION_NUMBER) until the module compiles and tests > pass. Then I push it upstream.
The problem is then ensuring that these are later removed as necessary. > But this Perl module is also used on non-OpenBSD systems with a > released version of LibreSSL. And there LibreSSL is not -current > and may be older. If I push a change that enables a feature without > version check, it will break older systems. And the Perl eco system > assumes that you can update libraries and modules independently to > a certain extent. > > Doing the right thing for OpenBSD is easy. Having a general solution > for Linux with LibreSSL is not. Indeed. Having feature flags/defines in OpenSSL would be another possible way to solve this, however we're largely stuck with OPENSSL_NO_* (which are useless/problematic in various ways).
