On 12/14/20 4:37 PM, Konstantin Belousov wrote: > On Mon, Dec 14, 2020 at 11:44:27AM -0800, John Baldwin wrote: >> If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are >> no longer having to maintain 1.1.1 in 13. If people want to keep older >> applications built on unsupported releases still working without >> recompiling, etc. they will have to manage that themselves. Currently >> we don't support 12.0 on the 12.x branch for example. > What do you mean by 'not supported'? Don't we put large efforts into > keeping ABI backward compatible to allow to run _any_ binary built early ? > The only exception I can think of is that we allow ABI mistakes on HEAD > to be fixed in non-backward compatible way. > > But for 12.0-built binaries, we offer full support. In fact it is the easiest > case, if comparing e.g. with binaries built against older branches. > > It is possible to bump dso version on stable branch, which I believe was > already done several times. In this case, we provided compatXx-<arch> > for stable/X branch, which contiained shared objects with previous versions.
So to be clear, my suggestion was precisely to bump the shared library and ship the 1.1.1 libraries in misc/compat13 packages, and while yes, binaries would still work (so be supported in that sense), they would not be supported in the sense of getting SA backports for bugs in the old libssl they are linked against. The cases that suck is if due to library dependencies a process pulls in both libssl.so.X verisons in the same binary. We could use symbol versioning to at least ensure a given DSO always gets the symbols it linked against, but it wouldn't solve the problem of a library returning a SSL * handle to another DSO that is linked against the other version. I do think though that sort of cross-threading is perhaps rarer with libssl than it would be with, say, libc where the malloc/free cross-threading is very common and breaks horribly. -- John Baldwin _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
