[openssl-users] [openssl-announce] Forthcoming OpenSSL releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as high severity. This defect does not affect the 1.0.0 or 0.9.8 releases. Yours The OpenSSL Project Team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM 2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ= =yVBV -END PGP SIGNATURE- ___ openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
On Wed, Mar 18, 2015 at 5:14 AM, Matt Caswell m...@openssl.org 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. +1 on the reformatting. My eyes no longer bleed when looking at some of the sources. Its an unfortunate side effect that its going to negatively affect some folks in the short term, but its a good long term decision for the health of the project. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
I just posted an updated version of my script in a new thread, titled Minimizing the pain of reformatting your OpenSSL patches Regards, msp On 03/19/2015 02:22 AM, Dr. Matthias St. Pierre wrote: 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. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
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
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
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/ Regards Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
(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? 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
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
On 18/03/15 10:45, Jakob Bohm wrote: 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. There should be no reason why the instructions cannot be adapted to patch files, if that is what you are using. You will still need access to git to do it - but the git repository is publicly accessible. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
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
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
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. I just tossed together https://wiki.openssl.org/index.php/Code_reformatting Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development 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. Folks had months of warning that this was going to happen. And, frankly, patches did not come flooding into the team. But I hope the above link helps. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
Thanks for the three line upgracde recipe in https://wiki.openssl.org/index.php/Code_reformatting It's as simple as you stated, indeed. The reformatting was a good thing to do. Also, it makes sense to me to apply it to all stable branches uniformly, in order to simplify cross-branch merging. msp On 03/18/2015 04:32 PM, Salz, Rich wrote: 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. I just tossed together https://wiki.openssl.org/index.php/Code_reformatting Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development 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. Folks had months of warning that this was going to happen. And, frankly, patches did not come flooding into the team. But I hope the above link helps. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
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-boun...@openssl.org] Im Auftrag von Jakob Bohm Gesendet: Mittwoch, 18. März 2015 15:39 An: openssl-users@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
