Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ryan Schmidt]

On Mar 2, 2021, at 15:10, Andrew Udvare wrote:

> 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.

Although it's not the primary purpose of MacPorts, it's within scope to expect 
MacPorts libs to be reusable in other projects. We already do a couple things 
to that end, such as setting MACOSX_DEPLOYMENT_TARGET to the build OS version 
and linking with -headerpad_max_install_names so that libraries can be 
relocated using install_name_tool or dylib_bundler. So if there are some easy 
changes we can make in MacPorts generally or in a small number of ports 
specifically to make them more useful for this purpose, that's reasonable to 
do. However if it requires us to disable source fortification we may not want 
to do that since I thought fortification was a good thing, designed to make 
programs safer.

But using Carthage or CocoaPods instead of MacPorts when your goal is to get 
libraries to redistribute with your project is also a reasonable approach.

Whichever approach you use, make sure the combination of licenses of the 
libraries and your program allow redistribution.

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ryan Schmidt]

On Mar 2, 2021, at 12:45, Adrian Georgescu wrote:

> After rebuilding a lot of port libs until I obtained the 
> LC_VERSION_MIN_MACOSX, I ran into this new Apple rejection reason:

Are you saying that *just* rebuilding from source on your computer was 
sufficient to get LC_VERSION_MIN_MACOSX to be used? If so, why did building 
from source on your computer work but building from source on our build 
machines did not work? Is this a feature introduced in Xcode after version 
12.2? I have not updated our Big Sur build machines past Xcode 12.2 yet.

Or did you have to modify the Portfiles in some way to get 
LC_VERSION_MIN_MACOSX to be used?


> 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?

You tell us; we've never heard of this before.

Re: 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  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  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).
>
>
>

Re: Migration after hardware failure

[Bill Cole]

On 2 Mar 2021, at 12:56, Craig Treleaven wrote:


Hi:

My old computer, which was running OS X 10.10, failed and I’ve 
replaced it with anew iMac running 10.15.  The drive in the old system 
was fine so I pulled it out and mounted it in an external enclosure so 
I could recover my file using Migration Assistant.


Looking at the Migration instructions [1], I don’t quite fit any of 
the mentioned scenarios.


Sure you do: it's a system upgrade.  It just has the added quirk of your 
MacPorts installation being under /Volumes//opt/local/ .


If you copy that entire directory to /opt/local on your new system, you 
can then proceed as described on the Migration page. So, make this Step 
0:


 cp -a /Volumes//opt/local /opt/



If I try to get a list of requested ports, it fails thusly:

$ port echo requested
Error: Current platform "darwin 19" does not match expected platform 
"darwin 14"
Error: If you upgraded your OS, please follow the migration 
instructions: https://trac.macports.org/wiki/Migration

OS platform mismatch
while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
mismatch



OK, so it looks like you already did that copy, since you have (a wrong 
version of) /opt/local/bin/port.



Do I just need to install the correct version of MacPorts for this OS


Yes. Step 2 on the Migration page.

The "port echo requested" command is Step 3(b) and you need to do all 
prior steps prior to this.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: 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 


Regards,
Adrian


> On 2 Mar 2021, at 07:14, Ryan Schmidt  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).

Migration after hardware failure

[Craig Treleaven]

Hi:

My old computer, which was running OS X 10.10, failed and I’ve replaced it with 
anew iMac running 10.15.  The drive in the old system was fine so I pulled it 
out and mounted it in an external enclosure so I could recover my file using 
Migration Assistant.

Looking at the Migration instructions [1], I don’t quite fit any of the 
mentioned scenarios.  If I try to get a list of requested ports, it fails 
thusly:

$ port echo requested
Error: Current platform "darwin 19" does not match expected platform "darwin 14"
Error: If you upgraded your OS, please follow the migration instructions: 
https://trac.macports.org/wiki/Migration
OS platform mismatch
while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch

Do I just need to install the correct version of MacPorts for this OS or is 
there something else I should be doing?

[1] https://trac.macports.org/wiki/Migration

Thanks,

Craig

Re: Build servers offline due to failed SSD

[Ryan Schmidt]

On Feb 21, 2021, at 10:08, Ryan Schmidt wrote:

> We got through the winter storms but now there's a new problem. The SSD that 
> the buildmaster VM is stored on and that boots up VMware ESXi is failing. I'm 
> currently setting up a new ESXi startup disk and trying to find a temporary 
> disk I can move that VM to to get us back up and running.

Builds are resuming though the buildmaster web interface is not yet available.

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Ryan Schmidt]

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).