Comment 12 for bug 1979639

On Thu, Jul 14, 2022 at 03:56:04PM -0000, David Zuelke wrote:
> So I think a big class of programs to consider that are affected by this
> potentially are those that use a statically linked OpenSSL v1, not just
> Node.js or any leftover programs that dynamically link against
> libssl1.1.
>
> And that's... a lot of software off the internet ;)

This is true. Maybe we need to be pragmatic about this type of case. I'd
like to see some data on what's actually affected though.

Regardless, such programs are buggy. They're not properly built if they
have a dependency on the system /etc by assuming libssl1.1 is available
on the system like this. This is a perfect demonstration of how merely
asking the linker to link statically does not result in a properly
independent binary.

In our ecosystem it's pretty unusual for there to be an expectation that
binaries will continue working following distribution release upgrades
like this, and if they don't, usually the third party distributor is
expected to produce a fixed binary. And if we do choose to maintain
compatibility, then this stifles improvements. What's the time limit for
backwards incompatibility like this? Usually a major distribution
release upgrade is the appropriate time to make these kinds of breaking
changes.

I have no issue with pragmatically arranging the configuration to be
backwards compatible for a while. But the time to do this is before
release. Doing it after is much riskier, and so we should be more
cautious. The people affected who want the change are not the people who
would be affected and be forced to deal with any fallout.

So how big is this impact really? That's why I'd like to see the
evidence.