Как утилита codesign от Apple решает, с каким алгоритмом SHA подписывать общую библиотеку?
во-первых, немного фона: я исследую, почему приложение MacOS/X моей компании (которое по всем учетным записям кажется правильно подписанным; оно отлично работает под MacOS/X 10.11.x и 10.12.X; Gatekeeper в порядке с ним на всех версиях MacOS; "spctl --assess "и" codesign-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-которые все подписаны с использованием одной и той же команды codesign, через скрипт сборки/пакета на нашей машине сборки 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, моя рабочая теория заключается в том, что OS/X 10.10.dyld x достаточно древний, что он не знает о хэшах SHA-256, и именно поэтому он ошибается, когда пытается загрузить общий пленный библиотека, подписанная только хэшем SHA-256.
мой вопрос (предполагая, что я не полностью лаю на неправильное дерево здесь): как codesign решает, когда штамповать файл только с хэшем sha256, а не добавлять как sha1, так и sha256 хэш? И как я могу заставить codesign всегда включать оба хэша, чтобы мое приложение могло запускаться под 10.10.x снова (как это было до того, как мы обновили нашу машину сборки до OSX/Sierra)?
для записи, вот как я вызываю codesign в моем скрипте сборки-аргументы вызова точно одинаковы для всех библиотек (как библиотеки Qt framework, которые заканчиваются 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"
2 ответов
после долгих поисков в гугле,ответ и ответ привел меня к решению.
проблема заключалась в том, что некоторые из сторонних общих библиотек, включенных в мое приложение, компилировались, используя только настройки сборки по умолчанию (например,"./ 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 в аргументы командной строки компилятора таким образом.
С этим изменением codesign теперь применяется как SHA-1, так и SHA-256 хэшей ко всем .dylib файлы, и в результате .приложение теперь работает, как ожидалось в соответствии с 10.10.x.
Джереми Фрайзенер это 1 работал для меня. Просто сторона не на компиляции OpenSSL. По крайней мере, для 1.0.2 h не было необходимости изменять файл Configure. Следующее сработало отлично
./Настроить darwin64-x86_64 с-СС общая --openssldir=$дома/cmake_builds/в OpenSSL-1.0.2 сек.Бен -mmacosx-версия-мин=10.10