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@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 / grah...@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
