2017-01-26 36 views
6

Po pierwsze, małe tło: badam, dlaczego aplikacja mojej firmy MacOS/X (która na wszystkich kontach wydaje się być poprawnie podpisana, działa poprawnie pod MacOS/X 10.11.x i 10.12.x; Gatekeeper jest w porządku z tym we wszystkich wersjach systemu MacOS: "spctl --assess" i "codesign -vvvv", wszyscy mówią, że spełnia wymagania dla wszystkich wersji systemu operacyjnego), ale nie uruchomią się pod OS/X 10.10.x - poniżej 10.10.x kiedy próbuję aby go uruchomić, dostaję zgłoszenie awarii gdzie dyld skarży się, że niektóre z bibliotek nie są poprawnie podpisane:W jaki sposób narzędzie kodów QR firmy Apple decyduje, z którym algorytmem SHA należy podpisać bibliotekę współdzieloną?

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' 

badając ten problem, zauważyłem, że biblioteki w .app/Contents/Framework - które są podpisane za pomocą dokładnie tego samego polecenia codesign, za pośrednictwem skryptu budowania/pakietowania na uruchomionej maszynie z systemem OS/X OS/X 10.12 - mają różne rodzaje obliczanych dla nich skrótów.

Oznacza to, że jeśli spojrzeć na jaki została zawarta jedna z plików niepodlegania-qt .dylib, widzę to tylko hash sha256 zapisane w nim:

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 

... ale jeśli patrzę w jaki sposób każdy z niewoli ram Qt została podpisana OTOH, widzę to zarówno SHA1 i hashe sha256 obejmowały:

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 

Zważywszy, że błąd dyld kiedy próbuje uruchomić mój app pod Yosemite odnosi się zawsze do jednej z bibliotek który ma tylko hasz sha256, moja robocza teoria mówi, że dynd OS/X 10.10.x jest wystarczająco starożytny t Nie wie o haszach SHA-256, i dlatego jest błędne, gdy próbuje załadować przechwyconą bibliotekę współdzieloną, która jest podpisana tylko za pomocą skrótu SHA-256.

Moje pytanie (zakładając, że nie szczekam zupełnie niewłaściwego drzewa tutaj) brzmi: w jaki sposób kodowanie decyduje o tym, kiedy oznaczyć plik hashem sha256, zamiast dodawać mieszanie sha1 i sha256? I w jaki sposób mogę wymusić kodowanie, aby zawsze zawierało oba skróty, aby moja aplikacja mogła ponownie uruchomić się pod 10.10.x (jak to było przed uaktualnieniem naszej maszyny do systemu OSX/Sierra)?

Dla przypomnienia, oto jak wywołuję codesign w moim skrypcie kompilacji - argumenty wywołania są dokładnie takie same dla wszystkich bibliotek (zarówno bibliotek framework Qt, które kończą się na sha1, sha256 i non-Qt biblioteki, które kończą się tylko SHA256), np:

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" 

Odpowiedz

7

Po dużo googling wokół, this answer i this answer doprowadziło mnie do roztworu.

Problem polegał na tym, że kilka bibliotek współużytkowanych firm trzecich zawartych w mojej aplikacji było kompilowanych przy użyciu tylko ich domyślnych ustawień kompilacji (np. "./configure; make"), a ponieważ były kompilowane pod OS/X 10.12, oczywiście zostały one skompilowane z myślą tylko o zgodności 10.12.

Aby uzyskać je skompilować w taki sposób, że wynikowe pliki .dylib byłby odpowiedni dla wcześniejszych wersji OS/X, a także dodałem te linie na górze mojego skryptu build:

export LDFLAGS="-mmacosx-version-min=10.9" 
export CFLAGS="-mmacosx-version-min=10.9" 
export CXXFLAGS="-mmacosx-version-min=10.9" 

... i to wystarczyło dla wszystkich bibliotek (libssh2, libsndfile, libogg, libflac, libvorbis, itp.) Z wyjątkiem libssl - dla tego musiałem ręcznie zmodyfikować plik Configure i wstawić - mmacosx-version-min argumenty w wierszu poleceń kompilatora w ten sposób.

Po tej zmianie, teraz kodign stosuje zarówno skróty SHA-1, jak i SHA-256 do wszystkich.Pliki dylib, a wynikowy plik .app działa teraz zgodnie z oczekiwaniami pod 10.10.x.

+0

Witam jestem obecnie w obliczu tego samego problemu, a coś nie jest dla mnie jasne Czy musisz dodać swoją linię eksportu u góry skryptu używanego do budowania własnej aplikacji, czy dodałeś te wiersze eksportu w wierszu poleceń, zanim odbudujesz stronę trzecią libs jak libsndfile? – nmud

+0

Mam skrypt budujący najwyższego poziomu, który sprowadza się do skryptów kompilacji niższego poziomu, które budują biblioteki, a następnie ostateczny skrypt kompilacji niższego poziomu, który buduje moją aplikację, która korzysta z tych bibliotek. Powyższe komendy eksportowania umieszczam na początku tego skryptu kompilacji najwyższego poziomu, aby zmienne środowiskowe LDFLAGS, CFLAGS i CXXFLAGS były obecne w środowisku dla wszystkich skryptów kompilacji (bibliotek i aplikacji). –

+0

W porządku. W moim przypadku buduję aplikację Qt, więc musiałbym przebudować biblioteki stron trzecich z tymi eksportowanymi flagami, a następnie odbudować własną aplikację, gdy biblioteki będą w porządku. Chodzi o to, że stworzyłem biblioteki stron trzecich, takie jak libsndfile z naparami, więc nie wiem, czy mogę zrobić coś takiego ./configure CFLAGS = "..." lub nie – nmud

1

Jeremy Friesner odpowiedź 1 pracował dla mnie. Po prostu nie z kompilacją OpenSSL. Przynajmniej na 1.0.2h nie było potrzeby zmiany pliku konfiguracyjnego. Poniżej działało dobrze

./configure darwin64-x86_64-cc dzielone --openssldir = $ HOME/cmake_builds/openssl-1.0.2h.bin -mmacosx-version-min = 10,10

+0

To może być lepiej umieszczone jako komentarz do mojej odpowiedzi niż jako osobna odpowiedź. –