Backports to 1.1.1 and what is allowed

Benjamin Kaduk kaduk at
Wed Jun 17 03:43:35 UTC 2020

On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote:
> PR 11188 proposes to backport a series of s390x patches to the 1.1.1
> branch. IIUC it includes performance improvements as well as support for
> new hardware instructions.
> I think we need to have a much clearer and more explicit policy about
> exactly what is allowed to be backported to a stable branch. For example
> PR #11968 was a significant recent PR that backported AES CTR-DRBG
> performance improvements to the 1.1.1 branch and was allowed (should it
> have been?).

I am happy to see 11968 landed; some informal testing that I hope to make
more formal soon seems to show a ~20% slowdown/regression for large RNG
requests going from 1.1.1d to 1.1.g, and 11968 provided substantially more
significant of a speedup (again, very informal testing, though).

In this case you could say that the "bug" is that we're only calling AES on
a block at a time despite having much more effective backends available for
multi-block calls.

> We have always said that the stable releases should only receive bug and
> security fixes. Performance improvements have been a bit of a grey area,
> e.g. a few lines of code that significantly improves the performance of
> a particular algorithm or codepath could reasonably be justified as
> "fixing a performance bug". OTOH bringing in whole new files of
> assembler seems to go way beyond that definition.

There's probably some semi-subtle distinction to make along the lines of
"making the algorithm more efficient" vs "using a new algorithm, that
happens to run faster", with the latter counting as a feature.

> However, when I tried to find a reference to the policy which says
> exactly what we are allowed to backport I could find one. Do we have
> such a thing?
> In any case I think we should develop a much more explicit policy that
> will enable us to decide whether PRs such as 11188 are reasonable or
> not. See for example Ubuntu's Stable Release Updates policy:

I agree that having something written down will be very useful, even if
just as a fixed benchmark against which to think about how exceptional any
given "exception case" is where we want to deviate from it.


> Matt

More information about the openssl-project mailing list