[openssl-users] [openssl-announce] Forthcoming OpenSSL releases

Thu Mar 19 01:22:12 UTC 2015

Hello,

Here is a recipe to guide you through the reformatting.
It worked nicely for me. I wrote a small bash shell script
which helped me do the bulk conversion, see attachment
Hope you'll find this information helpful.

In following I briefly describe the steps how you can

 1) get your patches into git (if not yet done)
 2) do the reformatting of the commits in git, with the
    help of my script
 3) rebase your patches to the current release
 4) recreate the patches using 'git format-patch'

If your patches are already maintained in a git repository,
you may skip step 1)

1) If you only have patches, it's a good idea to get
your own clone of the git repository

   git clone git://git.openssl.org/openssl.git
   cd openssl

now create a branch off the vanilla release to
which your patches apply (say, OpenSSL 1.0.1k)

   git checkout -b mypatches OpenSSL_1_0_1k

apply your patches one after the other, creating
a single commit for each with meaningful commit
messages

  (If you don't know how to do this in git, you may
   want to see http://git-scm.com/doc)

2) Now we assume that
  a) you already have an OpenSSL git repository
  b) your patches are on a branch called 'mypatches',
     which were branched from one of the stable branches
	 before the reformatting (say OpenSSL_1_0_1-stable)
  c) your working copy is clean (no local changes or
     untracked files)
  d) you're running linux (if not, get yourself a Linux VM)

The attached script shows an example of how to automate
the procedure of reformatting every single commit on your
branch and recommitting it. It contains a lot of comments
to explain what it is doing. PLEASE READ THE COMMENTS
CAREFULLY BEFORE RUNNING THE SCRIPT! 

You just have to set the two variables 'branch' and 'upstream' 
at the beginning of the script (marked 'todo') to the name
of your branch and its upstream branch, respectively.

3) After the script has succeeded, you can rebase your
reformatted branch to the head of the stable branch (or
to the tag of the most recent release), e.g.

git checkout -b mypatches-reformatted mypatches-post-auto-reformat
git rebase OpenSSL_1_0_1-stable

4) Now you can have git recreate your patches automatically
with a single command:

git format-patch $(git merge-base HEAD OpenSSL_1_0_1-stable)..HEAD

[5) Now you can keep using the git repository to manage new patches.
	Due the rebasing capabilites of git, your patches will always
	be up to date ]

DISCLAIMER

The script is not 100% fool-proof, it's a demonstration
which may serve as a starting point for you.
In particular, there is no error recovery and no guarantee,
if there are any conflicts or errors in the middle of the
reformating procedure.

So you'll better try it on a copy of your git repository
first.

-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von
Jakob Bohm
Gesendet: Mittwoch, 18. März 2015 15:39
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reformat.sh
Type: application/octet-stream
Size: 2200 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/a3ab5c37/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/a3ab5c37/attachment.bin>