<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 18/03/2015 10:14, Matt Caswell
wrote:<br>
</div>
<blockquote cite="mid:550941F5.5040106@openssl.org" type="cite">
<pre wrap="">On 18/03/15 07:59, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">(Resend due to MUA bug sending this to -announce)
On 16/03/2015 20:05, Matt Caswell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/">https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/</a>
</pre>
</blockquote>
<tt>Long read, and lots of internal details of how your script<br>
doesn't even work for your</tt><tt> </tt><tt>own code...</tt><tt><br>
</tt><tt><br>
</tt><tt>However the patch rebasing instructions are *completely<br>
useless* for those of us who</tt><tt> </tt><tt>maintain private
patches<br>
against releases tarballs. We *don't* have any of this<br>
in a clone of your git</tt><tt> </tt><tt>and we *have no way* to
access<br>
intermediary git steps from your partially botched</tt><tt><br>
</tt><tt>freeze-reformat-unfreeze-other-work-oopsmorereformat-<br>
other-work sequence.</tt><tt><br>
</tt><tt><br>
I guess each of us will have to spend weeks (or more)<br>
manually recreating all our hard work before we can apply<br>
whatever security fixes are hidden in tomorrows tarball.<br>
<br>
And it also seems that it is nearly impossible to turn the<br>
changes into a reviewable patch that can be applied to an<br>
existing tree, like the various distributions (on and off<br>
the vendor-sec lists) will need to.<br>
<br>
So let's all hope one of the vendors will do your job for<br>
you and transform the new releases into patches against<br>
the previous tarballs, before the embargo is lifted<br>
tomorrow, or soon after.<br>
</tt><br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>