Re: Apple ARM binary codesign issue
On 12.01.2021 at 02:37 Ryan Schmidt wrote: > The automatic codesigning that the compiler/linker does must be > sufficient, because we're not doing anything beyond that with the > binary packages that MacPorts downloads when you install a port. Ok, that's good to hear. So the only benefit of codesigning seems to be to guarantee that binaries aren't modified. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Apple ARM binary codesign issue
On Jan 11, 2021, at 07:27, Andreas Falkenhahn wrote: > Slightly off-topic, but maybe someone here knows something about this: When > distributing Apple ARM apps outside the App Store, is it sufficient to sign > them using ad-hoc or self-signed certificates or is it mandatory now to pay > the $99 per year even if the app is going to be distributed outside the App > Store? The automatic codesigning that the compiler/linker does must be sufficient, because we're not doing anything beyond that with the binary packages that MacPorts downloads when you install a port.
Re: Apple ARM binary codesign issue
Slightly off-topic, but maybe someone here knows something about this: When distributing Apple ARM apps outside the App Store, is it sufficient to sign them using ad-hoc or self-signed certificates or is it mandatory now to pay the $99 per year even if the app is going to be distributed outside the App Store? On 30.09.2020 at 06:48 Andrew Udvare wrote: >> On 2020-09-29, at 15:02, Michael Dickens wrote: >> Excellent! Thanks for the heads-up. I've downloaded this file and will get >> it installed and start testing later today. - MLD >> On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote: >>> Apple today released Xcode 12.2 beta 2 and the Release Notes state Apple Clang Compiler Resolved Issues • Fixed an issue that caused strip, install_name_tool and vtool to corrupt the ad-hoc code signatures generated by the linker for arm64 Mach-O files. (51911417) >>> - Gary Palter >>> Principal Software Engineer >>> Clozure Associates >>> Cell: 617-947-0536 > Hi, > If you get a chance, could you try compiling this on your Apple Silicon > device? > https://github.com/Tatsh/re3/tree/macos (part of this PR > https://github.com/GTAmodding/re3/pull/734) > Once you clone it (with git clone --recurse-submodules --branch=macos): > cd re3 > port install --unrequested premake5 openal-soft glew glfw mpg123 > libsndfile (if this step fails, stop here and let me know) > premake5 --with-librw gmake2 > cd build > make config=release_macosx-amd64-librw_gl3_glfw-oal -j5 > Just want to see the output and find out if it can build > successfully. Does not need the GTAIII game anywhere to build. > Thanks -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Apple ARM binary codesign issue
> On 2020-09-29, at 15:02, Michael Dickens wrote: > > Excellent! Thanks for the heads-up. I've downloaded this file and will get it > installed and start testing later today. - MLD > > On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote: >> Apple today released Xcode 12.2 beta 2 and the Release Notes state >>> Apple Clang Compiler >>> Resolved Issues >>> • Fixed an issue that caused strip, install_name_tool and vtool to >>> corrupt the ad-hoc code signatures generated by the linker for arm64 Mach-O >>> files. (51911417) >> >> - Gary Palter >> Principal Software Engineer >> Clozure Associates >> Cell: 617-947-0536 Hi, If you get a chance, could you try compiling this on your Apple Silicon device? https://github.com/Tatsh/re3/tree/macos (part of this PR https://github.com/GTAmodding/re3/pull/734) Once you clone it (with git clone --recurse-submodules --branch=macos): cd re3 port install --unrequested premake5 openal-soft glew glfw mpg123 libsndfile (if this step fails, stop here and let me know) premake5 --with-librw gmake2 cd build make config=release_macosx-amd64-librw_gl3_glfw-oal -j5 Just want to see the output and find out if it can build successfully. Does not need the GTAIII game anywhere to build. Thanks
Re: Apple ARM binary codesign issue
Excellent! Thanks for the heads-up. I've downloaded this file and will get it installed and start testing later today. - MLD On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote: > Apple today released Xcode 12.2 beta 2 and the Release Notes state >> Apple Clang Compiler >> Resolved Issues >> * Fixed an issue that caused `strip`, `install_name_tool` and `vtool` to >> corrupt the ad-hoc code signatures generated by the linker for arm64 Mach-O >> files. (51911417) > > - Gary Palter > Principal Software Engineer > Clozure Associates > Cell: 617-947-0536
Apple ARM binary codesign issue
Apple today released Xcode 12.2 beta 2 and the Release Notes state > Apple Clang Compiler > Resolved Issues > Fixed an issue that caused strip, install_name_tool and vtool to corrupt the > ad-hoc code signatures generated by the linker for arm64 Mach-O files. > (51911417) - Gary Palter Principal Software Engineer Clozure Associates Cell: 617-947-0536
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 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 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 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
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-...@lists.macports.org, ken.cunningham.web...@gmail.com, macports-users@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-...@lists.macports.org, macports-users@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 SEVERE SUCURITY VUNERABILITY
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-...@lists.macports.org, ken.cunningham.web...@gmail.com, macports-users@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-...@lists.macports.org, macports-users@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
Please look +552122366155 +552121796156 Leandro 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/f8yijZjBd88BSGqy8 De: "Ruben Di Battista" Enviada: 2020/09/23 05:38:20 Para: saa...@saagarjha.com Cc: ryandes...@macports.org, macports-...@lists.macports.org, macports-users@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
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-...@lists.macports.org, macports-users@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
On Tue, Sep 22, 2020 at 6:24 PM Ken Cunningham wrote: > ... > 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 have not looked at Apple signing in a while, so take this with a grain of salt... Apple should be signing assets and resources in the bundle, and not just the binary. That's called "semantic authentication". See David Wagner and Bruce Schneier's "Analysis of the SSL 3.0 Protocol" (c. 1996). Lack of semantic authentication is what Android bug 8219321 was all about, a.k.a Bluebox's "master key" bug or the "one key to rule them all." Android patched the 8219321 bug in 2013. If you modify the binary or assets in the bundle, you should have to resign the bundle. I don't think there's anything inherently insecure about (re)signing a bundle after modification. Or nothing comes to mind (for me). The standard caveats apply, like the codesign tool should make an insignificant modification before signing, like adding a whitespace to an XML file or text file. And codesign tool should calculate the digest itself, and not sign a precomputed digest. Never trust someone else's hash. Calculate the hash yourself. Jeff
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
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
On 22/09/2020 15: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? Report here bugreport.apple.com Then report the same report here: https://openradar.appspot.com/page/1 (without violating your Apple developer ToS). Andrew signature.asc Description: OpenPGP digital signature
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
