Подпись хелпера и hardened runtime — вместе с Developer ID

[akalikbergenov]

Вторая половина #1, отложенная до покупки Apple Developer ID. Первая половина
(ссылки календаря, санитайзинг метаданных, типы отказа в буфере, SHA-256 в
заметках) уже в main.

Что предложено

Scripts/bundle.sh подписывает вложенное отдельно от бандла, без устаревшей
--deep, с --options runtime и entitlement на Apple-события; хеш
libcyclopmedia.dylib запечатывается в Info.plist, а NowPlayingFeed
сверяет его перед тем, как отдать библиотеку в perl.

Зачем

/usr/bin/perl подписан без валидации библиотек: он загрузит что угодно,
что лежит по этому пути, и оно окажется внутри процесса, которому доверяет
mediaremoted. Между этими двумя фактами сегодня не стоит ничего.

Почему ждём

Автор PR сам назвал границу применимости, и это честно: против простой подмены
файла проверка держит, но кто может переписать dylib — перепишет и Info.plist
рядом с ним. Настоящей границей это становится только там, где подделанный
бандл вообще не запускается, то есть с Developer ID и нотаризацией.

А риск сегодня — реальный и молчаливый: связка «hardened runtime + ad-hoc
подпись + чужой perl» ломает Now Playing без единого сообщения. Не упадёт, не
покажет ошибку — вкладка просто скажет «Ничего не играет», и заметит это не
разработчик, собирающий из исходников, а тот, кто поставил образ.

Что сделать, когда дойдут руки

1. Купить Developer ID, добавить нотаризацию в Scripts/bundle.sh.
2. Взять правки подписи и сверки хеша из Ограничить ссылки из календаря, сверять хеш хелпера, поправить SECURITY.md #1 (Resources/Cyclop.entitlements,
   bundle.sh, NowPlayingFeed.isTrusted, шаг проверки в CI).
3. Прогнать Now Playing на чистой машине из установленного образа — не из
   сборки в build/: разница здесь и есть суть проверки.

Заодно снимется требование «Всё равно открыть» при первом запуске, о котором
спрашивают в комментариях к видео.

Автор исходных правок — @DontTrustMexD.

[ispy4you]

Ещё один живой случай из той же связки, с другой стороны — не про perl/dylib, а про TCC-атрибуцию под hardened runtime. Пока разбирался с #30, поймал момент, когда Cyclop (ad-hoc подпись, flags=0x2(adhoc), TeamIdentifier=not set) запрашивал доступ к календарю, а hardened runtime приписал ответственность за запрос не самому Cyclop, а процессу, который его запустил (у меня это была IDE), — и тихо заблокировал доступ ещё до того, как дело дошло до собственного TCC-состояния приложения. Симптом был неотличим от обычного отказа: приложение вообще не появилось в списке в Настройках, потому что блокировка случилась на уровень выше. log show --predicate 'process == "tccd"' называет ответственный процесс прямым текстом — так и нашёл.

Не тот же риск, что с perl/dylib, но тот же корень: без стабильной подписи (Developer ID) hardened runtime может вести себя непредсказуемо и молча. Ещё один случай, где сборка выглядит рабочей у одного человека и нерабочей у другого без единого сообщения об ошибке.

[akalikbergenov]

Отмечусь, чтобы не выглядело брошенным: issue ждёт покупки Developer ID, а не решения.

Заодно попросил в #34 прислать отдельным PR часть про подпись устойчивой личностью в
Scripts/bundle.sh — TCC привязывает выданные разрешения к хешу бинарника, и при ad-hoc они
слетают на каждой пересборке. Это не заменяет нотаризацию, но снимает самую заметную половину
боли для тех, кто собирает из исходников.