[openssl-users] [openssl-announce] Forthcoming OpenSSL releases

[Jakob Bohm]

Nice, so the extra work is minimal for complete forks of
OpenSSL.

The extra work is also documented (in a place not linked from
the wiki) for those who maintain a git fork of the OpenSSL
repository.

But I have not yet seen a meaningful recipe for those of us
who maintain a traditional set of feature patches against
the released tarballs, nicely organized for future
contribution.

Maybe they want us all to fork OpenSSL :-)

On 18/03/2015 13:55, John Foley wrote:
> We maintain our own derivative of OpenSSL and haven't had any 
> significant issues due to the code reformat.  We simply run the 
> reformat script on our downstream derivative.  We can then generate 
> patch files of our changes and reapply them to new OpenSSL releases.  
> It was fairly straight forward.
>
> IMHO, the code reformat was long overdue.  The prior lack of 
> consistent coding style was an abomination, making the code more 
> difficult to read and maintain.  Sometimes taking a step forward 
> results in some pain.  This was a good investment for the future.
>
> +1 for the reformat.
>
>
>
> On 03/18/2015 06:45 AM, Jakob Bohm wrote:
>> On 18/03/2015 10:14, Matt Caswell wrote:
>>> On 18/03/15 07:59, Jakob Bohm wrote:
>>>> (Resend due to MUA bug sending this to -announce)
>>>>
>>>> On 16/03/2015 20:05, Matt Caswell wrote:
>>>>> Forthcoming OpenSSL releases
>>>>> ============================
>>>>>
>>>>> The OpenSSL project team would like to announce the forthcoming release
>>>>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>>>
>>>>> These releases will be made available on 19th March. They will fix a
>>>>> number of security defects. The highest severity defect fixed by these
>>>>> releases is classified as "high" severity.
>>>> Just for clarity in preparing to use the forthcoming
>>>> update:
>>>>
>>>> Has the 1.0.1m source code been mangled by the script that
>>>> made it near-impossible to port local changes to 1.0.2, or
>>>> will it retain the same code formatting as in the rest of
>>>> the 1.0.1 series?
>>>>
>>>> Similarly, will 1.0.0r be mangled or will it retain the
>>>> same code formatting as in the rest of the 1.0.0 series?
>>>>
>>>> Similarly, will 0.9.8zf be mangled or will it retain the
>>>> same code formatting as in the rest of the 0.9.8 series?
>>> I prefer the term "improved" over "mangled"! ;-)
>>>
>>> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
>>> been reformatted according to the new coding style.
>>>
>>> It is perfectly possible, if a little fiddly, to reformat your local
>>> patches to the new style. I have done so myself for a number of my own
>>> patches. I included some outline instructions on how to do it in my
>>> recent blog post on the reformat:
>>>
>>> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
>> Long read, and lots of internal details of how your script
>> doesn't even work for yourown code...
>>
>> However the patch rebasing instructions are *completely
>> useless* for those of us whomaintain private patches
>> against releases tarballs.  We *don't* have any of this
>> in a clone of your gitand we *have no way* to access
>> intermediary git steps from your partially botched
>> freeze-reformat-unfreeze-other-work-oopsmorereformat-
>> other-work sequence.
>>
>> I guess each of us will have to spend weeks (or more)
>> manually recreating all our hard work before we can apply
>> whatever security fixes are hidden in tomorrows tarball.
>>
>> And it also seems that it is nearly impossible to turn the
>> changes into a reviewable patch that can be applied to an
>> existing tree, like the various distributions (on and off
>> the vendor-sec lists) will need to.
>>
>> So let's all hope one of the vendors will do your job for
>> you and transform the new releases into patches against
>> the previous tarballs, before the embargo is lifted
>> tomorrow, or soon after.
>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded