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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
