Как утилита кодировки Apple определяет, с каким алгоритмом (ами) SHA подписывать разделяемую библиотеку?
Во-первых, немного предыстории: я исследую, почему приложение моей компании MacOS/X (которое по всем учетным записям, кажется, правильно подписано; оно отлично работает под MacOS/X 10.11.x и 10.12.x; Gatekeeper подходит для всех Версии MacOS: "spctl --assess" и "codeign -vvvv" все говорят, что он удовлетворяет своему требованию на всех версиях ОС) тем не менее не запускается под OS/X 10.10.x - под 10.10.x, когда я пытаюсь запустить это, я получаю отчет о сбое, где dyld жалуется, что некоторые библиотеки не подписаны правильно:
Dyld Error Message:
Library not loaded: @executable_path/../Frameworks/libcrypto.1.0.0.dylib
Referenced from: /Applications/MyApplication v123/MyApplication.app/Contents/MacOS/MyApplication
Reason: no suitable image found. Did find:
/Applications/MyApplication v123/MyApplication.app/Contents/MacOS/../Frameworks/libcrypto.1.0.0.dylib: code signature invalid for '/Applications/MyApplication v123/MyApplication.app/Contents/MacOS/../Frameworks/libcrypto.1.0.0.dylib'
Исследуя эту проблему, я заметил, что библиотеки в.app/Contents/Framework - все они подписаны с использованием одной и той же команды codeign - через скрипт build/package на нашей машине сборки OS / X, работающей под управлением OS/X 10.12 -- иметь для них различные типы хэшей.
То есть, если я посмотрю, как был подписан один из файлов, отличных от Qt.dylib, я вижу, что в нем записан только хэш sha256:
sierrabuild-polaris:MyApp v123 autobuild$ codesign -vvvd ./MyApp.app/Contents/Frameworks/libsndfile.1.dylib
Executable=/Applications/MyApp v123/MyApp.app/Contents/Frameworks/libsndfile.1.dylib
Identifier=libsndfile.1
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=4140 flags=0x0(none) hashes=125+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=b4256e9bf0fac567bb8ac86f56964c066b93d069
Hash choices=sha256 <----------------------------- ONLY 256!?
CDHash=b4256e9bf0fac567bb8ac86f56964c066b93d069
Signature size=8846
Authority=Developer ID Application: MyCompany
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 24, 2017, 1:39:58 AM
Info.plist=not bound
TeamIdentifier=5XD27G7646
Sealed Resources=none
Internal requirements count=1 size=172
... но если я посмотрим, как была подписана какая-либо из интегрированных сред Qt, OTOH, я вижу, что в нее включены хэши sha1 и sha256:
sierrabuild-polaris:MyApp v123 autobuild$ codesign -vvvd ./MyApp.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
Executable=/Applications/MyApp v123/MyApp.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
Identifier=org.qt-project.QtCore
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=42549 flags=0x0(none) hashes=1324+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=09b5854f83091228f1baaad1455e7a30d6500c95
CandidateCDHash sha256=6dfdc74da06618e1b406a6e5fd0794fe43701def
Hash choices=sha1,sha256 <------------- BOTH sha1 and sha256, yay!
CDHash=6dfdc74da06618e1b406a6e5fd0794fe43701def
Signature size=8896
Authority=Developer ID Application: MyCompany
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 24, 2017, 1:39:57 AM
Info.plist entries=8
TeamIdentifier=5XD27G7646
Sealed Resources version=2 rules=13 files=1
Internal requirements count=1 size=184
Учитывая, что ошибка dyld при попытке запустить мое приложение под Yosemite всегда относится к одной из библиотек, которая имеет только хэш sha256, моя рабочая теория заключается в том, что dyld в OS / X 10.10.x достаточно древний, чтобы не знать о SHA-256 хэшей, и поэтому он выдает ошибку, когда пытается загрузить невыполненную разделяемую библиотеку, подписанную только с помощью хэша SHA-256.
Мой вопрос (при условии, что я здесь не совсем не лаю): как CodeSign решает, когда штамповать файл только с хэшем sha256, а не с хэшем sha1 и sha256? И как я могу заставить кодировку всегда включать оба хэша, чтобы мое приложение могло снова запускаться под 10.10.x (как это было до того, как мы обновили нашу сборочную машину до OSX/Sierra)?
Напомним, что вот как я вызываю codeign в моем скрипте сборки - аргументы вызова абсолютно одинаковы для всех библиотек (и библиотеки фреймворка Qt, заканчивающиеся на sha1,sha256, и библиотеки не-Qt, которые заканчиваются только с sha256), например:
codesign -f -v -s "Developer ID Application: MyCompanyName" "./Frameworks/libcrypto.1.0.0.dylib"
codesign -f -v -s "Developer ID Application: MyCompanyName" "./Frameworks/QtCore.framework/Versions/5/QtCore"
3 ответа
После долгих поисков, этот ответ и этот ответ привели меня к решению.
Проблема заключалась в том, что некоторые сторонние разделяемые библиотеки, включенные в мое приложение, компилировались с использованием только их настроек сборки по умолчанию (например, "./configure; make"), и, поскольку они компилировались в OS/X 10.12, естественно, они были скомпилированы с учетом только 10.12 совместимости.
Чтобы их можно было скомпилировать таким образом, чтобы полученные файлы.dylib подходили и для более ранних версий OS / X, я добавил эти строки в начало моего скрипта сборки:
export LDFLAGS="-mmacosx-version-min=10.9"
export CFLAGS="-mmacosx-version-min=10.9"
export CXXFLAGS="-mmacosx-version-min=10.9"
... и это помогло всем библиотекам (libssh2, libsndfile, libogg, libflac, libvorbis и т. д.), за исключением libssl - для этого мне пришлось вручную изменить файл Configure и вставить -mmacosx- аргумент version-min в аргументы командной строки компилятора таким образом.
С этим изменением теперь codeign применяет хеши SHA-1 и SHA-256 ко всем файлам.dylib, и результирующий.app теперь работает, как ожидается, в соответствии с 10.10.x.
Ответ Джереми Фризнера 1 сработал для меня. Просто сторона не на компиляции OpenSSL. По крайней мере, для 1.0.2h не было необходимости изменять файл конфигурации. Следующее работало нормально
./Configure darwin64-x86_64-cc shared --openssldir=$HOME/cmake_builds/openssl-1.0.2h.bin -mmacosx-version-min=10.10
Он перестает использовать SHA-1, только если вы ориентируетесь на macOS 10.14 или более позднюю версию.
ПараметрMACOSX_DEPLOYMENT_TARGET = 10.14
у меня сработало (должно быть установлено как переменная среды для построения и связывания вне Xcode, и может быть установлено в целевых конфигурациях Xcode для самого Xcode).