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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/de0746b6/attachment.html>
