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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx / +61 411 867 065
http://www.healthintersections.com.au / grahame@xxxxxxxxxxxxxxxxxxxxxxxxxx / +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
