codesign

Synopsis

     codesign -s identity [-i identifier] [-r requirements] [-fv] path ...
     codesign -v [-R requirement] [-v] [path|pid ...]
     codesign -d [-v] [path|pid ...]
     codesign -h [-v] [pid ...]
     codesign --validate-constraint path ...

Description

codesign komutu, kod imzaları oluşturmak, doğrulamak ve görüntülemekle birlikte, sistemdeki imzalı kodun dinamik durumu hakkında sorgulama yapmak için kullanılır.

codesign, hangi eylemin gerçekleştirileceğini belirlemek için tam olarak bir işlem seçeneğine ve bunun yanı sıra davranışını değiştirmek üzere istenen sayıda diğer seçeneklere ihtiyaç duyar. Her çağrıda herhangi bir sayıda nesne üzerinde işlem yapabilir, ancak hepsi üzerinde aynı işlemi gerçekleştirir.

codesign, tek karakterli (klasik) seçeneklerin yanı sıra --ad ve --ad=değer biçimindeki GNU tarzı uzun seçenekleri de kabul eder. Yaygın seçeneklerin her iki biçimi de mevcuttur; daha az sıklıkla kullanılan ve özel olan seçeneklerin ise yalnızca uzun biçimleri vardır. İsteğe bağlı değerlere sahip seçeneklerde --ad değer biçiminin (eşittir işareti olmadan) beklendiği gibi çalışmayacağını unutmayın.

Options

Seçenekler aşağıdaki gibidir:

--all-architectures Evrensel ("fat") Mach-O ikili dosyasına sahip kodlarda kod imzasını doğrular iken, içerilen her mimariyi ayrı ayrı doğrular. -a (--architecture) seçeneği ile geçersiz kılınmadığı sürece varsayılan davranış budur.

-a, --architecture architecture İmzaları doğrular veya görüntüler iken, verilen Mach-O mimarisini açıkça seçer. Mimari, adı (örneğin i386) veya numarası ile belirtilebilir; numara ile belirtilirse, virgülle ayrılarak bir alt mimari eklenebilir. Bu seçenek yalnızca Mach-O ikili koduna uygulanır ve diğer türler için yoksayılır. Eğer yol Mach-O biçimini kullanıyorsa ve verilen mimariye ait hiçbir kod içermiyorsa komut başarısız olur. Doğrulama için varsayılan değer, mevcut tüm mimarileri doğrulamak üzere --all-architectures seçeneğidir. Görüntüleme için varsayılan değer, ana bilgisayar sisteminin yerel mimarisini raporlamaktır. İmzalama sırasında codesign, evrensel bir Mach-O dosyasında bulunan tüm mimarileri her zaman imzalar.

--bundle-version version-string Framework'ler gibi sürümlendirilmiş paketleri (bundle) işler iken, üzerinde işlem yapılacak sürümü açıkça belirtir. Bu, paketin "Versions" dizinindeki isimlerden biri olmalıdır. Belirtilmezse codesign, paketin varsayılan sürümünü kullanır. Sistemle birlikte sunulan çoğu framework'ün yalnızca tek bir sürümü olduğunu ve bu nedenle bu seçeneğin onlar için geçersiz olduğunu unutmayın. Şu anda bir paketin tüm sürümleri üzerinde aynı anda işlem yapmaya yönelik bir olanak bulunmamaktadır.

--check-notarization Verilen yollardaki kodu doğrular iken, bir noter onay (notarization) biletinin mevcut olup olmadığını görmek için çevrimiçi noter onay kontrolünü zorunlu kılar.

-d, --display Verilen yollardaki kod hakkında bilgi görüntüler. Ayrıntı düzeyi arttıkça daha fazla çıktı üretilir. Biçim, insan gözü için anlaşılır kalırken basit betikler tarafından orta derecede kolay analiz edilecek şekilde tasarlanmıştır. Ayrıca, ek bilgi almak için -r, --file-list, --extract-certificates ve --entitlements seçenekleri kullanılabilir.

-D, --detached filename İmzalama yaparken, belirtilen dosyaya ayrılmış (detached) bir imza yazılacağını belirtir. İmzalanan kod üzerinde değişiklik yapılmaz ve kodun yazılabilir olması gerekmez. Doğrulama yaparken, doğrulama için kullanılacak ayrılmış imzayı içeren dosyayı belirtir. Koddaki gömülü imzalar yoksayılır.

• --deep: (macOS 13.0 itibarıyla imzalama için KULLANIMDAN KALDIRILMIŞTIR) Bir paketi imzalar iken yardımcı programlar, framework'ler ve eklentiler (plug-in) gibi iç içe geçmiş kod içeriklerinin sırasıyla özyinelemeli (recursive) olarak imzalanacağını belirtir. Dikkat edilmesi gerekenler:

• Tüm imzalama seçenekleri sırasıyla tüm iç içe geçmiş içeriklere uygulanacaktır. Bu neredeyse hiçbir zaman istemeyeceğiniz bir durumdur.

• İç içe geçmiş kod içeriği, yalnızca bir Contents klasörüne sahip macOS tarzı paketler için geçerli özel bir terimdir. Yalnızca yalın Mach-O dosyaları ve iyi yapılandırılmış paketler iç içe geçmiş kod içeriği olarak nitelendirilir. İç içe geçmiş kod içeriği konumlarındaki paket olmayan dizinler imzalama sırasında hataya neden olur. codesign aracı, iç içe geçmiş kod içeriklerini yalnızca aşağıdaki dizinlerde keşfedecektir:

• Contents

• Contents/Frameworks

• Contents/SharedFrameworks

• Contents/PlugIns

• Contents/Plug-ins

• Contents/XPCServices

• Contents/Helpers

• Contents/MacOS

• Contents/Library/Automator

• Contents/Library/Spotlight

• Contents/Library/LoginItems

