bug#66245: [PATCH] ; Silence macOS 14 warning

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Stefan Kangas <stefankangas@gmail.com> writes:

> Alan Third <alan@idiocy.org> writes:
>
>> Eli, Stefan, any thoughts? Does this look bad enough to force a new
>> Emacs 29 release?
>>
>> The link with the in-depth explanation again:
>>
>>     https://sector7.computest.nl/post/2022-08-process-injection-breaking-all-macos-security-layers-with-a-single-vulnerability/
>
> Let's see if I understand this right.
>
> Without this code, are we enabling malicious processes to escape the
> macOS sandbox, and gain the same privileges as the Emacs process?

Well, not that drastically...  From the release notes of macOS 12 Appkit
(we're now at 14).

https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-12?changes=lat__5_3

Restorable State

    To enable secure coding for a restorable state, implement
    applicationSupportsSecureRestorableState(_:). When opted in:

        The system requires classes passed to restorationClass to
        explicitly conform to NSWindowRestoration.

        ...

I understand that as meaning that this switches on additional checks in
Appkit.  That should be okay for Emacs because it doesn't use this
feature of Appkit, at least AFAIK.

> It is presumably easy for some malware to just test all processes on the
> machine until one is found to be vulnerable, right?  So they don't have
> to specifically target Emacs?
>
> The full exploit chain there is not very easy to understand, but it
> seems like several techniques are used for some of the more nasty stuff,
> and some of the steps have been fixed already.  There can be other ways
> to do the same thing of course.  So I'm not sure what to say about the
> urgency of fixing this; it could be urgent, or it could wait until 29.2.
> What is your view?
>
> Another thing.  The link says:
>
>     Nevertheless, if you write an Objective-C application, please make
>     sure you add -applicationSupportsSecureRestorableState: to return
>     TRUE and to adapt secure coding for all classes used for your saved
>     states!
>
> Do we use "secure coding for all classes used for saved states", or does
> that also need to be fixed?
>
> BTW, any idea why we're only hearing about it now?

I guess Apple is more and more turning on "Secure Coding" stuff in their
libs.