Re: Apple ARM binary codesign issue
We're in luck. The latest Xcode 12.2 beta 2 seems to work with MacPorts without modification on either end. Whew! Now back to getting ports installed and fixed on ARM64! - MLD On Fri, Sep 25, 2020, at 9:05 PM, Ryan Schmidt wrote: > > > On Sep 25, 2020, at 10:31, Michael Dickens wrote: > > > Install scripts are calling ‘install -s’ which in turn calls ‘strip’. > > > > After fighting with my hacks for a while I do think the best option is the > > very-final-destroot as mentioned. > > > > I’d appreciate any advice on where and how to add this in MacPorts > > installed files ... I’m not an expert in macports-base. > > You would do it in proc portdestroot::destroot_finish in > src/port1.0/portdestroot.tcl. > > I am still hopeful that we will need to make no changes to MacPorts > base or ports for this, and that Apple will fix their tools to work > properly again. > > >
Re: Apple ARM binary codesign issue
On Sep 25, 2020, at 10:31, Michael Dickens wrote: > Install scripts are calling ‘install -s’ which in turn calls ‘strip’. > > After fighting with my hacks for a while I do think the best option is the > very-final-destroot as mentioned. > > I’d appreciate any advice on where and how to add this in MacPorts installed > files ... I’m not an expert in macports-base. You would do it in proc portdestroot::destroot_finish in src/port1.0/portdestroot.tcl. I am still hopeful that we will need to make no changes to MacPorts base or ports for this, and that Apple will fix their tools to work properly again.
Re: Apple ARM binary codesign issue
Install scripts are calling ‘install -s’ which in turn calls ‘strip’. After fighting with my hacks for a while I do think the best option is the very-final-destroot as mentioned. I’d appreciate any advice on where and how to add this in MacPorts installed files ... I’m not an expert in macports-base. Thx! - MLD On Fri, Sep 25, 2020, at 11:04 AM, Ken Cunningham wrote: > > > > On Sep 25, 2020, at 7:55 AM, Michael Dickens wrote: > > > > Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so > > that would bypass our MP efforts ... we'd have to patch up all of those > > ports to coerce them into running the MP strip ... that seems like a lot of > > work! Maybe there's a way around that? I'm not thinking of it off the top > > of my head. - MLD > > > > Yeah, build scripts should not be calling /usr/bin/strip directly, and > in the end, then will all eventually need fixing. I often have to fix > things like that to make builds use the newer cctools on older systems. > > I haven’t explored what "xcrun —find” does re: finding our cctools port > as yet... > > I actually thought Josh’s (or was it your) idea to run a codesign fixup > step in base after the build was done sounded like the best idea to me, > but there are probably ports that do something funky in “post-destroot” > or somewhere that would show up warts. > > Ken > >
Re: Apple ARM binary codesign issue
> On Sep 25, 2020, at 7:55 AM, Michael Dickens wrote: > > Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so > that would bypass our MP efforts ... we'd have to patch up all of those ports > to coerce them into running the MP strip ... that seems like a lot of work! > Maybe there's a way around that? I'm not thinking of it off the top of my > head. - MLD > Yeah, build scripts should not be calling /usr/bin/strip directly, and in the end, then will all eventually need fixing. I often have to fix things like that to make builds use the newer cctools on older systems. I haven’t explored what "xcrun —find” does re: finding our cctools port as yet... I actually thought Josh’s (or was it your) idea to run a codesign fixup step in base after the build was done sounded like the best idea to me, but there are probably ports that do something funky in “post-destroot” or somewhere that would show up warts. Ken
Re: Apple ARM binary codesign issue
Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so that would bypass our MP efforts ... we'd have to patch up all of those ports to coerce them into running the MP strip ... that seems like a lot of work! Maybe there's a way around that? I'm not thinking of it off the top of my head. - MLD On Fri, Sep 25, 2020, at 10:52 AM, Michael Dickens wrote: > Can't do both "exec" and then other stuff. If we remove the "exec" and > then add in the codesign ... maybe ... I'll test that once I get this > version working. > > Yes: We need to fix cctools to install "install_name_tool" ... not sure > why it's not there. > > On Fri, Sep 25, 2020, at 10:46 AM, Ken Cunningham wrote: > > Would it not be easier to add that codesign line in the existing script > > that the cctools port writes to wrap those tools for the +xcode variant > > of cctools, perhaps? > > > > (well, NB cctools is not presently wrapping install_name_tool for the > > +xcode variant, but that looks like an oversight trivially fixed). > > > > K
Re: Apple ARM binary codesign issue
Would it not be easier to add that codesign line in the existing script that the cctools port writes to wrap those tools for the +xcode variant of cctools, perhaps? (well, NB cctools is not presently wrapping install_name_tool for the +xcode variant, but that looks like an oversight trivially fixed). K
Re: Apple ARM binary codesign issue
Let's try this again from my MP email so that it gets to lists ... sorry for
duplicate emails!
I've finally gotten to the point of working out a hack solution.
One can -not- modify '/usr/bin' without a lot of effort. But, one can modify
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
... and yes I know this is outside the scope of what MP does or is (likely)
willing to do. As noted: This is a hack to prove that it works.
In
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
I move the target executables from 'foo' to 'foo_orig', then create a script
'foo' that first calls 'foo_orig ${@}' then 'codesign' to update the signature
on the binary. The executables in '/usr/bin' just call those in
'/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin',
so my script is treated as a system provided executable for 'foo'. Initial
testing looks positive, regardless of how hacky this is.
Question: which executables am I targeting here? I think 'strip', 'lipo', and
'install_name_tool' are the obvious ones. is that all? Any others that need
this wrapping? - MLD
Re: Apple ARM binary codesign issue
On Sep 24, 2020, at 08:51, Ruben Di Battista wrote: > Ok, that's what I didn't know. I thought It was mandatory for Apple Store > software and not everything... Yup. As of macOS Big Sur 11 beta 6, released September 3, 2020, codesigning is mandatory for everything on ARM Macs. How to deal with that in MacPorts is what this thread is about. See https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes: > New in macOS 11 on Apple silicon Mac computers, and starting in macOS Big Sur > 11 beta 6, the operating system enforces that any executable must be signed > before it’s allowed to run. There isn’t a specific identity requirement for > this signature: a simple ad-hoc signature is sufficient. This new behavior > doesn’t change the long-established policy that our users and developers can > run arbitrary code on their Macs, and is designed to simplify the execution > policies on Apple silicon Mac computers and enable the system to better > detect code modifications. This new policy doesn’t apply to translated x86 > binaries running under Rosetta 2, nor does it apply to macOS 11 running on > Intel-based platforms.
Re: Apple ARM binary codesign issue
Ok, that's what I didn't know. I thought It was mandatory for Apple Store software and not everything... On Thu, 24 Sep 2020, 13:35 Ryan Schmidt, wrote: > On Sep 23, 2020, at 03:37, Ruben Di Battista wrote: > > > Can't be an easier choice to push globally a linker switch, if it > exists, to disable codesigning altogether for MP software? > > macOS 11 on ARM now require codesigning. Binaries that are not codesigned > cannot be used at all. > >
Re: Apple ARM binary codesign issue
On Sep 22, 2020, at 17:24, Ken Cunningham wrote: > On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: >> >> To me it seems unrealistic for Apple to suggest that an infinite number of >> open source projects, many of whose developers have never seen a Mac, should >> now add code to their build systems to codesign things on macOS. Apple made >> a point of stating during WWDC that they love open source software; imposing >> busy work on the open source community is not a good way to show that love. > > As I read it, the linker automatically codesigns the binary when you link, > which is usually the final step in the process. So nobody has to change > anything there. > > But if you later modify that final linked binary by stripping it (I guess ) > or changing the libraries around with install_name_tool (which I believe > MESON does to every single install :>) then you invalidate the signature, as > you should IMHO. The operative word is "you". In this case, "you" could be the project's build system, or it could be the portfile fixing things up after the build system got something wrong. My paragraph refers to the former: to projects that invoke install_name_tool or strip as part of their build process, and my contention that asking those projects to add codesigning steps to those is unreasonable. As for the latter, I don't recall any ports calling strip manually, but there are many that use install_name_tool; ideally, those should be fixed so that they don't need to do that (i.e. by fixing the build system to use the -install_name flag correctly when linking). Apple only just introduced the requirement that everything be codesigned in a very recent macOS 11 beta, and only just introduced the change into a recent Xcode 12 beta that causes the linker to automatically sign things. It would not surprise me if Apple introduces further changes in later betas that automatically re-sign things when using install_name_tool or strip.
Re: Apple ARM binary codesign issue
On Sep 22, 2020, at 18:05, Richard L. Hamilton wrote: > How will additional signing requirements impact MacPorts binary distribution > (which is a huge timesaver for installs and updates, if one doesn't have to > build most packages oneself)? As I understand it, it should not affect that at all. Apple documentation says that the automatic ad-hoc codesigning that the linker now does is not specific to the machine that did the linking, so we should be able to distribute ad-hoc codesigned files normally and it should work on user systems.
Re: Apple ARM binary codesign issue
On Sep 23, 2020, at 03:37, Ruben Di Battista wrote: > Can't be an easier choice to push globally a linker switch, if it exists, to > disable codesigning altogether for MP software? macOS 11 on ARM now require codesigning. Binaries that are not codesigned cannot be used at all.
Re: Apple ARM binary codesign issue
Leandro, feel free to make meaningful contributions to our conversations but please stop spamming the list with links to your "apple sucks" photo gallery or I will ban you. On Sep 23, 2020, at 13:07, Leandro neto wrote: > look please!!
RE: Apple ARM binary codesign issue
look please!! leandro leme neto phone +552122366155 +552121796156 https://photos.app.goo.gl/eZ1qaq6xiciZLdDq9 https://photos.app.goo.gl/vMh9wRVp9yYV2TJ47 https://photos.app.goo.gl/eq6Jp4E7BBPhtYWw6 https://photos.app.goo.gl/wHHNkfgEqz4H7kE36 https://photos.app.goo.gl/43BGYWcySozdvmJW9 https://photos.app.goo.gl/yGGMWiuMrqLmTZ1J6 https://photos.app.goo.gl/fovKnEnNXTkqAFkd7 De: "Leandro neto" Enviada: 2020/09/23 15:07:40 Para: rubendibatti...@gmail.com, saa...@saagarjha.com Cc: ryandes...@macports.org, macports-dev@lists.macports.org, ken.cunningham.web...@gmail.com, macports-us...@lists.macports.org Assunto: RE: Apple ARM binary codesign issue look please!! phone +552122366155 +552121796156 https://photos.app.goo.gl/eZ1qaq6xiciZLdDq9 https://photos.app.goo.gl/vMh9wRVp9yYV2TJ47 https://photos.app.goo.gl/eq6Jp4E7BBPhtYWw6 https://photos.app.goo.gl/wHHNkfgEqz4H7kE36 https://photos.app.goo.gl/43BGYWcySozdvmJW9 https://photos.app.goo.gl/yGGMWiuMrqLmTZ1J6 https://photos.app.goo.gl/fovKnEnNXTkqAFkd7 De: "Ruben Di Battista" Enviada: 2020/09/23 05:38:20 Para: saa...@saagarjha.com Cc: ryandes...@macports.org, macports-dev@lists.macports.org, macports-us...@lists.macports.org, ken.cunningham.web...@gmail.com Assunto: Re: Apple ARM binary codesign issue Can't be an easier choice to push globally a linker switch, if it exists, to disable codesigning altogether for MP software? On Wed, 23 Sep 2020, 03:09 Saagar Jha, <saa...@saagarjha.com> wrote: As far as I understand, ad-hoc codesigning is not actually really meant to protect a file on disk because you can just ad-hoc sign again when you modify the file; instead it simplifies some of Apple’s own code because it removes the special case of a binary that doesn’t have a signature (which until now has had a number of quirks and extra checks throughout the operating system). A more cynical interpretation would be that Apple would like to flip the switch to “paid developer account-signed software only” at some point in the future, but every engineer has denied that this is the goal when asked so I guess that if this will happen it hopefully won’t be anytime soon. I am still unsure why ld adds a signature but strip and install_name_tool don’t reapply an ad-hoc signature to a signed binary that they modify. This might be worth filing a feedback for. > On Sep 22, 2020, at 15:24, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > > > On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: >> >> To me it seems unrealistic for Apple to suggest that an infinite number of open source projects, many of whose developers have never seen a Mac, should now add code to their build systems to codesign things on macOS. Apple made a point of stating during WWDC that they love open source software; imposing busy work on the open source community is not a good way to show that love. > > As I read it, the linker automatically codesigns the binary when you link, which is usually the final step in the process. So nobody has to change anything there. > > But if you later modify that final linked binary by stripping it (I guess ) or changing the libraries around with install_name_tool (which I believe MESON does to every single install :>) then you invalidate the signature, as you should IMHO. > > I'm trying to imagine how Jeremy might prevent hackers from surreptitiously modifying signed binaries with strip or install_name_tool (which is good) while letting people modify signed binaries with strip or install_name_tool without invalidating the signature -- I don't immediately see how you can have it both ways. But maybe Jeremy has some trick that works for this I can't think of. > > I won't be surprised if the solution is that you have to resign them after doing that, though. > > Ken >
Re: Apple ARM binary codesign issue
Can't be an easier choice to push globally a linker switch, if it exists, to disable codesigning altogether for MP software? On Wed, 23 Sep 2020, 03:09 Saagar Jha, wrote: > As far as I understand, ad-hoc codesigning is not actually really meant to > protect a file on disk because you can just ad-hoc sign again when you > modify the file; instead it simplifies some of Apple’s own code because it > removes the special case of a binary that doesn’t have a signature (which > until now has had a number of quirks and extra checks throughout the > operating system). A more cynical interpretation would be that Apple would > like to flip the switch to “paid developer account-signed software only” at > some point in the future, but every engineer has denied that this is the > goal when asked so I guess that if this will happen it hopefully won’t be > anytime soon. > > I am still unsure why ld adds a signature but strip and install_name_tool > don’t reapply an ad-hoc signature to a signed binary that they modify. This > might be worth filing a feedback for. > > > On Sep 22, 2020, at 15:24, Ken Cunningham < > ken.cunningham.web...@gmail.com> wrote: > > > > > > On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: > >> > >> To me it seems unrealistic for Apple to suggest that an infinite number > of open source projects, many of whose developers have never seen a Mac, > should now add code to their build systems to codesign things on macOS. > Apple made a point of stating during WWDC that they love open source > software; imposing busy work on the open source community is not a good way > to show that love. > > > > As I read it, the linker automatically codesigns the binary when you > link, which is usually the final step in the process. So nobody has to > change anything there. > > > > But if you later modify that final linked binary by stripping it (I > guess ) or changing the libraries around with install_name_tool (which I > believe MESON does to every single install :>) then you invalidate the > signature, as you should IMHO. > > > > I'm trying to imagine how Jeremy might prevent hackers from > surreptitiously modifying signed binaries with strip or install_name_tool > (which is good) while letting people modify signed binaries with strip or > install_name_tool without invalidating the signature -- I don't > immediately see how you can have it both ways. But maybe Jeremy has some > trick that works for this I can't think of. > > > > I won't be surprised if the solution is that you have to resign them > after doing that, though. > > > > Ken > > > >
Re: Apple ARM binary codesign issue
As far as I understand, ad-hoc codesigning is not actually really meant to protect a file on disk because you can just ad-hoc sign again when you modify the file; instead it simplifies some of Apple’s own code because it removes the special case of a binary that doesn’t have a signature (which until now has had a number of quirks and extra checks throughout the operating system). A more cynical interpretation would be that Apple would like to flip the switch to “paid developer account-signed software only” at some point in the future, but every engineer has denied that this is the goal when asked so I guess that if this will happen it hopefully won’t be anytime soon. I am still unsure why ld adds a signature but strip and install_name_tool don’t reapply an ad-hoc signature to a signed binary that they modify. This might be worth filing a feedback for. > On Sep 22, 2020, at 15:24, Ken Cunningham > wrote: > > > On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: >> >> To me it seems unrealistic for Apple to suggest that an infinite number of >> open source projects, many of whose developers have never seen a Mac, should >> now add code to their build systems to codesign things on macOS. Apple made >> a point of stating during WWDC that they love open source software; imposing >> busy work on the open source community is not a good way to show that love. > > As I read it, the linker automatically codesigns the binary when you link, > which is usually the final step in the process. So nobody has to change > anything there. > > But if you later modify that final linked binary by stripping it (I guess ) > or changing the libraries around with install_name_tool (which I believe > MESON does to every single install :>) then you invalidate the signature, as > you should IMHO. > > I'm trying to imagine how Jeremy might prevent hackers from surreptitiously > modifying signed binaries with strip or install_name_tool (which is good) > while letting people modify signed binaries with strip or install_name_tool > without invalidating the signature -- I don't immediately see how you can > have it both ways. But maybe Jeremy has some trick that works for this I > can't think of. > > I won't be surprised if the solution is that you have to resign them after > doing that, though. > > Ken >
Re: Apple ARM binary codesign issue
On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: > > To me it seems unrealistic for Apple to suggest that an infinite number of > open source projects, many of whose developers have never seen a Mac, should > now add code to their build systems to codesign things on macOS. Apple made a > point of stating during WWDC that they love open source software; imposing > busy work on the open source community is not a good way to show that love. As I read it, the linker automatically codesigns the binary when you link, which is usually the final step in the process. So nobody has to change anything there. But if you later modify that final linked binary by stripping it (I guess ) or changing the libraries around with install_name_tool (which I believe MESON does to every single install :>) then you invalidate the signature, as you should IMHO. I'm trying to imagine how Jeremy might prevent hackers from surreptitiously modifying signed binaries with strip or install_name_tool (which is good) while letting people modify signed binaries with strip or install_name_tool without invalidating the signature -- I don't immediately see how you can have it both ways. But maybe Jeremy has some trick that works for this I can't think of. I won't be surprised if the solution is that you have to resign them after doing that, though. Ken
Re: Apple ARM binary codesign issue
> > I've read that number of duplicates is one of the ways they determine > issue priority internally. > I can confirm that this is indeed supposed to be the case. Our Apple engineering liaison at the university where I used to work as a sysadmin frequently repeated this during our Apple developer meetings. These Apple developer meetings were where the IT staff from various departments around campus gathered once a month to discuss issues with the latest betas and issues with software apps being used by faculty, staff, and students. One of the main purposes of these meetings were to bring up potential bugs in the betas, and to have as many of the meeting attendees go back and try to duplicate the bug, and then report it. In fact, we even passed around the titles of the bug reports to the mailing list, so that it could get recorded as a duplicate of the same issue. Even better, if the original person's bug report was lucky enough to get a bug report number in Apple's Radar bug tracker, the Apple liaison would look it up and pass it along to everyone at the meeting, so that we could reference the original bug report (again, to increase the duplicate count). -- Jason Liu On Tue, Sep 22, 2020 at 4:17 PM Joshua Root wrote: > On 2020-9-23 05:33 , Ryan Schmidt wrote: > > > > Send feedback through the Feedback Assistant app. > > Yes, everyone with any issues with Apple preview software should do this > early and often. I've read that number of duplicates is one of the ways > they determine issue priority internally. > > - Josh >
Re: Apple ARM binary codesign issue
On 2020-9-23 05:33 , Ryan Schmidt wrote: > > Send feedback through the Feedback Assistant app. Yes, everyone with any issues with Apple preview software should do this early and often. I've read that number of duplicates is one of the ways they determine issue priority internally. - Josh
Re: Apple ARM binary codesign issue
On Sep 22, 2020, at 14:52, Ken Cunningham wrote: > On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote: >> >> I hope that Apple fixes their toolchain to work without such intervention. > > I believe this may ultimately come under the category of "intended > behaviour". To me it seems unrealistic for Apple to suggest that an infinite number of open source projects, many of whose developers have never seen a Mac, should now add code to their build systems to codesign things on macOS. Apple made a point of stating during WWDC that they love open source software; imposing busy work on the open source community is not a good way to show that love. Part of the problem is that I don't understand what codesigning is for. I understand that for distribution in the app store I would codesign an app with my identity. Apple can then revoke apps I've signed if it turns out I've released malicious software. Great, but here we're not talking about signing with an identity, we're talking about ad-hoc signing. All that proves is that the binary hasn't been modified. That's good; it'll protect against corrupted files getting used. But how would it stop malicious code? Couldn't the malicious party just codesign it again after changing it?
Re: Apple ARM binary codesign issue
On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote: > > I hope that Apple fixes their toolchain to work without such intervention. > I believe this may ultimately come under the category of "intended behaviour". I can understand why they would want these changes to invalidate the signature. I suspect we'll have to find a way to re-sign them after making such changes. In addition, we may not find that automatically doing it by wrapping our strip or install_name_tool with codesigners is suitably secure. Ken
Re: Apple ARM binary codesign issue
On Sep 22, 2020, at 14:19, Michael Dickens wrote: > I have macOS 11.0beta7 installed : check! > > Compare / contrast ARM Mac versus MacBook Pro 16 : check! > > I have Xcode 12.2 beta installed : check! > > I've removed "/Library/Developer/CommandLineTools" : check! > > I hope that Apple fixes their toolchain to work without such intervention : > check! > > Do you know that best way we can complain to Apple to fix the toolchain? > > Still doesn't work for me ... those specific files are almost the only ones > that just don't respond to codesign. I'll try reinstalling from scratch ... > maybe ports built with Xcode 12.0 don't entirely work with those built using > 12.2beta? H I was getting the "codesign_allocate helper tool cannot be found or used" error earlier too; the only thing I think I changed since then is getting rid of the Xcode 12.0 beta CLT. Though I do have a couple different MacPorts installs and I was working on the other one before. Send feedback through the Feedback Assistant app. They have responded to one of mine recently.
Re: Apple ARM binary codesign issue
I have macOS 11.0beta7 installed : check! Compare / contrast ARM Mac versus MacBook Pro 16 : check! I have Xcode 12.2 beta installed : check! I've removed "/Library/Developer/CommandLineTools" : check! I hope that Apple fixes their toolchain to work without such intervention : check! Do you know that best way we can complain to Apple to fix the toolchain? Still doesn't work for me ... those specific files are almost the only ones that just don't respond to codesign. I'll try reinstalling from scratch ... maybe ports built with Xcode 12.0 don't entirely work with those built using 12.2beta? H Thx! - MLD On Tue, Sep 22, 2020, at 2:58 PM, Ryan Schmidt wrote: > > > On Sep 22, 2020, at 13:29, Michael Dickens wrote: > > > % codesign -v - --ignore-resources > > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > > invalid signature (code or signature have been modified) > > % sudo codesign -s - > > --preserve-metadata=identifier,entitlements,flags,runtime -f > > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > > replacing existing signature > > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > > the codesign_allocate helper tool cannot be found or used > > % which codesign > > /usr/bin/codesign > > % which codesign_allocate > > /usr/bin/codesign_allocate > > > > You need Xcode 12.2 beta, which you probably have, but also make sure > that you don't have old command line tools installed. I don't think the > Xcode 12.0 beta command line tools are compatible, and there isn't an > Xcode 12.2 beta command line tools yet. Delete > /Library/Developer/CommandLineTools. > > > % codesign -v - > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > invalid signature (code or signature have been modified) > In architecture: arm64 > % codesign -s - > --preserve-metadata=identifier,entitlements,flags,runtime -f > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > replacing existing signature > ... > % codesign -v - > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > valid on disk > mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > satisfies its Designated Requirement > % > > > > Mentioned as possible fixes were: (1) inserting MP strip and > > install_name_tool wrappers that sign the binary if the signature is broken; > > or (2) a new step in destroot_finish . > > I hope that Apple fixes their toolchain to work without such intervention. > >
Re: Apple ARM binary codesign issue
On Sep 22, 2020, at 13:29, Michael Dickens wrote: > % codesign -v - --ignore-resources > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > invalid signature (code or signature have been modified) > % sudo codesign -s - > --preserve-metadata=identifier,entitlements,flags,runtime -f > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > replacing existing signature > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: > the codesign_allocate helper tool cannot be found or used > % which codesign > /usr/bin/codesign > % which codesign_allocate > /usr/bin/codesign_allocate > You need Xcode 12.2 beta, which you probably have, but also make sure that you don't have old command line tools installed. I don't think the Xcode 12.0 beta command line tools are compatible, and there isn't an Xcode 12.2 beta command line tools yet. Delete /Library/Developer/CommandLineTools. % codesign -v - mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: invalid signature (code or signature have been modified) In architecture: arm64 % codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime -f mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: replacing existing signature ... % codesign -v - mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: valid on disk mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: satisfies its Designated Requirement % > Mentioned as possible fixes were: (1) inserting MP strip and > install_name_tool wrappers that sign the binary if the signature is broken; > or (2) a new step in destroot_finish . I hope that Apple fixes their toolchain to work without such intervention.
Apple ARM binary codesign issue
There has been some discussion about the recent change Apple made for macOS
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As
pointed out, a better venue for discussion would be these lists.
The brief summary is that Apple is instituting code signing for all binaries
during linking as noted here <
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Updates-in-macOS-Big-Sur-11-Universal-Apps-Beta-7
>. The signing is as-hoc and done automatically; it is invalidated if one
modifies the binary in any way ... for example using "strip", or
"install_name_tool" to change the name of a required library, or even the
self-ID name.
Many MacPorts installs use various post-linking means to tweak the resulting
binary, and hence these are not currently usable under macOS 11.0beta7 or more
recent on ARM Mac only; again: this change is NOT for Intel Mac -- at least not
at this time.
One can test whether the signing is valid via the command: "codesign -v FILE" ;
according to Apple one should use "codesign -v - --ignore-resources FILE"
to be more verbose as well as look at just the non-resource binary. Both work
in my testing.
In my initial testing, some of the binaries can be made to work via the command
"[sudo] codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime
-f FILE" ... but, not all! For example:
{{{
% codesign -v - --ignore-resources
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8:
invalid signature (code or signature have been modified)
% sudo codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime
-f /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8:
replacing existing signature
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: the
codesign_allocate helper tool cannot be found or used
% which codesign
/usr/bin/codesign
% which codesign_allocate
/usr/bin/codesign_allocate
}}}
So in this case, "codesign_allocate" cannot be used for some non-obvious reason
(as it clearly is in the PATH and works for some other codesign efforts). The
same holds true for some of the Python libraries and some of the primary
executables -- but, not all!
Mentioned as possible fixes were: (1) inserting MP strip and install_name_tool
wrappers that sign the binary if the signature is broken; or (2) a new step in
destroot_finish .
Let's pick up the discussion here, and try to work out a fix in short order.
For those of us trying to do anything within MacPorts using ARM Mac, this new
feature is causing significant issues & needs to be dealt with so that we can
get back to real work instead of fighting macOS::codesign .
Cheers! - MLD
