On 04/15/18 07:53, Viktor Dukhovni wrote: > > >> On Apr 15, 2018, at 1:38 AM, Richard Levitte <[email protected]> wrote: >> >> Errr, are we? Please inform me, because I cannot remember having seen >> tests that specifically targets the case of programs built with 1.1.0 >> that get implicitly relinked with 1.1.1 libraries (that's what you >> call "going forward", isn't it?), or data collection for that matter. >> I may have missed something, but I am interested. > > It think it is most prudent to not fall into the trap of debating this > particular side-issue. I commend your initiative of running the 1.1.0 > tests against the 1.1.1 libraries, that's fantastic. And I further > commend attention to the failure cases. Thank you. > > With that out of the way, it seems to me that apart from some fixes in > the test framework, and tests that did not expect protocol versions > higher than TLS 1.2, no *interesting* issues have turned up. > > If such issue did or will turn up let's fix them, but there should not > be fundamental obstacles to an ABI-compatible 1.1.1 library with the > same SONAME as its 1.1.0 predecessor. The new library may negotiate > TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility > that requires an SONAME version bump. > > Which is not to say I could not be convinced otherwise, but at present > I don't see a need for the bump, or for work-arounds to limit the > negotiated protocols for code compiled against 1.1.0 that happens to > run against 1.1.1. > > Let's stay alert, but not overreact to minor issues we can resolve. >
One possible example of application failure that I am aware of is #5743: A certificate that is incompatible with TLS1.3 but works with TLS1.2. Admittedly that I did come up with that scenario only because I saw a possible issue per code inspection. Bernd. _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
