Viktor Dukhovni:
> On Sun, Mar 10, 2019 at 12:29:44PM -0400, Wietse Venema wrote:
>
> > > My preference would be to press on with 3.4 (I don't mind packaging the
> > > bug
> > > fixes if you don't mind releasing them), but if you are going to withdraw
> > > 3.4
> > > please do it before next Sunday so I can keep it out of the next Debian
> > > release.
> >
> > We know of multiple bugs that broke 'desirable functionality' after
> > an overhaul of the TLS stack, and that were kindly brought to the
> > developer's attention by folks like you.
> >
> > I have to consider the possibility that the same overhaul introduced
> > an equal if not larger number of bugs with 'undesirable functionality',
> > and that these bugs will be found by not-so-kind folks, who will
> > report them only if it helps to promote themselves while at the
> > same time destroying Postfix's good reputation.
>
> Some of the changes in 3.4 are quite useful when Postfix is compiled
> with OpenSSL 1.1.1, which introduces TLS 1.3.
>
> My sense is that the situation is not so dire as to warrant retracting
> the release. The recent changes in 3.4 are:
>
> - Support for server-side SNI, with new code to load multi-algorithm
> certificate chain sets. This also loads the key + cert in a
> single pass when both are in the same file, now with the correct
> test for the return value (first report bug) and tests.
>
> - More diligent tlsproxy(8) checking for compatible parameters in TLS
> connection re-use. The tlsproxy connection re-use was added earlier,
> and the more recent changes just fine-tune context sharing.
>
> - Removal of support for OpenSSL 1.0.2. Reduces the attack
> surface and intoduces no new code.
>
> This was however the source of the present (second) reported
> bug, because an #ifdef guard testing for 1.0.2 or later that
> should have been removed, was left in place.
>
> - Consolidation of TLS summary logging, and better logging of
> TLS 1.3 handshake properties.
>
> Looking over the various changes again, I think 3.4 is fine. I'll
> do another code review this week.
You are looking from the "we made improvements" angle. I am looking
from the "with hard work, we introduce 1 bug in 1000 lines of new
code" angle.
In the TLS library there were 1039 additions and 559 deletions from
Postfix 3.3.3 to 3.4.1 (diff -bur --new-file for 'c' and 'h' files
only, excluding proxy-related code). That count does not distinguish
between low-impact changes that affect only nearby code, and
high-impact changes that affect multiple lines, such as global ifdefs.
The changes among those 1600 lines that 'broke' intended functionality
are 'easy' to weed out - just wait for people to to report breakages.
Such a reactive approach might be acceptable in some projects.
I am concerned about the changes among those 1600 lines that did
NOT break intended behavior, but that introduced some other problem.
What is the basis for confidence that no such problems have been
introduced, if we obviously missed multiple things that could have
been found with simple tests?
Wietse
