Подтвердить что ты не робот

Являются ли в Mac App Store кодовыми обозначениями ресурсов всегда версии 1?

После того, как последнее сообщение электронной почты детализирует изменения в привратнике для 10.10 beta 5 и 10.9.5, я пошел и сразу же проверил свое приложение с рекомендованным методом от TN2206. К моему удивлению, поскольку я не использовал никаких правил ресурса и не построил его на Mavericks, это не удалось:

$ spctl -a -t exec -v /Applications/MyApp.app/
/Applications/MyApp.app/: rejected
source=obsolete resource envelope

Затем я продолжил проверку представленного двоичного файла в архиве Xcode, который был незамедлительно отклонен, но без предупреждения об устаревших ресурсах. Я полагаю, потому что он подписан сертификатом подачи.

$ spctl -a -t exec -v Products/Applications/MyApp.app/
Products/Applications/MyApp.app/: rejected

Позже я проверил сами конверты ресурсов:

$ codesign -d -v  /Applications/MyApp.app/
Executable=/Applications/MyApp.app/Contents/MacOS/MyApp
Identifier=my.app.id
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=14108 flags=0x200(kill) hashes=697+5 location=embedded
Signature size=4169
Info.plist entries=34
TeamIdentifier=not set
Sealed Resources version=1 rules=5 files=82
Internal requirements count=1 size=220

Затем представленное приложение:

$ codesign -d -v  Products/Applications/MyApp.app/
Executable=/Users/jorgepeixotovasquez/Library/Developer/Xcode/Archives/2014-07-09/myapp 09-07-14 00.34.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/myApp
Identifier=my.app.id
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=14123 flags=0x0(none) hashes=697+5 location=embedded
Signature size=4393
Signed Time=09/07/2014 00:34:08
Info.plist entries=34
TeamIdentifier=F2XAAD6WWR
Sealed Resources version=2 rules=12 files=85
Internal requirements count=1 size=220

Как вы можете видеть, загруженное приложение для Mac App Store имеет только конверт ресурсов версии 1, даже с представлением версии 2. Разумеется, я проверил папку /Application и узнал, что каждое приложение, загруженное из Mac App Store, также имеет конверт версии 1, даже Apple.

Кто-нибудь знает, будет ли это нормальным, т.е. если Mac App Store при повторной подписке приложения добавит только конверты на одну версию?
Более того, это вызовет проблемы?
Будет ли это исправлено Apple?
После этого исправления я должен повторно отправить свое приложение?

4b9b3361

ОТВЕТЫ

Ответ 1

Это действительно ошибка. A открыл радар, который был закрыт как дубликат, который открыт.

Ответ 2

Обозначение версии (1 или 2) больше связано с тем, какая версия OS X была использована для сборки и подписи кода.

Конверты ресурсов версии 1 и 2

(Подписи кода, содержащие конверты ресурсов версии 1 или версии 2 также известны как подписи версии 1 или подписи 2-й версии, соответственно)

< OS X v10.9 (версия 1)

  • Записал только файлы в каталоге Ресурсы и проигнорировал остальные.
  • Игнорирует символические ссылки.
  • Если система равна < 10.9 он игнорирует конверты ресурсов версии 2 и использует версию 1 исключительно.
  • Использует документированную функцию подписания (--resource-rules), чтобы контролировать, какие файлы в комплекте должны быть запечатаны подписи кода. (устарел для 10.9+)

OS X v10.9 + (версия 2)

  • Записывает вложенный код (фреймворки, dylib, вспомогательные инструменты и приложения, плагины и т.д.).
  • Записывает по существу все файлы по умолчанию.
  • Записывает символические ссылки.
  • Создает, по умолчанию, конверты ресурсов версии 2 и версии.
  • Если система 10.9+ видит подпись версии 1, она выполняет проверку версии 1.
  • Всегда запечатывает все файлы в комплекте; нет необходимости указывать это явно.
  • codeign на OS X 10.9+ и более поздних версиях не отображает конверт ресурса версии 1, если присутствует конверт ресурсов версии 2, поскольку будет использоваться только конверт ресурсов версии 2.

Чтобы определить, какая версия огибающей ресурса имеет сигнатура кода, используйте codesign -dv:

$ codesign -dv My.app/
[...]
Sealed Resources version=2 rules=15 files=53
[...]

Изменения в OS X 10.9.5 и Предварительный просмотр разработчика Yosemite 5

Изменения в OS X версии 10.9.5+

  • Подписи версии 1, созданные с версиями OS X до Mavericks, больше не будут распознаваться Gatekeeper и считаются устаревшими.
  • Чтобы ваши приложения запускались на обновленных версиях OS X, они должны быть подписаны на OS X версии 10.9 или новее и, следовательно, иметь подпись версии 2.
  • Приложения, подписанные с использованием предыдущих версий OS X, необходимо будет переписать с версией 10.9 или новее для создания подписей версии 2.
  • Приложения, подписанные с подписями версии 2, будут работать в более старых версиях OS X.
  • Если ваше приложение находится в Mac App Store, отправьте повторно подписанное приложение в качестве обновления.

