https://wiki.openssl.org/api.php?action=feedcontributions&user=Aponomarenko&feedformat=atomOpenSSLWiki - User contributions [en]2024-03-29T05:29:47ZUser contributionsMediaWiki 1.35.6https://wiki.openssl.org/index.php?title=ABI_Tracker&diff=2726ABI Tracker2018-09-13T13:37:31Z<p>Aponomarenko: /* Prepare configuration file */ fix for 1.1</p>
<hr />
<div>[[File:openssl-abi-tracker.jpg]]<br />
<br />
One can set up a local ABI tracker in order to automate [[Binary_Compatibility|binary compatibility]] analysis for sequential releases of the OpenSSL by following the instructions below.<br />
<br />
You can find live setup of this tracker on [http://abi-laboratory.pro/tracker/timeline/openssl/ this page] maintained by Andrey P.<br />
<br />
== Prepare configuration file ==<br />
The initial point is to create main configuration file (openssl.json):<br />
{<br />
"Name": "openssl",<br />
"Title": "OpenSSL",<br />
"SourceUrl": "https://www.openssl.org/source/",<br />
"Git": "https://github.com/openssl/openssl.git",<br />
"Maintainer": "Maintainer Name",<br />
"BuildScript": "build_script/openssl.sh",<br />
"SkipObjects": [ "engines/" ],<br />
"HeadersDiff": "Off",<br />
"LetterReleases": "On"<br />
}<br />
<br />
The referred build script (build_script/openssl.sh) is:<br />
./config -d --prefix="$INSTALL_TO" shared<br />
sed -i -e 's/ \-O0 / -g -Og /' Makefile<br />
sed -i -e 's/ \-g/ -g -Og/' Makefile<br />
make<br />
make install_sw<br />
<br />
== Download and build previous releases ==<br />
The second step is to install [https://github.com/lvc/abi-monitor abi-monitor] tool and then download and build sources of previous releases of the library:<br />
abi-monitor -get -build openssl.json<br />
<br />
This command will extend the openssl.json file with the list of built versions.<br />
<br />
== Perform the analysis ==<br />
The final step is to install [https://github.com/lvc/abi-tracker abi-tracker], [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] and [https://github.com/lvc/abi-dumper abi-dumper] tools and then create ABI dumps and compatibility reports for all built versions of the library:<br />
abi-tracker -build openssl.json<br />
<br />
The report should be generated to: timeline/openssl/index.html<br />
<br />
== Daily run ==<br />
To perform daily update of the report you can add these commands to your crontab:<br />
abi-monitor -get -build-new openssl.json # download and build new releases only<br />
abi-tracker -build openssl.json # update ABI dumps and report<br />
<br />
Enjoy!</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2725Binary Compatibility2018-09-13T13:35:38Z<p>Aponomarenko: /* Build two versions of the library with debug info */ fix for 1.1</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / -g -Og /' Makefile<br />
sed -i -e 's/ \-g/ -g -Og/' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (1.0 Beta or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2c.abi -new libssl-1.0.2d.abi -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2528Binary Compatibility2017-02-26T06:20:07Z<p>Aponomarenko: /* Compare ABI dumps to produce report */</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (1.0 Beta or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2c.abi -new libssl-1.0.2d.abi -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2527Binary Compatibility2017-02-26T06:19:49Z<p>Aponomarenko: /* Make ABI dumps of the library versions */</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (1.0 Beta or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2.c.abi -new libssl-1.0.2.d.abi -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2526Binary Compatibility2017-02-26T06:19:12Z<p>Aponomarenko: /* Compare ABI dumps to produce report */</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (1.0 Beta or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2.d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2.c.abi -new libssl-1.0.2.d.abi -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2525Binary Compatibility2017-02-26T06:17:42Z<p>Aponomarenko: /* Make ABI dumps of the library versions */</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (1.0 Beta or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2.d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2.c.abi -new libssl-1.0.2.d.abi -headers-list ./headers.list -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=User:Aponomarenko&diff=2447User:Aponomarenko2016-08-20T08:17:55Z<p>Aponomarenko: Fixed formatting</p>
<hr />
<div>Andrey Ponomarenko.<br />
<br />
Maintainer of binary compatibility reports for OpenSSL.<br />
<br />
Responsible for pages:<br />
* [[Binary_Compatibility]]<br />
* [[ABI_Tracker]]<br />
<br />
WWW: http://abi-laboratory.pro/<br />
<br />
Linkedin: https://www.linkedin.com/in/andreyponomarenko</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=User:Aponomarenko&diff=2446User:Aponomarenko2016-08-20T08:17:31Z<p>Aponomarenko: Add more connection info</p>
<hr />
<div>Andrey Ponomarenko.<br />
<br />
Maintainer of binary compatibility reports for OpenSSL.<br />
<br />
Responsible for pages:<br />
* [[Binary_Compatibility]]<br />
* [[ABI_Tracker]]<br />
<br />
WWW: http://abi-laboratory.pro/<br />
Linkedin: https://www.linkedin.com/in/andreyponomarenko</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=ABI_Tracker&diff=2335ABI Tracker2015-12-17T12:29:35Z<p>Aponomarenko: Move the picture up to the top of the page</p>
<hr />
<div>[[File:openssl-abi-tracker.jpg]]<br />
<br />
One can set up a local ABI tracker in order to automate [[Binary_Compatibility|binary compatibility]] analysis for sequential releases of the OpenSSL by following the instructions below.<br />
<br />
You can find live setup of this tracker on [http://abi-laboratory.pro/tracker/timeline/openssl/ this page] maintained by Andrey P.<br />
<br />
== Prepare configuration file ==<br />
The initial point is to create main configuration file (openssl.json):<br />
{<br />
"Name": "openssl",<br />
"Title": "OpenSSL",<br />
"SourceUrl": "https://www.openssl.org/source/",<br />
"Git": "https://github.com/openssl/openssl.git",<br />
"Maintainer": "Maintainer Name",<br />
"BuildScript": "build_script/openssl.sh",<br />
"SkipObjects": [ "engines/" ],<br />
"HeadersDiff": "Off",<br />
"LetterReleases": "On"<br />
}<br />
<br />
The referred build script (build_script/openssl.sh) is:<br />
./config -d --prefix="$INSTALL_TO" shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Download and build previous releases ==<br />
The second step is to install [https://github.com/lvc/abi-monitor abi-monitor] tool and then download and build sources of previous releases of the library:<br />
abi-monitor -get -build openssl.json<br />
<br />
This command will extend the openssl.json file with the list of built versions.<br />
<br />
== Perform the analysis ==<br />
The final step is to install [https://github.com/lvc/abi-tracker abi-tracker], [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] and [https://github.com/lvc/abi-dumper abi-dumper] tools and then create ABI dumps and compatibility reports for all built versions of the library:<br />
abi-tracker -build openssl.json<br />
<br />
The report should be generated to: timeline/openssl/index.html<br />
<br />
== Daily run ==<br />
To perform daily update of the report you can add these commands to your crontab:<br />
abi-monitor -get -build-new openssl.json # download and build new releases only<br />
abi-tracker -build openssl.json # update ABI dumps and report<br />
<br />
Enjoy!</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=User:Aponomarenko&diff=2323User:Aponomarenko2015-10-26T13:35:54Z<p>Aponomarenko: About me</p>
<hr />
<div>Andrey Ponomarenko.<br />
<br />
Maintainer of binary compatibility reports for OpenSSL.<br />
<br />
Responsible for pages:<br />
* [[Binary_Compatibility]]<br />
* [[ABI_Tracker]]<br />
<br />
WWW: http://abi-laboratory.pro/</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2322Binary Compatibility2015-10-26T12:24:36Z<p>Aponomarenko: Fixed internal link</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI Tracker|ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (0.99.11 or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2.d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2.c.abi -new libssl-1.0.2.d.abi -headers-list ./headers.list -report-path ./report.html</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=ABI_Tracker&diff=2321ABI Tracker2015-10-26T12:23:33Z<p>Aponomarenko: Instructions on how to track ABI changes</p>
<hr />
<div>One can set up a local ABI tracker in order to automate [[Binary_Compatibility|binary compatibility]] analysis for sequential releases of the OpenSSL by following the instructions below.<br />
<br />
You can find live setup of this tracker on [http://abi-laboratory.pro/tracker/timeline/openssl/ this page] maintained by Andrey P.<br />
<br />
== Prepare configuration file ==<br />
The initial point is to create main configuration file (openssl.json):<br />
{<br />
"Name": "openssl",<br />
"Title": "OpenSSL",<br />
"SourceUrl": "https://www.openssl.org/source/",<br />
"Git": "https://github.com/openssl/openssl.git",<br />
"Maintainer": "Maintainer Name",<br />
"BuildScript": "build_script/openssl.sh",<br />
"SkipObjects": [ "engines/" ],<br />
"HeadersDiff": "Off",<br />
"LetterReleases": "On"<br />
}<br />
<br />
The referred build script (build_script/openssl.sh) is:<br />
./config -d --prefix="$INSTALL_TO" shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Download and build previous releases ==<br />
The second step is to install [https://github.com/lvc/abi-monitor abi-monitor] tool and then download and build sources of previous releases of the library:<br />
abi-monitor -get -build openssl.json<br />
<br />
This command will extend the openssl.json file with the list of built versions.<br />
<br />
== Perform the analysis ==<br />
The final step is to install [https://github.com/lvc/abi-tracker abi-tracker], [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] and [https://github.com/lvc/abi-dumper abi-dumper] tools and then create ABI dumps and compatibility reports for all built versions of the library:<br />
abi-tracker -build openssl.json<br />
<br />
The report (timeline/openssl/index.html) should look like:<br />
<br />
[[File:openssl-abi-tracker.jpg]]<br />
<br />
== Daily run ==<br />
To perform daily update of the report you can add these commands to your crontab:<br />
abi-monitor -get -build-new openssl.json # download and build new releases only<br />
abi-tracker -build openssl.json # update ABI dumps and report<br />
<br />
Enjoy!</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=File:Openssl-abi-tracker.jpg&diff=2320File:Openssl-abi-tracker.jpg2015-10-26T12:19:19Z<p>Aponomarenko: Aponomarenko uploaded a new version of &quot;File:Openssl-abi-tracker.jpg&quot;</p>
<hr />
<div>ABI report example</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=File:Openssl-abi-tracker.jpg&diff=2319File:Openssl-abi-tracker.jpg2015-10-26T12:05:00Z<p>Aponomarenko: ABI report example</p>
<hr />
<div>ABI report example</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Unit_Testing&diff=2318Unit Testing2015-10-26T10:35:36Z<p>Aponomarenko: /* Improved Patch/Cherry-pick Process */ Move links to a separate page with the short description of how to use it.</p>
<hr />
<div>This page will track the effort to improve unit test and other automated test coverage for OpenSSL. Everyone is encouraged to help with this effort, but this page will track which community members have accepted specific responsibilities, and what tasks are currently underway.<br />
<br />
== Goals ==<br />
<br />
The goals of this project are:<br />
<br />
* Establish a written contribution/code review policy that requires:<br />
** tests for every new code change, except for very trivial changes that do not directly impact program logic (e.g. documentation fixes, string constant updates, build script tweaks); this can be limited to an agreed-upon subset of the code to start, but would hopefully be expanded to cover most, if not all, of the code base<br />
** tests for every bugfix <br />
** smaller, well-tested changes building up to a complete feature (as opposed to large and/or untested changes that implement a large, complex feature all at once) <br />
* Establish a schedule of Build Cops and Tutors to begin enforcing rollbacks/fixes and to help shepherd new contributors through the testing process.<br />
* Set up a series of publicly-accessible continuous integration servers using whatever system the community prefers (e.g. Jenkins, Buildbot, etc.). These can be dedicated hardware or possibly Amazon Web Services-based. Establish a written policy that these remain green at all times, and that breakages be rolled-back or fixed within no more than 30 minutes.<br />
<br />
We can add more concrete goals to this list after we make progress on these. Getting people to own roles, setting up build infrastructure, and setting and enforcing policy are important first steps. Upon that foundation, we can begin to make serious progress towards improved test coverage, code quality, and defect prevention.<br />
<br />
== Discussion List ==<br />
[https://groups.google.com/d/forum/openssl-testing openssl-testing] is the mailing list dedicated to the unit/automated testing effort, to avoid clogging openssl-dev. Membership is open to whoever wishes to join, even if only to lurk. Ideally all testing discussions will eventually move to openssl-dev once we have processes, tools, conventions, etc. in place.<br />
<br />
== Team ==<br />
<br />
We can define new roles as needed. The success of this effort will be inversely proportional to the number of roles with any one individual's name next to them. Each role can have more than one person filling it, but needs specific people to fill them. <br />
<br />
The point is not to tell people what to do and not do: it’s to establish clear responsibilities so everyone can run with them right away and begin applying their creative energy to solutions, rather than waste it figuring out what the hell is going on, what they should do to contribute, and who they need to coordinate with to get things done.<br />
<br />
=== Organizer===<br />
<br />
Contact: [mailto:mbland@acm.org Mike Bland]<br />
<br />
Ensures the overall effort is making progress by facilitating communication, removing obstacles, and making hands-on contributions when necessary.<br />
<br />
=== Tech Writer ===<br />
<br />
Contacts: [mailto:mbland@acm.org Mike Bland], Sandeep Mankar, Chelsea Komlo, Graham Brooks, Lisa Carey<br />
<br />
Maintains documentation of tools, techniques, outstanding issues, etc. May maintain a code review/testing style guide based on the community consensus. Also documents who currently fills each role, as well as who might've filled it in the past.<br />
<br />
=== Buildmaster ===<br />
<br />
Contacts: [mailto:mbland@acm.org Mike Bland], Isaac Truett, Dileep Bapat, Graham Brooks<br />
<br />
Sets up and maintains automated builds and any infrastructure used to monitor them and report breakage.<br />
<br />
=== Toolsmith ===<br />
<br />
Contact: Tony Aiuto<br />
<br />
Maintains any tools and frameworks that are a part of the core build process; proposes, integrates, and/or retires existing tools.<br />
<br />
=== Tutor ===<br />
<br />
Contacts: [mailto:mbland@acm.org Mike Bland], Darshan Mody, Tom Francis, Brian N. Makin, Edward Knapp, Dileep Bapat, Graham Brooks<br />
<br />
Helps contributors, particularly new contributors, with the details of writing unit or other automated tests. May be assigned by the reviewer of a patch to help a contributor get a new change under test. Submission of the patch should require the approval of the tutor in most cases. (Should ideally be more than one person.)<br />
<br />
== Tasks ==<br />
The current list is posted in the [http://goo.gl/5u9nbw OpenSSL Testing Tasks Google Spreadsheet].<br />
<br />
(Would be nice to enable the [http://www.mediawiki.org/wiki/Extension:Widget MediaWiki Widget extension] and the [http://www.mediawikiwidgets.org/Google_Spreadsheet Google Spreadsheet widget].)<br />
<br />
== Howtos and Style Guides ==<br />
Documents that provide background on specific testing issues and idioms should be linked from here.<br />
<br />
* [[How To Write Unit Tests For OpenSSL]]<br />
* [http://mike-bland.com/2014/06/05/pseudo-xunit-pattern.html The Pseudo-xUnit Pattern]<br />
* [[Testing and Development Tools and Tips]]<br />
<br />
== Discussion Topics ==<br />
These are discussions related to some of the current testing tasks.<br />
<br />
=== First Area of Focus ===<br />
Matt Caswell: One criterion might be ease of testing. If you were going down that route you might choose some of the low level packages within libcrypto which are relatively self-contained. I'm not talking about the crypto algorithms themselves (there are at least *some* tests for those), I'm thinking more about bio, pem, x509, x509v3, etc.<br />
<br />
Another criterion might be where you get the most value. I suspect we will get the most value from a really good set of unit tests for libssl. I suspect this might be a big ask to start off with (you would probably have to mock out a lot of stuff).<br />
<br />
=== Build Systems/Machines ===<br />
Where can we get the machines? Is someone willing to donate them? What system should we use?<br />
<br />
=== Get Unit Tests to Build on Windows ===<br />
Steve Henson on building ssl/heartbeat_test.c on Windows: The first problem is that __func__ isn't understood. Changing that to __FUNCTION__ resolves that easily enough.<br />
<br />
The second problem is more serious. Windows (and a couple of other platforms IIRC) is strict about only exporting approved symbols from global headers in shared libraries and wont export internal only functions.<br />
<br />
That means you get linker errors:<br />
<br />
heartbeat_test.obj : error LNK2019: unresolved external symbol _ssl3_setup_buffe<br />
rs referenced in function _set_up<br />
heartbeat_test.obj : error LNK2019: unresolved external symbol _ssl_init_wbio_bu<br />
ffer referenced in function _set_up<br />
heartbeat_test.obj : error LNK2019: unresolved external symbol _tls1_process_hea<br />
rtbeat referenced in function _set_up_tls<br />
heartbeat_test.obj : error LNK2019: unresolved external symbol _dtls1_process_he<br />
artbeat referenced in function _set_up_dtls<br />
out32dll\heartbeat_test.exe : fatal error LNK1120: 4 unresolved externals<br />
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0<br />
\VC\BIN\link.EXE"' : return code '0x460'<br />
<br />
Potential solutions:<br />
* http://stackoverflow.com/questions/7759777/is-it-possible-to-test-internal-class-from-a-c-dll-using-mstest<br />
* http://stackoverflow.com/questions/19934714/googletest-c-unit-testing-linking-error<br />
* http://stackoverflow.com/questions/14010627/unresolved-externals-when-compiling-unit-tests-for-visual-c-2012<br />
<br />
ifdef'd out (for now): https://github.com/openssl/openssl/commit/7ce79a5bfdbcd53ae75f85e94eed665a05b5dea3<br />
<br />
=== How to Manage Private Symbols ===<br />
Steve Henson: As this also affects other platforms a general solution might be in order.<br />
<br />
One option is to link to static libraries as has been mentioned. If you have a<br />
lot of unit tests you could end up with a lot of large binaries. Would need some<br />
changes to the dreaded Windows build system too.<br />
<br />
A different option would be to export the unit test functions through a<br />
structure pointer which a function returns. So you'd have something like..<br />
<br />
unit_test = SSL_get_unit_test_funcs();<br />
<br />
unit_test.some_internal_funcction(...);<br />
<br />
Where the actual structure is opaque to applications (so they aren't tempted to<br />
poke around in internals) but visible to the unit test code. Then the unit test<br />
code doesn't call any internal functions not defined in there and doesn't need<br />
to load private headers (unless it needs them for some definitions).<br />
<br />
Mike Bland: This is an interesting idea, though I'd expect the unit tests will<br />
still need access to internal headers.<br />
<br />
But I have a question: Why do any of the symbols need to be private?<br />
Is that degree of encapsulation necessary, and does it really<br />
discourage irresponsible clients? The source code is open, so people<br />
can always build their own copy and depend on internals if they really<br />
want to, and the default UNIX/Linux/OS X build (i.e. ./configure &&<br />
make && make test) doesn't lock down internal symbols. Have<br />
dependencies on internal APIs ever been a problem in practice?<br />
<br />
I'm not saying I feel strongly either way, but it seems that clients<br />
should be clear that the public API is what's available in<br />
openssl/include, and shouldn't depend on anything else. I just don't<br />
understand what making symbols private buys anyone in the context of<br />
OpenSSL, in light of how it appears to complicate the ability to unit<br />
test.<br />
<br />
Not trying to be argumentative, I just want to understand the<br />
rationale. I'll work with whatever environment I have to.<br />
<br />
Tom Francis: Making the symbols private allows the link editors on Windows and pretty much every UNIX system that doesn't use GNU ld to:<br />
1) Run much, much faster at link time (not a minor consideration for most of the software I've worked on); and<br />
2) optimize the final binary to load much faster.<br />
Last time I checked, there was a minor improvement for GNU ld for #1, but it's trivial compared to Windows and HP's link editor, e.g. (I can't overstate the difference there). The runtime improvement is also dramatic on Windows, HP-UX, and AIX (we're talking tens for milliseconds for libraries that are much smaller than OpenSSL -- never tried it with OpenSSL, too lazy to mark everything, after having just done so for the library I was really interested in).<br />
<br />
If you want to avoid a bunch of small binaries, you could combine all the unit tests into a single test application, and use multiple runs of it for each test, similar to how the openssl binary is created; if you link the object files directly (or a static library), you avoid the private symbols issue. Of course, this may be an issue for some of the embedded systems, where the loading a large binary for running the tests might not be acceptable (but might be preferable to a bunch of binaries?). Mike Bland was concerned about parallelization, and for any kind of automated tests on commits, that's a big point, if you can guarantee that each system only compiles/executes a limited number of tests (it could be useful for OS vendors, too). For the average OpenSSL user, that's not really a consideration; an average user is more likely concerned with how long (wall clock) it takes to compile and run the tests, and depending on the size of a single binary v the size of each smaller binary, it'll vary from system to system (generally, it'll be many times faster to create a single large binary than a few hundred smaller binaries, but the larger the binary, the longer it takes to load -- at some point, the load time might well outweigh the hundreds of smaller binaries (assuming you execute the large binary several times, rather than have a method for it to execute all tests in a single go). That point is probably > 100MB for larger systems, but for an embedded system, it could be much smaller.<br />
<br />
For Steve's second suggestion, I think my biggest concerns would be how to logically separate out a unit test method without including the test framework (maybe throw it all in there?). I kinda like the idea of keeping the test inside the libraries, but I'm not sure why -- maybe 'cause I recently spent a few months back in a java world, where it's normal to throw all your unit tests into the same jar for production. I'm not sure I like that, though. The overhead of a single function per "module" added to the exports is also unlikely to drastically decrease link-time or run-time performance, too (compared with exporting everything).<br />
<br />
=== Improved Patch/Cherry-pick Process ===<br />
Geoff Thorpe: (a) patches that are not applied/cherry-picked to all the branches they apply to, or (b) applied to more branches than they should be. A complication of (a) is that some patches may need to be reworked in order to apply (or in order to not break binary compatibility of a stable branch). The difficulty of (b) is determining when the nature of the change either breaks [[Binary_Compatibility|binary compatibility]] or causes some other behavioral deviation that is not in keeping with the "promises" of stable branches.<br />
<br />
Geoff on 2014-05-30: ...we might move to a scheme whereby we only maintain one most-recent stable branch for production releases, with snapshots or whatever of the development head. Ie. two branches, one for maximum-compatibility/bug-fixes-only, and the other for more active development. The number of "stable" branches would thus be 1 rather than 'n'. The idea is that we may defer to downstream "slow-moving" users (eg. long-term releases of linux distros) the opportunity to step up and do the work of maintaining (cherry-picking, back-porting, ...) older branches. Ie. what they typically already do in-house, but the opportunity to do it under our roof and thus combine their efforts with any other similarly-interested parties. If there's noone prepared to do that, the logical conclusion is that there is probably no need for it (or so the argument goes).<br />
<br />
=== Improve/Standardize Algorithm Testing ===<br />
Steve Henson: While the algorithms are partly tested I don't think they're anything like comprehensive enough. The way they are handled is also haphazard and spread across multiple tests covering all sorts of odd APIs, some of which are deprecated.<br />
<br />
In fact I'd say they're (with the odd exception) an example of how *not* to do things.<br />
<br />
Examples rc2test tests RC2 it has various test vectors hard coded inconsistent indentation and use of low level APIs. The rc4test is a similar story and uses a different format to rc2test. The same tale is repeated all over the place with ideatest, rmdtest etc etc.<br />
<br />
Then we come to the code which I think is closest to how things should be which is evp_test. It uses the standard high level EVP API the format is consistent (if undocumented) and adding new tests can be done simply by editing a text file.<br />
<br />
It currently however only works for some algorithms and the text file format could be better. It currently doesn't handle public key algorithms or test variants of the same algorithm (e.g. AES-NI versus non AES-NI) either.<br />
<br />
=== Develop SSL/TLS Stack and Other Tools ===<br />
Steve Henson: The heartbeat bug is an example where you can perform some testing without a complete SSL/TLS stack. However looking through the code in heartbeat_test.c it uses a lot of functionality which would normally be strictly off-limits for an application.<br />
<br />
Some bugs are far more subtle and harder to test. For example some involve doing *almost* everything right and then slipping in some illegal parameter or badly formatted message. If you want to do that in a standalone bit of code you need a near complete SSL/TLS stack.<br />
<br />
I can think of a couple of ways to handle that. One is to have some kind of hooks in libssl so testing code can misbehave and send out illegal messages in controlled ways (I had a prototype "bad heartbeat" API which only added a couple of lines to libssl). An alternative would be to write some kind of tiny SSL/TLS code used only by the test programs and carefully tailored to permit such things.</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=OpenSSL_1.1.0_Changes&diff=2317OpenSSL 1.1.0 Changes2015-10-26T10:29:28Z<p>Aponomarenko: Added a link to the page describing a method to check binary compatibility of the release</p>
<hr />
<div>This is a parent page for discussion about API changes being done for OpenSSL version 1.1<br />
<br />
The overall goal of this project is to make most data structures opaque to applications. This provides us with a number of benefits:<br />
* We can add fields without breaking [[Binary_Compatibility|binary compatibility]]<br />
* Applications are more robust and can be more assured about correctness<br />
* It helps us determine which (new) accessors and settors, for example, are needed<br />
<br />
Please add sub-pages to discuss particular parts of the library as work progresses.<br />
<br />
== Major Changes so far ==<br />
<br />
* All structures in libssl public header files have been removed so that they are "opaque" to library users. You should use the provided accessor functions instead<br />
* The old DES API has been removed<br />
* bn, a sub library in libcrypto, has been made opaque<br />
* Access to deprecated functions/macros has been removed by default. To enable access you must do two things. 1) Build OpenSSL with deprecation support (pass "enable-deprecated" as an argument to config) 2) Applications must define "OPENSSL_USE_DEPRECATED" before including OpenSSL header files<br />
* HMAC_Init and HMAC_cleanup were previously stated in the docs and header files as being deprecated - but were not flagged in previous versions with OPENSSL_NO_DEPRECATED. This has been corrected in 1.1.0. Access to these functions/macros will be off by default in 1.1.0 as per the note above about deprecation.<br />
<br />
== Things that Broke in Qt ==<br />
<br />
Here's what's broken in the dev branch of Qt when building openssl master as of 6 Feb 2015.<br />
<br />
* DH - we were directly accessing p and q to set the DH params to primes embedded in Qt. We can probably replace this with SSL_CTX_set_dh_auto(ctx, 1). Another option suggested by Steve Henson is to save the DHparams we're using at the moment then use d2i_DHparams to load them in. This is compatible with openssl versions that don't have the dh_auto option.<br />
<br />
* ctx->cert_store - we were directly accessing the cert_store field of SSL_CTX. We can probably replace this with X509_STORE *SSL_CTX_get_cert_store(SSL_CTX *ctx) [Fixed in dev]<br />
<br />
* session->tlsext_tick_lifetime_hint - we were directly accessing the lifetime hint of the session. [A new API to access this field has been added]<br />
<br />
* cipher->valid - we were directly accessing the valid field of SSL_CIPHER. No replacement found. [This turned out not to be needed and so will be removed].<br />
<br />
== Things that Broke in Curl ==<br />
<br />
* SSL_SESSION->ssl_version. Replaced with SSL_version(SSL *)<br />
<br />
== Things that Broke in wget ==<br />
<br />
* SSL->state. Replaced with SSL_state(SSL *)<br />
<br />
== Things that Broke in Apache Traffic Manager ==<br />
<br />
* Setting SSL->rbio without setting SSL->wbio. New function introduction in 1.1.0 to handle this: SSL_set_rbio()<br />
<br />
== Things that Broke in OpenConnect ==<br />
<br />
In order to simulate "resume" of a DTLS session which never really existed but which was actually negotiated over the VPN control connection, [http://git.infradead.org/users/dwmw2/openconnect.git/blob/fa5cea08:/dtls.c#l147 this code] in the [http://www.infradead.org/openconnect/ OpenConnect VPN client] needs to set the following fields in a new <tt>SSL_SESSION</tt>:<br />
* <tt>->ssl_version</tt><br />
* <tt>->cipher{,_id}</tt><br />
* <tt>->master_key{,_length}</tt><br />
* <tt>->session_id{,_length}</tt><br />
<br />
This was fixed with [http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5abb133f this OpenConnect commit] which makes it create the ASN.1 representation of the session and import it with <tt>d2i_SSL_SESSION()</tt>. This is done conditionally in the above patch because it depends on the [http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=af674d4e20a82c2a98767b837072d7093c70b1cf fix in openssl HEAD] for <tt>d2i_SSL_SESSION()</tt> to make it cope with <tt>DTLS1_BAD_VER</tt> <i>([http://rt.openssl.org/Ticket/Display.html?id=3704 RT#3704])</i>.<br />
<br />
Other simpler things which broke:<br />
* <tt>SSL_CIPHER->id</tt>. Replaced with <tt>SSL_CIPHER_get_id()</tt><br />
* <tt>SSL_CTX->extra_certs</tt>. Replaced with <tt>SSL_CTX_get_extra_chain_certs_only()</tt><br />
<br />
== Things that Broke in TianoCore/EDKII ==<br />
<br />
EDKII is the reference implementation of UEFI firmware.<br />
<br />
* Various implicit inclusions of <tt>&lt;openssl/bn.h&gt;</tt> and <tt>&lt;openssl/rsa.h&gt;</tt> needed to be made explicit. ''[http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/8d7d32c1 (commit)]''<br />
* <tt>X509_NAME->bytes->{data,length}</tt>. Replaced with <tt>i2d_X509_NAME()</tt> ''[http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/e192c51b (commit)]''<br />
* <tt>X509_ATTRIBUTE->{object,value}</tt>. Replaced with <tt>X509_ATTRIBUTE_get0_object()</tt> and <tt>X509_ATTRIBUTE_get0_type()</tt> ''[http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/1bd8ee96 (commit)]''<br />
* <tt>ASN1_OBJECT->{length,data}</tt>. Replaced with <tt>OBJ_get0_data()</tt> and <tt>OBJ_length()</tt>. With backward-compatibility <tt>#define</tt> of same. ''[http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/6a7a36edc (commit)]''</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Contributions&diff=2316Contributions2015-10-26T10:24:27Z<p>Aponomarenko: /* Compatibility */ fixed typos and formatting</p>
<hr />
<div>There are a number of reasons why code or documentation contributions may not be adopted by the OpenSSL maintainers.<br />
See http://www.opensslfoundation.com/contributions.html for a personal perspective on OpenSSL contributions.<br />
<br />
=== Technical Concerns ===<br />
<br />
==== Compatibility ====<br />
[[Binary_Compatibility|Binary incompatible changes]] can only occur on major releases (the next is 1.1.0) and releases are often years apart. OpenSSL has a painful history of problems caused by references to OpenSSL internals, a history that has left the survivors very paranoid about referencing or changing APIs or structures (even those which seem to be clearly for internal use only).<br />
<br />
New features cannot be added to existing stable releases as this violates the [[versioning]] rule. So adding new functionality to OpenSSL 0.9.8, 1.0.0 or 1.0.1 just isn't going to happen ''unless'' that new functionality is needed to address a security hole or bug.<br />
<br />
==== Security Issues ====<br />
It is all too easy to inadvertently introduce security vulnerabilities that may not be<br />
immediately apparent even to experts. For instance, side channel attacks that exploit<br />
subtle timing differences between different code paths.<br />
<br />
==== Platform Portability ====<br />
OpenSSL runs on an enormous variety of platforms -- processor architectures, operating<br />
systems, compilers -- some of which have subtle and obscure quirks. Any changes to<br />
OpenSSL should at a minimum not break support for any existing platforms. The typical<br />
contributor will not be aware of all the potential platform portability pitfalls and<br />
so the code will require careful review by the OpenSSL team.<br />
<br />
==== Future Directions ====<br />
(TBD)<br />
<br />
==== Maintainability ====<br />
Incorporation of new code into OpenSSL means an implicit obligation to support it<br />
forever. There are many subtleties about OpenSSL which even surprise the experts at<br />
times: new code may have unfortunate consequences and open up security holes. OpenSSL<br />
is used on a very wide range of applications including a sizeable proportions of the<br />
world's web servers and as a result the developers have to be pretty darned sure new<br />
additions wont have unfortunate consequences. Comments and/or documentation can help<br />
a lot here especially for addition of new features to OpenSSL itself. <br />
<br />
=== Presentation ===<br />
(TBD)<br />
<br />
==== Patch Format ====<br />
Methods of creating patches in the recommended format are covered in the<br />
[[Use of Git#Making patches|documentation for accessing OpenSSL source code]].<br />
<br />
==== Coding Style ====<br />
Although there are some exceptions most of the OpenSSL code is indented in a rather<br />
quirky way. That style isn't documented but if you can't figure it out from looking<br />
at existing source you haven't spend nearly enough time with OpenSSL to think about<br />
changing it. If a reviewer has to reformat everything to fit with the current code<br />
style that counts against it. <br />
<br />
=== Documentation ===<br />
(TBD)<br />
<br />
==== Code Maturity ====<br />
With documentation there is another factor. People rely on documentation as showing the preferred way of using the software, and once documented an API it effectively "cast in stone" for future versions of OpenSSL. There is a reluctance to document features that may not yet be in a final form.<br />
<br />
==== Abstraction Level ====<br />
With OpenSSL there is usually a preferred general high-level API (EVP) and then<br />
many lower level function calls that can be used to achieve similar outcomes.<br />
The higher level abstractions are usually the best solution for all common application<br />
requirements. As a result there is a reluctance to adopt and publish documentation of<br />
low level APIs when the corresponding preferred high level approach is not yet<br />
adequately documented.<br />
<br />
=== Licensing and Copyright ===<br />
Is the code compatible with the [[License|OpenSSL license]]? New contributions will receive<br />
appropriate credit but they can't be expected to require every OpenSSL application to<br />
acknowledge the author in the documentation by adding additional attribution requirements.</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Contributions&diff=2315Contributions2015-10-26T10:22:17Z<p>Aponomarenko: /* Compatibility */ Added a link to the page with the description of how to check binary compatibility of new releases</p>
<hr />
<div>There are a number of reasons why code or documentation contributions may not be adopted by the OpenSSL maintainers.<br />
See http://www.opensslfoundation.com/contributions.html for a personal perspective on OpenSSL contributions.<br />
<br />
=== Technical Concerns ===<br />
<br />
==== Compatibility ====<br />
[[Binary_Compatibility|Binary incompatible changes]] can only occur on major releases (the next is 1.1.0) and releases<br />
are often years apart.<br />
OpenSSL has a painful history of problems caused by references to OpenSSL internals, a<br />
history that has left the survivors very paranoid about referencing or changing APIs or<br />
structures (even those which seem to be clearly for internal use only).<br />
<br />
New features cannot be added to existing stable releases as this violates the [[versioning]]<br />
rule So adding new functionality to OpenSSL 0.9.8, 1.0.0 or 1.0.1 just isn't going to<br />
happen ''unless'' that new functionality is needed to address a security hole or bug.<br />
<br />
==== Security Issues ====<br />
It is all too easy to inadvertently introduce security vulnerabilities that may not be<br />
immediately apparent even to experts. For instance, side channel attacks that exploit<br />
subtle timing differences between different code paths.<br />
<br />
==== Platform Portability ====<br />
OpenSSL runs on an enormous variety of platforms -- processor architectures, operating<br />
systems, compilers -- some of which have subtle and obscure quirks. Any changes to<br />
OpenSSL should at a minimum not break support for any existing platforms. The typical<br />
contributor will not be aware of all the potential platform portability pitfalls and<br />
so the code will require careful review by the OpenSSL team.<br />
<br />
==== Future Directions ====<br />
(TBD)<br />
<br />
==== Maintainability ====<br />
Incorporation of new code into OpenSSL means an implicit obligation to support it<br />
forever. There are many subtleties about OpenSSL which even surprise the experts at<br />
times: new code may have unfortunate consequences and open up security holes. OpenSSL<br />
is used on a very wide range of applications including a sizeable proportions of the<br />
world's web servers and as a result the developers have to be pretty darned sure new<br />
additions wont have unfortunate consequences. Comments and/or documentation can help<br />
a lot here especially for addition of new features to OpenSSL itself. <br />
<br />
=== Presentation ===<br />
(TBD)<br />
<br />
==== Patch Format ====<br />
Methods of creating patches in the recommended format are covered in the<br />
[[Use of Git#Making patches|documentation for accessing OpenSSL source code]].<br />
<br />
==== Coding Style ====<br />
Although there are some exceptions most of the OpenSSL code is indented in a rather<br />
quirky way. That style isn't documented but if you can't figure it out from looking<br />
at existing source you haven't spend nearly enough time with OpenSSL to think about<br />
changing it. If a reviewer has to reformat everything to fit with the current code<br />
style that counts against it. <br />
<br />
=== Documentation ===<br />
(TBD)<br />
<br />
==== Code Maturity ====<br />
With documentation there is another factor. People rely on documentation as showing the preferred way of using the software, and once documented an API it effectively "cast in stone" for future versions of OpenSSL. There is a reluctance to document features that may not yet be in a final form.<br />
<br />
==== Abstraction Level ====<br />
With OpenSSL there is usually a preferred general high-level API (EVP) and then<br />
many lower level function calls that can be used to achieve similar outcomes.<br />
The higher level abstractions are usually the best solution for all common application<br />
requirements. As a result there is a reluctance to adopt and publish documentation of<br />
low level APIs when the corresponding preferred high level approach is not yet<br />
adequately documented.<br />
<br />
=== Licensing and Copyright ===<br />
Is the code compatible with the [[License|OpenSSL license]]? New contributions will receive<br />
appropriate credit but they can't be expected to require every OpenSSL application to<br />
acknowledge the author in the documentation by adding additional attribution requirements.</div>Aponomarenkohttps://wiki.openssl.org/index.php?title=Binary_Compatibility&diff=2314Binary Compatibility2015-10-26T10:15:23Z<p>Aponomarenko: Page about a method to test binary compatibility</p>
<hr />
<div> <br />
This approach allows to manually detect most of the possible binary compatibility issues between any particular releases of the OpenSSL. Alternatively one can set up a local instance of the [[ABI tracker]] for OpenSSL to automate analysis for sequential releases of the library.<br />
<br />
== Build two versions of the library with debug info ==<br />
The library should be built with '''-g''' and '''-Og''' options of the GCC compiler and installed to a local directory (PREFIX=/home/USER):<br />
<br />
./config -d --prefix=$PREFIX/openssl-1.0.2d/ shared<br />
sed -i -e 's/ \-O0 / /' Makefile<br />
sed -i -e 's/ \-g / -g -Og /' Makefile<br />
make<br />
make install_sw<br />
<br />
== Make ABI dumps of the library versions ==<br />
Install [https://github.com/lvc/abi-dumper abi-dumper] tool (0.99.11 or newer) and run it on shared objects to create ABI dumps:<br />
<br />
abi-dumper -o libssl-1.0.2.d.abi -public-headers $PREFIX/openssl-1.0.2d/include/ -vnum 1.0.2d $PREFIX/openssl-1.0.2d/lib/libssl.so.1.0.0<br />
<br />
The -public-headers option is needed to filter out private part of the ABI.<br />
<br />
== Compare ABI dumps to produce report ==<br />
Install [https://github.com/lvc/abi-compliance-checker abi-compliance-checker] tool (1.99.13 or newer) and run it on two ABI dumps to create report:<br />
<br />
abi-compliance-checker -l libssl -bin -old libssl-1.0.2.c.abi -new libssl-1.0.2.d.abi -headers-list ./headers.list -report-path ./report.html</div>Aponomarenko