Backports to 1.1.1 and what is allowed

[Dr Paul Dale]

I’d also support 11968 being merged.  I find the recent discussion and the likelihood of all major distros (supporting the S390x) picking up the patches fairly compelling, especially since the same people will be maintaining it.

I would need to go and double check the non-S390x specific parts for possible breakage but the bulk of the changes are S390x specific.


I support formalising the rules better than we have at the moment.  Even if this is in conflict with the above.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 17 Jun 2020, at 1:43 pm, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> 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.
> 
> -Ben
> 
>> https://wiki.ubuntu.com/StableReleaseUpdates
>> 
>> 
>> Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200617/bc242dc9/attachment-0001.html>