Для OS X версии 10.9 или новее:

  • Включить только подписанный код в каталогах, которые должны содержать подписанный код.
  • Включать только ресурсы в каталогах, которые должны содержать ресурсы.
  • Не используйте флаг --resource-rules или ResourceRules.plist. (ваше приложение будет отклонено)

Чтобы ваши текущие и предстоящие выпуски работали корректно с помощью Gatekeeper, протестируйте OS X версии 10.10 (Seed 5 или новее) и OS X версии 10.9.5.

spctl будет принимать по умолчанию приложения приложений и приложений, поддерживающие идентификатор разработчика, загруженные из Mac App Store. Он отклонит приложения подписанный с сертификатами разработки или распространения Mac App Store.

Используйте spctl в своем приложении, например:

$ spctl -a -t exec -vv Foo.app

Это результат, если ваша подпись приложения будет принята:

Foo.app: accepted

source=Developer ID
Источником

➣ может быть Mac App Store.

Если ваша подпись приложения имеет только устаревший конверт ресурса 1, вы увидите следующее:

Foo.app: rejected

source=obsolete resource envelope

Примечание. Необходимо подписать код во время работы OS X Mavericks, чтобы получить подпись версии 2. Фактические машины для подписи кода являются частью операционной системы, а не инструментария кодов. Не удалось скопировать инструмент кодов с Mavericks на более раннюю версию OS X.

Ответ 3

Эта проблема, по-видимому, исправлена ​​в Mac OS X Yosemite (проверена 10.10.5), но она снова появилась на El Capitan (проверена 10.11.4).

Пакеты приложений могут быть легко подписаны и проверены. Например:

$ codesign --deep --strict -r="designated => anchor trusted" -s MouseSigner ebe.app
$ codesign -vvvv ebe.app
ebe.app: valid on disk
ebe.app: satisfies its Designated Requirement
$ codesign -dvvv ebe.app
Executable=/Volumes/ebe/ebe.app/Contents/MacOS/ebe
Identifier=org.burrow.ebe
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=29151 flags=0x0(none) hashes=905+4     location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=b1c33........
CandidateCDHash sha256=384e........
Hash choices=sha1,sha256
CDHash=384e........
Signature size=2699
Authority=MouseSigner
Authority=Forest CA
Signed Time=Apr 10, 2016, 14:49:44
Info.plist entries=8
TeamIdentifier=not set
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=36
$ spctl -a -vvv -t exec ebe.app
ebe.app: accepted
source=Forest CA
origin=MouseSigner
$

Однако любая попытка подписать один бинарный (исполняемый файл) не отвечает системной политике (как показано spctl):

$ codesign -dvv foo-ssl
Executable=/Users/me/src/foo-ssl
Identifier=foo-ssl
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=280 flags=0x0(none) hashes=3+4 location=embedded
Signature size=2699
Authority=MouseSigner
Authority=Forest CA
Signed Time=Apr 9, 2016, 00:02:21
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=44
$ spctl -a -vvv -t exec foo-ssl
foo-ssl: rejected
source=obsolete resource envelope
origin=MouseSigner

Это включает в себя программные двоичные файлы Apple, такие как /usr/bin/perl:

$ codesign -dvv /usr/bin/perl
Executable=/usr/bin/perl
Identifier=com.apple.perl
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=223 flags=0x0(none) hashes=6+2 location=embedded
Platform identifier=1
Signature size=4105
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64
$ spctl -a -vvv -t exec /usr/bin/perl
/usr/bin/perl: rejected
source=obsolete resource envelope
origin=Software Signing
$

Радар был отправлен - никакой реакции от Apple еще. Отчет от Apple был менее чем обнадеживающим:

Please know that our engineering team has determined that this issue
behaves as intended based on the information provided.

Gatekeeper (as of 10.11.4) rejects anything that isn’t an app (or "like" an
app, such a widget). This is part of a general hardening effort.

Ответ 4

В моей поданной заявке также был конверт v2, который Apple заменил на v1.

Я оставил "*.dylib" в папке "Ресурсы" полностью без подписи.

Убедитесь, что ваши вложенные библиотеки подписаны:

codesign --display --verbose=4 library.dylib
library.dylib: code object is not signed at all

Однако этого было недостаточно.

Чтобы исправить это, я добавил к дополнительному кодовому имени post-build и pkg, создав script. Следуйте этому учебнику

Также убедитесь, что ваши сторонние структуры правильно структурированы (не пропустите символические ссылки). Проверьте руководство Apple по структуре .

EDIT: Не работает. Пакет все еще возвращается в версии 1. Любая идея?

Ответ 5

Это проблема с Mac OSX 10.9.5 и более поздними версиями. Apple исправит это в будущем выпуске.

Пожалуйста, просмотрите мои комментарии для Ошибка при экспорте архива