OpenSSL 1.1 on OSX
grahame at healthintersections.com.au
Tue Dec 7 12:20:59 UTC 2021
So I did end up statically binding openSSL into my application - thanks for
Still, it seems to me that a note in the install/build instructions under
macos saying that the default dylibs are not compatible with the rules for
hardened applications would be a nice thing for developers like me, who
have no idea about all this stuff.
On Sat, Dec 4, 2021 at 12:02 AM Jakob Bohm via openssl-users <
openssl-users at openssl.org> wrote:
> Which is indeed what I do in our notarized MacOsX and iOS applications.
> However to do so, I have historically needed to clean up OpenSSL source
> code to actually behave as a proper static library where only used
> functions are linked in. Most notably, the source files named xxx_lib.c
> tend to cause the opposite behavior by bundling used and unused code
> into a single .o file, so I had to do thematic splitting of those source
> files, to not only avoid the unused functions getting linked in, but
> also the unused .o files referenced by those unused functions. This
> problem is fully cross platform, although some more detail work had to
> be done to ensure compatibility of certain source files with XCode
> bundled tool chains (In particular the optimized assembler files).
> On 2021-11-20 07:47, Dr Paul Dale wrote:
> > An alternative would be to statically link libssl and libcrypto. No
> > more dependencies.
> > Pauli
> > On 20/11/21 3:48 pm, Viktor Dukhovni wrote:
> >> On Sat, Nov 20, 2021 at 01:38:39PM +1100, Grahame Grieve wrote:
> >>> I agree it's sure not a core openSSL issue. But surely lots of people
> >>> want to use openSSL in cross platform apps and openSSL is interested
> >>> in adoption issues?
> >> Most of the users here are building applications that are not notarised,
> >> and so work with the upstream builds.
> >>> Anyway, it looks like I now have to figure out how to maintain a
> >>> custom build of openSSL :-(
> >> It shouldn't be too difficult to execute the build, once you've figured
> >> out the actual requirements. Apparently you need to make sure that
> >> signed code has very explicit dependencies, which makes some sense, so
> >> the libraries bundled with the application need to be built in a way
> >> that can be verified along with the application.
> >> My best guess is that Apple are not specifically picking on OpenSSL
> >> here, and similar issues would arise with any other libraries you'd
> >> want to package with your application. Good luck.
> >> Feel free to share your findings. Perhaps someone will then help
> >> you find a way to improve on them, or to add a template to the
> >> build to support this going forward...
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://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
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
Benson & Grieve: Principles of Health Interoperability (Health
Information Technology Standards), 4th ed -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users