Это создает серьезные задержки в выполнении, что можно легко проверить:
echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
time /tmp/test.sh && time /tmp/test.sh
Результаты удивляют:
$ time /tmp/test.sh && time /tmp/test.sh
Hello
real 0m1.417s
user 0m0.001s
sys 0m0.003s
Hello
real 0m0.003s
user 0m0.001s
sys 0m0.002s
Почему так происходит? Apple довольно давно использует механизм Notarization — с его помощью пользователи могут быть уверены, что программа, подписанная валидным Developer-ID не содержит зловредных компонентов. То есть помимо того, что приложение подписано, Apple его еще и автоматически проверит на элементы malware.
Что интересно, в будущем Apple вообще планирует запретить запуск не прошедших нотаризацию программ. Цитата:
Important
Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized.
Сейчас, видимо, в целях обкатки, любой новый неподписанный код, который вы запускаете, отправляется на сервера AAPL. Это легко проверить, запустив любой сетевой анализатор и увидев обращения к домену api.apple-cloudkit.com. Нужно отметить, что передается не сам код, а хеш-сумма. Проверить это можно двумя способами — сравнить обьем данных, передаваемых по сети, для скриптов разного размера; а также посмотрев на содержимое самого демона, ответственного за пересылку данных (otool -tV /usr/libexec/syspolicyd). Тем не менее, при медленном интернет соединении задержки могут составлять секунды — пользователь из Китая пишет о задержке в 5.47 секунд.
С одной стороны Apple можно понять — она заботится о безопасности пользователей, правда, вместе с тем превращая процесс любой разработки на их платформе в ад.
Но я хочу процитировать слова разработчика, который первым обратил внимание на проблему:
Подобное поведение операционной системы свидетельствует о серьезных проблемах в ее дизайне, когда два метода из низкоуровневого системного API (например exec и getxattr) выполняют синхронные сетевые обращения прежде чем вернуть результат.
Ссылки:
lapcatsoftware.com/articles/catalina-executables.html
news.ycombinator.com/item?id=23275922
sigpipe.macromates.com/2020/macos-catalina-slow-by-design
KYuri
Что будет, если «api.apple-cloudkit.com» заблокировать на роутере?
Или DNS по имени «api.apple-cloudkit.com» будет возвращать «0.0.0.0»?
drsmoll
Интересно что отвечает api.apple-cloudkit.com, на запрос с хешем? Потом поднять свой локальный сервер, который быстро будет отвечать — «ОК».
kwolfy
Думаю, что на деле все сильно сложнее. Наверняка "ок" еще подписывается приватным ключем не говоря уже об ssl
hollow1 Автор
Если прям на маке поставить фаервол и заблокировать все сетевые запросы от демона syspolicyd то запросы отправляться не будут. Думаю, если на роутере заблокировать, то примерно то же самое.
Lsh
Можно ли просто прибить демон?
(не пользуюсь macOS, мимо проходил)
hollow1 Автор
В macOS системные демоны лучше не прибивать. Один раз я прибил kerberos демон, при том что его вообще не использую, компьютеру помог только хард резет — иначе система просто уходила в бесконечную загрузку.
HellishGyp
Ну, как следует из названия демона, от отвечает за авторизацию. Не стоит его прибивать :)
DMGarikk
kerberos обычно не используется в локальной авторизации