• Herhangi bir kod (Mach-O'lar, paketler) yukarıda listelenen konumların dışında yer alıyorsa, --deep seçeneği ile imzalanmayacaktır.

• Contents klasörü olmayan iOS tarzı bir pakette --deep seçeneğinin kullanılması hataya neden olmaz ancak yalnızca paketin ana ikili dosyasını imzalar. Bir paketi doğrular iken, bu seçenek herhangi bir iç içe geçmiş kod içeriğinin tüm içeriğiyle birlikte özyinelemeli olarak doğrulanacağını belirtir. Varsayılan olarak, iç içe geçmiş içeriğin doğrulanması, iç içe geçmiş koddaki değişiklikleri tespit edemeyebilecek yüzeysel bir inceleme ile sınırlıdır. Bir imzayı görüntüler iken, bu seçenek doğrudan iç içe geçmiş kodlerin bir listesinin görüntüleme çıktısına yazılacağını belirtir. Bu, yalnızca hedef nesnenin içinde doğrudan iç içe geçmiş kodları listeler; dolaylı olarak iç içe geçmiş her şey codesign komutunun özyinelemeli olarak uygulanmasını gerektirir.

--detached-database İmzalama yaparken, --detached seçeneğinde olduğu gibi ayrılmış bir imza oluşturulacağını ancak elde edilen imzanın bir sistem veritabanına yazılacağını belirtir. Buradan imza, sistem üzerinde imzasız görünen kod doğrulandığında otomatik olarak kullanılabilir hale getirilir. Bu sistem veritabanına yazmak, sıradan kullanıcıların sahip olmadığı yükseltilmiş işlem ayrıcalıkları gerektirir.

-f, --force İmzalama yaparken, codesign aracının verilen yollardaki mevcut tüm imzaları değiştirmesini sağlar. Bu seçenek olmadan, mevcut imzalar değiştirilmez ve imzalama işlemi başarısız olur.

--force-library-entitlements İmzalama yaparken, sağlanan yetkilendirmeleri (entitlements) kütüphanelerin (ana yürütülebilir olmayan dosyaların) imzasına zorla gömer. macOS 15.0 itibarıyla tüm platformlar için imzalama yapılırken kütüphane imzalarına yetkilendirme gömmemek varsayılan davranıştır.

--generate-entitlement-der İmzalama yaparken, sağlanan yetkilendirme XML verilerini DER biçimine dönüştürür ve yetkilendirmeleri imzada hem XML hem de DER olarak gömer. macOS 12.0 itibarıyla tüm platformlar için imzalama yapılırken DER yetkilendirmelerinin gömülmesi varsayılan davranıştır. Bu parametre macOS 10.14 (Mojave) sürümünde sunulmuştur.

-h, --hosting Çalışan bir programın barındırma zincirini (hosting chain) oluşturur ve yazdırır. pid argümanları çalışan kodu (pid'ler vb.) belirtmelidir. Ayrıntılı (verbose) seçeneklerle bu durum, barındırma zincirinin her bir öğesinin bağımsız dinamik geçerlilik durumunu da görüntüler.

-i, --identifier identifier İmzalama sırasında, kod imzalarına gömülecek benzersiz tanımlayıcı (identifier) dizesini açıkça belirtir. Bu seçenek atlanırsa, tanımlayıcı ya Info.plist dosyasından (varsa) ya da imzalanan yürütülebilir dosyanın adından türetilir; muhtemelen --prefix seçeneğiyle değiştirilir. Farklı programları aynı tanımlayıcıyla imzalamak çok kötü bir fikirdir.

-o, --options flag,... İmzalama sırasında, kod imzasına gömülecek bir dizi seçenek bayrağı belirtir. Değer, virgülle ayrılmış adlar listesi (boşluksuz) biçimini alır. Alternatif olarak, seçenek maskesini (CodeDirectory bayrak sözcüğü) doğrudan belirtmek için sayısal bir değer kullanılabilir. Aşağıdaki SEÇENEK BAYRAKLARI bölümüne bakın.

-P, --pagesize pagesize Kod imzalamanın ayrıntı düzeyini (granularity) belirtir. Sayfa boyutu (pagesize) ikinin bir kuvveti olmalıdır. pagesize baytlık bloklar ayrı ayrı imzalanır ve böylece gerektiğinde bağımsız olarak doğrulanabilir. Özel bir durum olarak, sıfır sayfa boyutu, kodun tamamının tek bir, muhtemelen devasa bir sayfa olarak imzalanması ve doğrulanması gerektiğini belirtir. Bu seçenek yalnızca ana yürütülebilir dosyaya uygulanır ve kaynaklar dahil ilişkili verilerin mühürlenmesi üzerinde hiçbir etkisi yoktur.

--remove-signature Verilen yollardan mevcut kod imzasını kaldırır.

-r, --requirements requirements İmzalama sırasında, belirtildiği şekilde kod yollarına dahili gereksinimlerin (internal requirements) gömülmesi gerektiğini belirtir. Aşağıdaki "gereksinimlerin belirtilmesi" bölümüne bakın. Açıkça belirtilmeyen gereksinim türlerine varsayılan değerler uygulanacaktır; böyle bir varsayılanı etkisiz hale getirmek istiyorsanız, o tür için "never" (asla) belirtin. Görüntüleme sırasında, kodun dahili gereksinimlerinin nereye yazılacağını belirtir. Bunları standart çıktıya yazmak için -r- kullanın.

-R, --test-requirement requirement Doğrulama sırasında, verilen yolların belirtilen kod gereksinimine göre doğrulanması gerektiğini belirtir. Bu seçenek atlanırsa, kod yalnızca dahili bütünlük açısından ve kendi belirlenmiş gereksinimine (designated requirement) göre doğrulanır.

-s, --sign identity Bu kimliği (identity) kullanarak verilen yollardaki kodu imzalar. Aşağıdaki İMZALAMA KİMLİKLERİ bölümüne bakın.

-v, --verbose Çıktının ayrıntı düzeyini ayarlar (sayısal bir değerle) veya artırır. Ayrıntılı (verbose) seçenek olmadan, klasik UNIX stilinde, başarı durumunda hiçbir çıktı üretilmez. Başka hiçbir seçenek farklı bir eylem talep etmiyorsa, karşılaşılan ilk -v doğrulamayı başlatmak üzere --verify olarak yorumlanır (ve ayrıntı düzeyini artırmaz).

-v, --verify Kod imzalarının doğrulanmasını talep eder. Başka eylemler de (imzalama, görüntüleme vb.) talep edilmişse, -v seçeneği --verbose anlamına gelecek şekilde yorumlanır.

--continue Bir yol argümanının işlenmesi başarısız olsa bile codesign aracının diğer yol argümanlarını işlemeye devam etmesini söyler. Bu seçenek verilirse, operasyonel hatalardan kaynaklanan çıkışlar tüm yol argümanları değerlendirilene kadar ertelenir. Çıkış kodu daha sonra en ciddi hatayı (veya eşit önemde ise karşılaşılan ilk hatayı) belirtecektir.

--dryrun İmzalama sırasında, neredeyse tüm imzalama işlemlerini gerçekleştirir ancak sonucu gerçekten hiçbir yere yazmaz. Kriptografik imzalar, verilen imzalama kimliği kullanılarak ve normal şekilde her türlü erişim denetimi kontrolünü tetikleyerek yine de oluşturulur, ancak elde edilen imza daha sonra atılır.

--entitlements path İmzalama yaparken, verilen yoldaki dosyayı alır ve içeriğini yetkilendirme verisi olarak imzaya gömer. Eğer yoldaki veri zaten uygun bir ikili ("blob") başlığıyla başlamıyorsa, otomatik olarak bir tane eklenir. Bir imzayı görüntüler iken, imzadan yetkilendirme verilerini çıkarır ve soyut bir gösterimle verilen yola yazar. Gerekirse yetkilendirmeleri istenen biçimde çıktı almak için --xml veya --der aktarılabilir; her ikisini de aktarırsanız DER yazdırılır. Standart çıktıya yazmak için yol olarak "-" kullanın. Eğer imzada yetkilendirme verisi yoksa, hiçbir şey yazılmaz (bu bir hata değildir).

--enforce-constraint-validity İmzalama yaparken, sağlanan kısıtlamaların (örneğin --launch-constraint-* veya --library-constraint) yapısal olarak geçerli olmasını ve yalnızca bu macOS sürümünde bilinen anahtarları içermesini veya $optional işlecini düzgün şekilde kullanmasını gerektirir. Varsayılan olarak kısıtlamalar kontrol edilir ve hatalar bildirilir ancak geçerlilikleri zorunlu tutulmaz. Bu varsayılan davranış, geliştiricilerin mevcut işletim sistemi sürümünde daha yeni işletim sistemi sürümleri için kısıtlamalar belirlemesine olanak tanır.

--extract-certificates prefix Bir imzayı görüntüler iken, gömülü sertifika zincirindeki sertifikaları çıkarır ve bunları ayrı dosyalara yazar. Dosya adlarını oluşturmak için prefix argümanına 0, 1, ... sayıları eklenir; bu adlar göreli veya mutlak olabilir. Sertifika 0 uç (leaf - imzalama) sertifikasıdır ve imzada kaç sertifika varsa o kadar dosya yazılır. Dosyalar ASN.1 (DER) biçimindedir. Eğer prefix belirtilmezse varsayılan önek, geçerli dizindeki "codesign" ifadesidir.

--file-list path İmzalama yaparken veya bir imzayı görüntüler iken codesign, imzalama işleminin bir parçası olarak değiştirilmiş olabilecek dosyaların bir listesini verilen yola yazar. Bu, neyin değiştiğini veya bir programın "imzasını" oluşturmak için hangi dosyaların gerektiğini bilmesi gereken yükleyici veya yama programları için yararlıdır. Verilen dosyaya, yazılan her mutlak yol için bir satır olacak şekilde ekleme yapılır. "-" (tek tire) argümanı standart çıktıyı belirtir. Listenin biraz kötümser olabileceğini unutmayın - listede yer almayan tüm dosyaların imzalama işlemiyle değişmediği garanti edilir ancak listedeki bazı dosyalar aslında değişmemiş olabilir. Ayrıca bu dosyaların genişletilmiş özniteliklerinde (extended attributes) değişiklikler yapılmış olabileceğini de unutmayın.

--ignore-resources Statik doğrulama sırasında, kodun kaynaklarının (resources) içeriğini doğrulamaz. Bu durum, kaynakları bozulmuş (veya uygunsuz şekilde imzalanmış) olan kodlardaki doğrulamayı başarıyla geçirecektir. Büyük programlarda statik doğrulamayı da önemli ölçüde hızlandıracaktır, çünkü tüm kaynaklar belleğe okunmayacaktır. Elbette böyle bir doğrulanmanın sonucu, kendi şartlarına göre değerlendirilmelidir.

--keychain filename İmzalama sırasında, imzalama kimliğini yalnızca belirtilen anahtar zinciri (keychain) dosyasında arar. Bu, kullanıcının arama listesindeki birkaç anahtar zincirinde benzer adlara sahip birden fazla kimliğiniz varsa, eşleşen bağları çözmek için kullanılabilir. İmzaya gömülen sertifika zinciri oluşturulurken standart anahtar zinciri arama yoluna yine de başvurulduğunu unutmayın. Belirtilen dosya adının, kullanıcının anahtar zinciri arama listesinde de yer almadığı sürece, imzalama kimliğinin sertifika zincirini çözmek için aranmayacağını unutmayın.

--prefix string Açık bir benzersiz tanımlayıcı belirtilmemişse (-i seçeneği kullanılarak) ve örtük olarak oluşturulan tanımlayıcı nokta (.) karakteri içermiyorsa, verilen dize kullanılmadan önce tanımlayıcının önüne eklenir. Örtük tanımlayıcı bir nokta içeriyorsa olduğu gibi kullanılır. Genellikle bu, varsayılan tanımlayıcısı yalnızca komutun dosya adı olan, Info.plist dosyası bulunmayan komut araçlarıyla başa çıkmak için kullanılır; kullanılan geleneksel önek com.domain. şeklindedir (sondaki noktanın açıkça belirtilmesi gerektiğine dikkat edin).

--preserve-metadata=list Zaten imzalanmış olan kodu yeniden imzalar iken, eski imzadan bazı bilgileri yeniden kullanır. Yeni veriler açıkça belirtilirse tercih edilir. İmzaların üzerine yazılmasını etkinleştirmek için yine de -f (--force) seçeneğini belirtmeniz gerekir. Bu seçenek yoksa, herhangi bir eski imzanın imzalama işlemi üzerinde hiçbir etkisi yoktur. Not: Önceki ikili dosyada linker-signed bayrağı varsa, bu seçenek yoksayılır. Bu seçenek, makul şekilde kısaltabileceğiniz virgülle ayrılmış adlar listesini alır:

identifier Varsayılan bir tanımlayıcı oluşturmak yerine imzalama tanımlayıcısını (--identifier) korur.

entitlements Yetkilendirme verilerini (--entitlements) korur.

requirements Açıkça Belirlenmiş Gereksinim (Designated Requirement) dahil olmak üzere dahili gereksinimleri (--requirements seçeneği) korur. Tüm dahili gereksinimlerin bir bütün olarak korunduğunu veya yeniden oluşturulduğunu unutmayın; bu seçenekle tek tek öğeleri seçip ayıramazsınız.

flags Seçenek bayraklarını (-o) korur, aşağıdaki SEÇENEK BAYRAKLARI bölümüne bakın.

runtime Sürümü geçersiz kılmak veya türetmek yerine korumalı çalışma zamanı (hardened runtime) sürümünü (-o runtime bayrağı, --runtime-version seçeneği) korur.

launch-constraints binary üzerinde ayarlanmış mevcut başlatma kısıtlamalarını kaldırmak yerine korur. --launch-constraint-* seçeneklerinden herhangi biri ayarlanmışsa bu seçenek yoksayılır.

library-constraints binary üzerinde ayarlanmış mevcut kütüphane yükleme kısıtlamalarını kaldırmak yerine korur. --library-constraint seçeneği ayarlanmışsa bu seçenek yoksayılır. Tarihsel nedenlerden dolayı, --preserve-metadata seçeneği bir değer olmadan da verilebilir ve bu durum şu anda bilinen tüm bu değerleri korur. Bu kullanım artık önerilmemektedir ve gelecekte kaldırılacaktır; her zaman korunacak öğelerin açık bir listesini belirtin.

--strict options Kodu doğrular iken, varsayılanların ötesinde ek kısıtlamalar uygular.

symlinks Kod paketi içindeki sembolik bağların (symbolic links), paketin içindeki mühürlü dosyalara işaret edip etmediğini kontrol eder. Bu, bozuk sembolik bağların yanı sıra paketin dışındaki yerlere ve herhangi bir nedenle imza tarafından mühürlenmemiş yerlere yapılan bağların reddedileceği anlamına gelir.

sideband İmzalı kodda kaynak çatalları (resource forks), Finder öznitelikleri veya benzer yan bant (sideband) verilerinin bulunmadığını kontrol eder. Bu artık imzalama işlemleri tarafından otomatik olarak zorunlu kılınmaktadır. Seçenekler virgülle ayrılmış bir liste olarak belirtilebilir. Mümkün olduğunca katı olmak için düz --strict veya --strict=all kullanın. --strict=all seçeneğinin zamanla daha fazla kontrol türü içerebileceğini unutmayın. Tüm katılık kontrolleri her durumda mantıklı olmayabilir, bu nedenle bu davranışlar varsayılan değildir.

--timestamp [=URL] İmzalama sırasında, imzalama zamanını doğrulamak için bir zaman damgası yetkilendirme (timestamp authority) sunucusuyla iletişim kurulmasını talep eder. İletişim kurulan sunucu URL değeriyle verilir. Bu seçenek bir değer belirtilmeden verilirse Apple tarafından sağlanan varsayılan bir sunucu kullanılır. Bu sunucunun, Apple tarafından sağlanmayan kimliklerle yapılan imzaları desteklemeyebileceğini unutmayın. Zaman damgası yetkilendirme hizmetine internet üzerinden erişilemezse, hizmet arızalanırsa veya hizmeti reddederse imzalama işlemi başarısız olur. Bu seçenek hiç verilmezse, sisteme özgü varsayılan bir davranış tetiklenir. Bu, bazı kod imzalarının zaman damgalı olmasıyla, bazılarının ise olmamasıyla sonuçlanabilir. Özel none değeri, zaman damgası hizmetlerinin kullanımını açıkça devre dışı bırakır.

--runtime-version version İmzalama sırasında, runtime SEÇENEK BAYRAĞI ayarlandığında, kod imzasında saklanan korumalı çalışma zamanı (hardened runtime) sürümünü açıkça belirtir. Bu seçenek atlanırsa ancak runtime SEÇENEK BAYRAĞI ayarlanmışsa, korumalı çalışma zamanı sürümü Mach-O olmayan dosyalar için atlanır ve Mach-O dosyalarının SDK sürümünden türetilir.

--launch-constraint-self path İmzalama yaparken, verilmedi yoldaki dosyayı alır ve içeriğini bu yürütülebilir dosyada bir başlatma kısıtlaması (launch constraint) olarak imzaya gömer. Yol üzerindeki dosya, istenen başlatma kısıtlaması koşullarını ifade eden bir plist içermelidir. Başlatma kısıtlaması karşılanmadığı sürece bu yürütülebilir dosya başlatılamaz.

--launch-constraint-parent path İmzalama yaparken, verilen yoldaki dosyayı alır ve içeriğini bu yürütülebilir dosyanın ebeveyninde bir başlatma kısıtlaması olarak imzaya gömer. Yol üzerindeki dosya, istenen başlatma kısıtlaması koşullarını ifade eden bir plist içermelidir. Ebeveyni bu başlatma kısıtlamasını karşılamadığı sürece bu yürütülebilir dosya başlatılamaz.

--launch-constraint-responsible path İmzalama yaparken, verilen yoldaki dosyayı alır ve içeriğini bu yürütülebilir dosyanın sorumlu sürecinde (responsible process) bir başlatma kısıtlaması olarak imzaya gömer. Yol üzerindeki dosya, istenen başlatma kısıtlaması koşullarını ifade eden bir plist içermelidir. Sorumlu süreci bu başlatma kısıtlamasını karşılamadığı sürece bu yürütülebilir dosya başlatılamaz.

--library-constraint path İmzalama yaparken, verilen yoldaki dosyayı alır ve içeriğini bu sürecin yükleyebileceği kütüphaneler üzerinde bir kısıtlama olarak imzaya gömer. İşletim sistemi kütüphaneleri bu mekanizma ile kısıtlanamaz. Yol üzerindeki dosya, istenen kısıtlama koşullarını ifade eden bir plist içermelidir. Bu yürütülebilir dosya, belirtilen koşulları karşılamayan kütüphaneleri yüklemeyecektir.

--strip-disallowed-xattrs İmzalama yaparken, kod imzalamaya müdahale edebilecek xattr'leri (örneğin com.apple.FinderInfo ve com.apple.ResourceFork) ayıklar. İzin verilmeyen bir xattr ile karşılaşılırsa, codesign döküntü (detritus) varlığından şikayet edecek ve sorunlu dosyanın yolu ile xattr'si ayrıntılı olarak günlüğe kaydedilecektir.

--single-threaded-signing İmzalama yaparken, kaynak mührünü (resource seal) oluşturmak için tek bir iş parçacığı (thread) kullanır.

--validate-constraint Yol(lar) tarafından belirtilen kısıtlama plist'lerinin yapısal olarak geçerli olduğunu ve yalnızca bu işletim sistemi sürümünde bilinen anahtarları veya $optional işleci ile düzgün şekilde sarılmış anahtarları içerdiğini doğrular. Bir hata oluşursa bir hata mesajı yazdırılır.

Operation

İlk özet (synopsis) biçiminde codesign, sağlanan kimliği kullanarak verilen yollardaki kod nesnelerini imzalamaya çalışır. Talep edilirse dahili gereksinimler ve yetkilendirmeler gömülür. Belirtilmeyen dahili gereksinimlere uygun varsayılan değerler atanabilir. Varsayılan atama her dahili gereksinim türüne ayrı ayrı uygulanır. Bir tanımlayıcı açıkça verilirse, tüm yollara mühürlenir. Aksi takdirde, her yol tanımlayıcısını kendi Info.plist dosyasından veya yol adından bağımsız olarak türetir. Paket dizinlerinin içinde yer alan kodlar önceden imzalanmış olmalıdır, aksi takdirde imzalama işlemi başarısız olur; ancak --deep seçeneği verilmişse, devam etmeden önce imzasız iç içe geçmiş kodlar aynı imzalama seçenekleri ve parametreleri kullanılarak özyinelemeli olarak imzalanır. Eğer --force seçeneği verilirse, mevcut olan --preserve-metadata seçeneklerine bağlı olarak mevcut herhangi bir üst düzey imza değiştirilir. --force ve --deep seçeneklerinin birleştirilmesi, hedef paket içindeki tüm imzaların zorla değiştirilmesiyle sonuçlanır.

İkinci özet biçiminde codesign, verilen tüm yollardaki kod imzalarını doğrular. Doğrulama, bu yollardaki kodun imzalı olduğunu, imzanın geçerli olduğunu ve tüm mühürlü bileşenlerin değiştirilmemiş olduğunu onaylar. Bu durumda geçerli olmak, imzanın yapısal ve kriptografik olarak sağlam olduğu anlamına gelir. Bir gereksinim verilirse, her yol bu gereksinime göre de kontrol edilir (ancak aşağıdaki DIAGNOSTICS bölümüne bakın). Ayrıntılı doğrulama talep edilirse, program kendi belirlenmiş gereksinimine göre de kontrol edilir; bu kontrol düzgün şekilde imzalanmış bir program için asla başarısız olmamalıdır.

Not: Doğrulama/geçerleme, imzayı işletim sistemi politikasına göre kontrol etmez. Geçerli/doğrulanmış bir imza, Gatekeeper, Yetkilendirmeler (Entitlements) veya diğer bağlamsal politika gereksinimlerini karşılamada yine de başarısız olabilir.

Bir yol ondalık bir basamakla başlıyorsa, sistemde çalışan bir sürecin süreç kimliği (process id) olarak yorumlanır ve bunun yerine o süreç üzerinde dinamik doğrulama gerçekleştirilir. Bu, kodun dinamik durumunu ve nominal güvenlik zarfını kapatmaya yetecek kadar statik veriyi kontrol eder. Tam bir statik kontrol gerçekleştirmek için en az bir ayrıntı düzeyi (verbosity) ekleyin.

Üçüncü özet biçiminde codesign, verilen yollardaki imzaların içeriğini görüntüler. Ayrıntı düzeyi arttıkça daha fazla bilgi görüntülenir. Bu biçim, yollardaki imzaları tamamen doğrulamayabilir; ancak yollar hakkında bilgi edinme sürecinde bazı doğrulama adımlarını gerçekleştirebilir. -r path seçeneği verilirse, dahili gereksinimler yollardan çıkarılır ve yola yazılır; standart çıktıya yazmak için bir tire "-" belirtin. Kod açıkça belirlenmiş bir gereksinim içermiyorsa, örtük olan gereksinim alınacak ve bir kaynak yorumu olarak yazılacaktır. Eğer --entitlements path seçeneği verilirse, gömülü yetkilendirme verileri de aynı şekilde çıkarılacak ve belirtilen dosyaya yazılacaktır.

Dördüncü özet biçiminde codesign, verilen her bir pid için barındırma yolunu (hosting path) oluşturur ve bunu her satırda bir ana bilgisayar olacak şekilde standart çıktıya yazar. Barındırma yolu, çalıştığı bilinen en özel kodla başlayan ve güven kökü (çekirdek) ile sona eren kod imzalama barındırıcıları zinciridir. Eğer --verbose seçeneği verilirse, her bir barındırıcının dinamik geçerlilik durumu da yoldan bir sekme (tab) karakteri ile ayrılarak görüntülenir. Barındırma zincirlerinin zaman zaman geçersiz veya imzasız kodlar için bile oluşturulabileceğini ve codesign komutunun bu biçiminin çıktısının resmi bir kod geçerliliği beyanı olarak kabul edilmemesi gerektiğini unutmayın. Bunu yalnızca codesign --verify yapabilir; ve aslında, resmi doğrulama işlemi kendi operasyonunun bir parçası olarak barındırma zincirini oluşturur (ancak görüntülemez).

Beşinci özet biçiminde codesign, sağlanan yolları doğrular. Doğrulama, anahtarların ve işleçlerin uygun türlerle düzgün şekilde yapılandırıldığından ve tüm anahtarların ile işleçlerin bilindiğinden ya da $optional işleci içinde yuvalandığından emin olmak anlamına gelir.

Signing Identities

Kod imzalamak için kullanılacak dijital kimliğin, çağıran kullanıcının anahtar zinciri arama listesinde bulunan bir anahtar zincirinde (keychain) saklanması gerekir. Düzgün yapılandırılmışsa tüm anahtar zinciri kaynakları desteklenir. Özellikle, desteklenen bir akıllı kart üzerinde saklanan bir kimlikle kod imzalamak mümkündür. Eğer imzalama kimliğiniz farklı bir biçimde saklanıyorsa, onunla kod imzalamak için onu anahtar zinciri biçiminde kullanılabilir hale getirmeniz gerekir. Eğer --keychain argümanı kullanılırsa, kimlik yalnızca verilen özel anahtar zincirinde aranır. Bu, kimliklere yapılan atıflardaki belirsizlikleri gidermeye yardımcı olmak içindir. Bu durumda bile, imzayı tamamlamak için gereken ek sertifikalar için tam anahtar zinciri arama listesine yine de başvurulur.

Kimlik öncelikle bir anahtar zinciri kimlik tercihinin (keychain identity preference) tam adı olarak değerlendirilir. Böyle bir tercih varsa, doğrudan kullanılan kimliği adlandırır. Aksi takdirde kimlik, konusu ortak adı (common name) yalnızca verilen kimlik dizesini içeren bir sertifika için tüm anahtar zincirleri aranarak bulunur. Birden fazla eşleşme varsa işlem başarısız olur ve hiçbir imzalama yapılmaz; ancak kısmi eşleşme yerine tam eşleşme tercih edilir. Bu karşılaştırmalar büyük/küçük harfe duyarlıdır. Birden fazla anahtar zincirinde tamamen aynı sertifikanın birden fazla örneğinin bulunması zararsız kabul edilir.

Kimlik tam olarak kırk onaltılık (hexadecimal) basamaktan oluşuyorsa, bunun yerine istenen kimliğin sertifika kısmının SHA-1 karması (hash) olarak yorumlanır. Bu durumda kimliğin konu adı dikkate alınmaz.

Hem kimlik tercihleri hem de sertifika karmaları, adından bağımsız olarak belirli bir imzalama kimliğini tanımlamak için kullanılabilir. Kimlik tercihleri her kullanıcı için genel ayarlardır ve bir dolaylılık katmanı sağlar. Sertifika karmaları ise çok açık ve yereldir. Bu seçenekler, Xcode projesine ve hedef derleme değişkenlerine ve/veya betik ayarlarına yerleştirilenlerle birleştiğinde imzalama kimliklerinin çok esnek bir şekilde belirlenmesini sağlar.

Kimlik tek bir "-" (tire) harfi ise, ad-hoc imzalama gerçekleştirilir. Ad-hoc imzalama hiçbir kimlik kullanmaz ve kodun tam olarak tek bir örneğini tanımlar. Ad-hoc imzalı kodun kullanımında önemli kısıtlamalar geçerlidir; bunu kullanmadan önce belgelere danışın.

codesign, oluşturduğu kod imzasına, herhangi bir ara sertifika ve çıpa (anchor) sertifikası dahil olmak üzere imzalama kimliğini belgeleyen tüm sertifika zincirini gömmeye çalışacaktır. Bunları, imzalama işlemini gerçekleştiren kullanıcının anahtar zinciri arama listesinde arar. Sertifika zincirinin tamamını oluşturamazsa imzalama yine de başarılı olabilir, ancak doğrulayan kodun eksik sertifikalar için (kendi anahtar zincirlerinden) bağımsız bir kaynağı yoksa doğrulama başarısız olabilir.

Specifying Requirements

Gereksinim(ler) argümanları (-r ve -R) çeşitli biçimlerde verilebilir. Düz metin bir argüman, gereksinim(ler)i içeren bir dosyanın yolu olarak kabul edilir. codesign, hem düzgün şekilde derlenmiş gereksinim kodunu içeren ikili dosyaları hem de kullanılmadan önce otomatik olarak derlenen kaynak dosyalarını kabul edecektir. "-" argümanı, gereksinim(ler)in standart girdiden okunmasını talep eder. Son olarak, bir eşittir işareti "=" ile başlayan argüman, hazır bir gereksinim kaynak metni olarak kabul edilir ve kullanım için buna göre derlenir.

Option Flags

İmzalama yaparken, imzalanmış kod kullanılırken sistemin davranışını değiştirmek için bir dizi seçenek bayrağı belirtilebilir. Aşağıdaki bayraklar codesign tarafından tanınır; API düzeyinde başka bayraklar da mevcut olabilir. Seçenek adlarının bir listesi yerine (tek bir) sayısal değer vererek de herhangi bir geçerli bayrağı belirtebileceğinizi unutmayın.

kill Kod yürütülmeye başladığında imzalanan kodun kill bayrağının ayarlanmasını zorunlu kılar. Kill bayrağı ayarlanmış kod, dinamik olarak geçersiz hale geldiğinde sonlandırılır (die). Bu nedenle, bu şekilde işaretlenmiş kodun, bir kez doğrulandıktan sonra hayatta olduğu sürece geçerli bir kimliğe sahip olmaya devam edeceğini varsaymak güvenlidir.

hard Kod yürütülmeye başladığında imzalanan kodun hard bayrağının ayarlanmasını zorunlu kılar. Hard bayrağı, sisteme, kodun erişim sağlamasının kimliğini geçersiz kılacağı durumlarda kaynaklara erişiminin reddedilmesini tercih ettiğine dair bir ipucudur.

host Kodu, misafir kodu (guest code) barındırabilecek kapasitede olarak işaretler. Kodun alt ("misafir") kodu kontrol eden bir kod imzalama barındırıcısı (host) gibi davranmasını istiyorsanız bu seçeneği ayarlamanız gerekir. Dahili bir misafir gereksinimi belirtirseniz bu bayrak otomatik olarak ayarlanır.

expires Kodun herhangi bir doğrulamasının, ilgili sertifikaların sona erme tarihlerini dikkate almasını zorunlu kılar. Bu bayrakla oluşturulan kod imzaları, doğrulayıcının niyetinden bağımsız olarak, zincirdeki sertifikalardan herhangi birinin süresi dolduğunda doğrulanamaz. Bu bayrağın, sertifika iptal kontrolleri de dahil olmak üzere imza doğrulamasının başarısız olmasına neden olabilecek diğer kontrolleri etkilemediğini unutmayın.

library Kod yürütülmeye başladığında imzalanan kodun kütüphane doğrulama (library validation) bayrağının ayarlanmasını zorunlu kılar. Kod yalnızca sistem kütüphanelerine ve framework'lerine veya kod dizininde gömülü aynı ekip tanımlayıcısına (team identifier) sahip kütüphanelere, framework'lere ve eklenti paketlerine bağlanabilecektir. Ekip tanımlayıcıları, uygun Apple tarafından verilmiş imzalama sertifikalarıyla imzalama yapıldığında imzalara otomatik olarak kaydedilir. Bu bayrağın i386 ikili dosyaları için desteklenmediğini ve yalnızca ana yürütülebilir dosyaya uygulandığını unutmayın. Bayrağın, framework'ler ve kütüphaneler üzerinde ayarlandığında hiçbir etkisi yoktur.

runtime macOS sürümü >= 10.14.0 olan sistemlerde, imzalı süreçleri, çalışma zamanı kod imzalama zorlaması, kütüphane doğrulaması, hard, kill ve hata ayıklama kısıtlamalarını içeren korumalı bir çalışma zamanı (hardened runtime) ortamına dahil eder. Bu kısıtlamalar yetkilendirmeler (entitlements) aracılığıyla seçici olarak gevşetilebilir. Not: 10.14.0'dan eski macOS sürümleri, kod imzasındaki bu bayrağın varlığını yoksayar.

linker-signed Bir imzanın bağlayıcı (linker) tarafından imzalandığını tanımlar. Bağlayıcı imzaları aşağıdaki durumlar hariç ad-hoc imzalara çok benzer:

• bağlayıcı imzaları --force seçeneği kullanılmadan değiştirilebilir.

• bağlayıcı imzaları, --preserve-metadata seçeneğinin kullanımından bağımsız olarak asla korunmaz.

• bağlayıcı imzaları genellikle belirlenmiş bir gereksinim (designated requirement) dahil olmak üzere gömülü kod gereksinimleri içermez.

Kodun kendi üzerinde hard ve kill bayraklarını istediği zaman ayarlayabileceğini unutmayın. İmzalama seçenekleri yalnızca bunların başlangıç durumunu etkiler. Herhangi bir yolla bir kez ayarlandıktan sonra, bu bayraklar kodun ömrü boyunca temizlenemez. Bu nedenle, bu tür bayrakların imzalama seçenekleri olarak belirtilmesi, imzalanan kod her çalıştığında bunların ayarlanacağını garanti eder.

İmzalanan kod, CSFlags adlı bir anahtar içeren bir Info.plist dosyasına sahipse, o anahtarın değeri seçenekler için varsayılan değer olarak kabul edilir. CSFlags değeri, --options seçeneğiyle aynı biçimde bir dize veya mutlak sayısal değeri belirten bir tamsayı olabilir. Ancak, komut satırlarında bayrak adlarını kısaltabilseniz de, Info.plist içinde bunları açıkça yazmanız gerektiğini unutmayın.

Examples

     Terminal.app uygulamasını "authority" adlı imzalama kimliğiyle imzalamak için:
	   codesign --sign authority Terminal.app

     "helper" komut satırı aracını aynı kimlikle imzalamak, mevcut tüm imzaların üzerine yazmak,
     "com.mycorp.helper" imzalama tanımlayıcısını kullanmak ve özel olarak belirlenmiş bir gereksinimi gömmek için:
	   codesign -f --sign authority --prefix=com.mycorp. -r="designated => anchor /tmp/foo" helper

     Terminal.app üzerinde korumalı çalışma zamanını etkinleştirmek ve "authority" adlı imzalama kimliğiyle imzalamak için:
	   codesign --sign authority --options runtime Terminal.app

     Terminal.app üzerindeki imzayı doğrulamak ve bazı ayrıntılı çıktılar üretmek için:
	   codesign --verify --verbose Terminal.app

     666 sürecinin dinamik geçerliliğini doğrulamak için:
	   codesign --verify +666

     Terminal.app uygulamasının kod imzası hakkındaki tüm bilgileri görüntülemek için:
	   codesign --display --verbose=4 Terminal.app

     Terminal.app uygulamasından standart çıktıya dahili gereksinimleri çıkarmak için:
	   codesign --display -r- Terminal.app

     Bir ikili dosyanın veya paketin yetkilendirmelerini görüntülemek için:
	   codesign --display --entitlements - /sbin/launchd
	   codesign --display --entitlements - --der Terminal.app

     666 sürecinin yetkilendirmelerini görüntülemek için:
	   codesign --display --entitlements - +666

     1337 sürecinin XML yetkilendirmelerini görüntülemek için:
	   codesign --display --entitlements - --xml +1337

     Terminal.app uygulamasını gömülü bir başlatma kısıtlaması ve gömülü bir kütüphane kısıtlamasıyla imzalamak için:
	   codesign --sign authority --launch-constraint-self self-constraint.plist --library-constraint library-constraint.plist Terminal.app

     İmzalamadan önce bir dizi kısıtlama dosyasını doğrulamak için:
	   codesign --validate-constraint self-constraint.plist library-constraint.plist

Troubleshooting

codesign kullanırken yaygın bir kafa karışıklığı kaynağı, komut satırı seçeneklerinin sıralanmasından kaynaklanır. Eğer codesign beklendiği gibi davranmıyorsa, bu kılavuza danışın ve argümanlarınızın sıralamasını kontrol edin. Genel bir kural olarak codesign, eylem-nesne kuralını takip eder. Örneğin çağrıda --sign, --options seçeneğinden önce yer almalıdır. Bunun nedeni, verilen bir seçenek kümesiyle bir "imzalama" (sign) eylemi gerçekleştiriyor olmanızdır.

Bunlar tersine çevrilirse ve çağrıda --options, --sign seçeneğinden önce sağlanırsa, --options değeri sessizce yoksayılır.

Diagnostics

codesign, tüm işlemler başarılı olursa 0 değeriyle çıkar. Bu, tüm kodların imzalandığını veya tüm kodların talep edildiği gibi düzgün bir şekilde doğrulandığını gösterir. Bir imzalama veya doğrulama işlemi başarısız olursa çıkış kodu 1 olur. Çıkış kodu 2, geçersiz argümanları veya parametreleri belirtir. Çıkış kodu 3, doğrulama sırasında tüm yolların düzgün şekilde imzalandığını ancak bunlardan en az birinin -R seçeneğiyle belirtilen gereksinimi karşılamada başarısız olduğunu belirtir.

Doğrulama için, program çıkmadan önce tüm yol argümanları her zaman incelenir. Diğer tüm işlemler için program, karşılaşılan ilk hatada çıkar ve --continue seçeneği belirtilmediği sürece diğer tüm yol argümanları yoksayılır; bu seçenek belirtilmişse codesign, tüm yol argümanlarını sırasıyla işlemeyi deneyene kadar başarısızlık çıkışını erteler.

Signing Atomicity

Belirli bir kod için imzalama işlemi başarısız olduğunda, kod gerekli imza verileri eklenerek belirli şekillerde zaten değiştirilmiş olabilir. Bu tür bilgiler kodun çalışmasını değiştirmeyecektir ve bu parçalar yerinde olsa bile kod imzalı sayılmayacaktır. İmzalama işlemini sorunsuz bir şekilde tekrarlayabilirsiniz. Ancak, -f seçeneğini belirttiyseniz önceki geçerli bir imzanın fiilen yok edilmiş olabileceğini unutmayın. codesign tarafından sağlanandan daha katı bir imzalama bölünmezliği (atomicity) istiyorsanız, kodunuzun açık bir kopyasını oluşturup onu imzalamanız gerekir.

Environment

Eğer CODESIGN_ALLOCATE ortam değişkeni ayarlanmışsa, Mach-O ikili dosyalarında kod imzaları için alan tahsis etmek üzere kullanılan yedek bir codesign_allocate aracını tanımlar. Bu, Xcode SDK dağıtımları tarafından iPhone'lar gibi yerel olmayan platformlar için mimari destek sağlamak amacıyla kullanılır. Sistem, özel olarak imzalanmadıkları sürece (Apple tarafından) bu tür yedekleri kabul etmeyecektir.

Files

/var/db/DetachedSignatures İmzasız kodlar için ayrılmış kod imzalarının sistem genelindeki veritabanı.

See Also

csreq(1), xcodebuild(1), codesign_allocate(1)

History

codesign komutu ilk olarak Mac OS 10.5.0 (Leopard) sürümünde ortaya çıkmıştır.

Bugs

Bazı seçenekler yalnızca belirli işlemlere uygulanır ve bunları anlamı olmayan bir işlem için belirtirseniz codesign bunları (şikayet etmeden) yoksayar.

--preserve-metadata seçeneği eskiden hiçbir değer almıyordu ve tam olarak neyi koruduğu sürümler arasında farklılık gösteriyordu. Geriye dönük uyumlu betikler yazmanız gerekiyorsa, bunun getirdiği kafa karışıklığı hala geçerlidir.

Hem ayrıntı düzeyini (verbosity) hem de doğrulamayı (verification) belirten -v seçeneğinin ikili anlamı bazı kişilerin kafasını karıştırmaktadır. Kafa karıştırıcı buluyorsanız, bunun yerine açık olan uzun biçimler --verbose yards ve --verify seçeneklerini kullanın.

--verify seçeneği bir dosya veya bir pid alabilir. Dosya yolunuz bir sayıyla başlıyorsa, codesign aracının argümanı bir yol olarak yorumlamasını zorunlu kılmak için önüne "./" eklemelisiniz. Örneğin: codesign --verify 666 şu şekle dönüşmelidir: codesign --verify ./666

Notes

CODE_SIGN_IDENTITY derleme değişkeni ayarlanmışsa Xcode derleme sistemi codesign aracını otomatik olarak çağırır. Oradaki ek derleme değişkenleriyle herhangi bir codesign seçeneği kombinasyonunu ifade edebilirsiniz.

codesign temelde kod imzalama API'leri etrafında bir kabuktur ve altta yatan işlerin hiçbirini gerçekleştirmez. Onu daha eski veya daha yeni sürümlerle değiştirmek yararlı bir etki oluşturmayacaktır.

codesign, deneysel olmaları (ve her an değişebilmeleri) veya tedbirsiz kişilere tavsiye edilmemeleri nedeniyle bu kılavuz sayfasında bilerek belgelenmemiş birkaç işleme ve seçeneğe sahiptir. Meraklı olanların yayınlanan kaynak koda bakmaları tavsiye edilir.

macOS 26.4 May 7, 2011 macOS 26.4