Apple ARM binary codesign issue
Ruben Di Battista
rubendibattista at gmail.com
Wed Sep 23 08:37:46 UTC 2020
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, <saagar at 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.webuse at 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200923/3e5a9364/attachment.htm>
More information about the macports-dev
mailing list