[openssl-users] [openssl-announce] Forthcoming OpenSSL releases
jb-openssl at wisemo.com
Wed Mar 18 14:38:54 UTC 2015
Nice, so the extra work is minimal for complete forks of
The extra work is also documented (in a place not linked from
the wiki) for those who maintain a git fork of the OpenSSL
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
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
>>>> 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:
>> 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
>> 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.
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
More information about the openssl-users