Во-первых, небольшой фон: я изучаю, почему приложение MacOS/X моей компании (которое по всем учетным записям, кажется, правильно подписано, отлично работает под MacOS/X 10.11.x и 10.12.x; гейткипер в порядке с ним на всех версиях MacOS: «spctl -assess» и «codesign -vvvv» все говорят, что он удовлетворяет его требованиям для всех версий ОС), тем не менее, не будет запускаться под OS/X 10.10.x - под 10.10.x, когда я попытаюсь чтобы запустить его, я получаю отчет о сбое, где dyld жалуется, что некоторые из библиотек не подписаны правильно:Как утилита Apples для кодирования определяет, какой алгоритм SHA подписать совместно используемую библиотеку?
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/Содержание/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 был подписан, Ото, я вижу это как 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.
Мой вопрос (предполагая, что я не полностью лаем по неправильному дереву здесь): каким образом кодовое слово решает, когда нужно штамповать файл только с помощью хэша sha256, а также добавить как sha1, так и sha256 хэш? И как я могу заставить кодовое слово всегда включать оба хэша, чтобы мое приложение могло снова запускаться под 10.10.x (как это было раньше, прежде чем мы обновили нашу машину сборки до OSX/Sierra)?
Для записи, вот как я вызываю codeign в моем скрипте сборки - аргументы вызова одинаковы для всех библиотек (как библиотеки фреймворка Qt, в которые входят sha1, sha256 и non-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"
Здравствуйте Я в настоящее время столкнувшись с той же проблемой, и мне что-то неясно Вам нужно было добавить строку экспорта в начало вашего скрипта, используемого для создания собственного приложения, или вы добавили эти строки экспорта в командной строке, прежде чем восстанавливать стороннюю сторону libs как libsndfile? – nmud
У меня есть сценарий сборки верхнего уровня, который вызывает более строгие сценарии построения, которые строят библиотеки, а затем окончательный строковый скрипт нижнего уровня, который создает мое приложение, которое использует эти библиотеки. Я помещал вышеуказанные экспортные команды в верхнюю часть этого сценария верхнего уровня, чтобы переменные среды LDFLAGS, CFLAGS и CXXFLAGS присутствовали в среде для всех скриптов сборки (библиотек и приложений). –
Хорошо. В моем случае я создаю приложение Qt, поэтому мне придется перестроить сторонние библиотеки с этими экспортированными флагами, а затем перестроить собственное приложение, как только библиотеки будут в порядке. Дело в том, что я создал сторонние библиотеки, такие как libsndfile с варевом, поэтому я не знаю, могу ли я что-то сделать ./configure CFLAGS = «...» или нет – nmud