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
