OpenSSL 1.1 on OSX

[Grahame Grieve]

So I did end up statically binding openSSL into my application - thanks for
the suggestion.

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.

Grahame


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...
> >>
> >
> Enjoy
>
> Jakob
> --
> 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 -
http://www.springer.com/978-3-030-56882-5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211207/18d7183a/attachment.htm>