Apple notarisation process - LC_VERSION_MIN_MACOSX

[Adrian Georgescu]

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 <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/ccce568c/attachment.htm>