Как утилита 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