On 04/15/18 07:53, Viktor Dukhovni wrote:
> 
> 
>> On Apr 15, 2018, at 1:38 AM, Richard Levitte <levi...@openssl.org> 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
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to