[tottenhm]

Yeah, in the long run, breaking compatibility is totally understandable for a fork. And generally... power-to-them in publishing a free/open/quality SSL implementation.

But... the article also says:

> ... it is not possible to install both OpenSSL and LibreSSL on the same system.

That combination -- not-compatible and not-coexisting -- sounds rough.

[kazinator]

> Yeah, in the long run, breaking compatibility is totally understandable for a fork.

Sure, in the long run, when you've overtaken the original and sent it into obsolescence. I.e. at approximately that point where even the original would have deviated from compatibility.

In the short run, drop-in replace, or perish.

Linux still follows POSIX. I can make a program that is source-code compatible with GNU/Linux, Solaris, Cygwin, MacOS, Android/Bionic, ...

If I can't do that between two SSL implementations, something is wrong.

[mgorny]

If it only were that simple.

Imagine you're maintaining some program that intensively uses OpenSSL. It's 2014-ish, and some LibreSSL people come to you and tell you that you're using deprecated API and you need to upgrade for compatibility with LibreSSL. Sure, it's an improvement and maintains compatibility with OpenSSL, so why not.

Then OpenSSL 1.1 comes with some more API changes. You end up adding #if conditions to support both OpenSSL versions. And the next thing you realize, you've just broken LibreSSL because it pretends to be OpenSSL 2.0.0.

And when you patch it, you realize you're adding another ticking time bomb because LibreSSL will probably support the new API at some point too and you will have to add yet another version check to the code.

I am not surprised that somewhere in middle of that process upstreams stop taking LibreSSL seriously.

[tottenhm]

Right, sprinkling #if's across a dozen downstream codebases sucks.

Consider an analogy to shell-scripting -- there are different shells ("bash", "dash", "zsh") which have substantial overlap (insofar as they largely support traditional POSIX). Someone writing a script/program can target a specific flavor ("#!/usr/bin/env bash") and get more features, or they can write conservative code and let downstream policy determine the shell ("#!/bin/sh"). General-purpose distros (like Debian/Redhat) don't seem to have a problem with supporting them side-by-side.

I'm more than a little rusty on the mechanics of dependency-management in C... but shouldn't it allow some analogous arrangement where an app either (a) signals a requirement for a specific implementation or (b) signals ambivalence/deference (and limits itself to common APIs).

(This, of course, only makes sense if the developers of LibreSSL/OpenSSL and of the distros believe that it's better to coexist+compete than to consolidate. The tenor of the LWN article seems to convey a XOR mentality, but if both projects have independently healthy teams, then... maybe they prefer friendly coopetition...)