Apple notarisation process - LC_VERSION_MIN_MACOSX

[Andrew Udvare]

This is not related to MacPorts really. I would strongly not suggest
attempting to pull in MacPorts-built libs into your app you plan to
distribute. MacPorts libs can really only be trusted to work with MacPorts
packages that use them.

You either have to build the libs yourself or use something like Carthage.

The reason you get this issue is because those dylibs from MacPorts contain
definitions of sprintf_chk which is a private symbol to Apple (already
defined in their own lib or possibly just because it starts with __).
Clang/GCC usually generates this code when you use sprintf as part of
source fortification (-D_FORTIFY_SOURCE). You have to build those libs
without such features. You can try -D_FORTIFY_SOURCE=0 and every library
you want to use must be built with this. Carthage packages probably have
this fixed.


On Tue, Mar 2, 2021, 13:46 Adrian Georgescu <ag at ag-projects.com> wrote:

> After rebuilding a lot of port libs until I obtained the
> LC_VERSION_MIN_MACOSX, I ran into this new Apple rejection reason:
>
> Guideline 2.5.1 - Performance
> Your app links against the following non-public framework(s):
>
> • Contents/Frameworks/libcrypto.1.1.dylib/___sprintf_chk
> • Contents/Frameworks/libp11-kit.0.dylib/___sprintf_chk
> • Contents/Frameworks/libmpfr.6.dylib/___sprintf_chk
> • Contents/Frameworks/libgnutls.30.dylib/___sprintf_chk
> • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strdup
> • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strlen
> • Contents/Frameworks/libidn2.0.dylib/_sprintf
> • Contents/Frameworks/libx264.157.dylib/___sprintf_chk
> • Contents/Frameworks/libssl.1.1.dylib/___sprintf_chk
> • Contents/Frameworks/libxml2.2.dylib/___sprintf_chk
>
> *Next Steps*
>
> The use of non-public APIs is not permitted on the App Store as it can
> lead to a poor user experience should these APIs change.
>
> Is it possible to rebuild those libs without those symbols?
>
> I found this link which may be relevant (I am not a C developer)
>
>
> https://stackoverflow.com/questions/12201625/disable-using-sprintf-chk#12203365
>
> Regards,
> Adrian
>
>
> On 2 Mar 2021, at 07:14, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Mar 1, 2021, at 17:16, Adrian Georgescu wrote:
>
> I am just a new user so bear with me.
>
> It seems that now Apple rejects any library part of a notarised
> application (and Mac App Store) if it does not comply with certain rules.
>
> One of this rules is that each binary or library must indicate the minimum
> OS version is suppose to run on.
>
> This can be checked with otool like in this example:
>
> otool -l libvpx.dylib |grep -A 2 -B 3 LC_VERSION_MIN_MACOSX
> cmdsize 24
>   uuid 1EDC0CF1-9D58-30B4-AF67-A0DEEAF3BAF4
> Load command 8
>     cmd LC_VERSION_MIN_MACOSX
> cmdsize 16
> version 10.11
>
> If your app depends on 3rd party libs you can install them using Mac
> Ports. But the default built binaries do not always work.
>
> The only way to obtain this flag set while using port is to install from
> source using -s parameter
>
> But for some libraries even this is not enough (libvpx and libsdl are some
> examples I ran into).
>
> The option for generating this flag is at linking stage and the option for
> creating this flag must be passed to the linker for this and this is not
> always possible by just using port install -s command.
>
> For example installing libvpx library (and many others) was not possible
> using -s because the library was not ready to use this flag.
>
> I have to edit the Makefiles and pass this flag to the linking stage:
>
> -mmacosx-version-min=10.11
>
> 10.11 or whatever minimum version the lib or app is suppose to run on.
>
> May I suggest that this must be documented somehow in the port recipes.
>
>
> I am not aware of Apple's increasingly inconvenient requirements in this
> regard.
>
> MacPorts adopted the strategy of setting the MACOSX_DEPLOYMENT_TARGET
> environment variable in all phases. It was our understanding that this was
> equivalent to setting -mmacosx-version-min, therefore we make no effort to
> set -mmacosx-version-min and have not had any qualms in removing
> conflicting -mmacosx-version-min directives when we encounter them.
>
> If this is not longer satisfactory to Apple, then we will need to change
> how MacPorts works and fix all ports (a huge undertaking, of course).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210302/7abe162a/attachment.htm>