Yıllardır Maç’inde PowerShell kullananların yaşadığı o meşhur sahne var. Yeni bir kurulum yapıyorsun, .pkg dosyasını indiriyorsun, çift tıklıyorsun ve… maalesef. macOS bir anda sürat asıyor: “Bu uygulama tanımlanamayan bir geliştiriciden.” Sonra sağ tık, “Aç”, sistem ayarlarına gir, “Yine de aç” butonuna baş, parolayı yaz, biraz da içinden geçir. Tarball indirdiysen bu kez xattr -d com.apple.quarantine ile karantinayı kaldırman gerekiyordu — işin aslı baya uğraştırıcıydı.
Neyse ki o kısım geride kaldı. Microsoft, PowerShell 7.4 ve üzeri sürümler için macOS paketlerini Apple tarafından notarize edilmiş ve hardened hâle getirdi. Yani artık Gatekeeper’a tek tek açıklama yapmıyorsun. Açık konuşayım — topluluğun en çok beklediği düzeltmelerden biriydi bu, hem de 14’ten fazla GitHub issue’şunu tek seferde kapatıyor.
Notarization Aslında Ne Demek?
Bunu teknik jargonla boğmadan anlatayım. Apple’ın notarization süreci, kabaca “Apple’ın uygulamana bakıp bunda bariz bir kötülük yok” demesi gibi çalışıyor. Geliştirici paketi hazırlar, Apple’ın sunucusuna yollar, sistem içeriği tarar (zararlı kod var mı, imza sağlam mı, başka bir tuhaflık çıkıyor mu diye), her şey yolundaysa bir notary ticket döner. O bilet de uygulamaya iliştirilir.
Hmm, bunu nasıl anlatsamdı…
Şöyle ki, Sonra ne oluyor? Kullanıcı uygulamayı açınca macOS Apple’a soruyor: “Bu şey güvenilir mi?” Apple da “evet, ben onayladım” derse Gatekeeper kenara çekiliyor. Kısacası olay bu.
Hardened runtime işe biraz başka kulvar (buna dikkat edin). Bu yapı, uygulama çalışırken hangi yetkilere sahip olacağını sıkı kurallara bağlıyor. Mesela “bu process’e dışarıdan kod enjekte edilemesin” ya da “imzasız kütüphane yüklenemesin” gibi entitlement’lar devreye giriyor. Yani Apple sana aslında şunu söylüyor: “Notarize olmak istiyorsan oyuncak gibi davranma.”
Bir müşterimizde geçen yıl tam da bu yüzden PowerShell otomasyonu kuramamıştık. DevOps ekibi tamamen MacBook’tan çalışıyordu, kurumsal MDM politikası “unidentified developer” uygulamalarını blokluyordu. Notarize olmayan PowerShell paketini her makinede tek tek exception’a aldırmamız gerekti. Tam bir baş ağrısı.
Sahada Bu Değişiklik Ne Anlama Geliyor?
Bireysel Kullanıcılar İçin
Eğer Maç’inde PowerShell kullanan bir geliştirici, sistem yöneticisi ya da DevOps mühendisiysen — kısaca hiçbir şey yapmana gerek yok. Bir sonraki bakım sürümünü indiriyorsun, kuruyorsun, bitti gidiyor. Sağ tıkla aç, karantina kaldır, şu butona baş… bunların hepsi yavaş yavaş tarih oluyor. Ben kendi M2 MacBook’umda preview build’i denedim; çift tıkla kuruluyor. İlk denemede insanın omuzları gevşiyor resmen.
Kurumsal Ortamlar İçin
Asıl fark burada çıkıyor ortaya. Jamf, Intune veya Kandji gibi bir MDM çözümüyle Maç filosu yönetiyorsan hayatın baya kolaylaşıyor çünkü:
- Notarize edilmiş paketler MDM’in “approved app” listelerine sorunsuz giriyor
- Gatekeeper bypass policy’si yazmana gerek kalmıyor
- Compliance raporlarında “unsigned binary” uyarısı çıkmıyor
- End-user’lara “şuraya tıkla, parolanı gir” diye dört sayfalık döküman göndermiyorsun
Logosoft’ta hizmet verdiğimiz bir sigorta şirketinde yaklaşık 200 MacBook vardı. Geçen ay bu konuyu masaya yatırdık — IT direktörü direkt sordu: “PowerShell’i fleet-wide deploy edemiyoruz, notarize değil çünkü. Ne yapacağız?” O zaman cevabım netti ama kısa sürdü: Microsoft tarafına ticket açılmıştı, bekliyorduk. Şimdi işe rahatım.
Notarization’ın Teknik Tarafı: Ne Değişti?
Yani, Microsoft’un build pipeline’ına bakınca işin iki ayağı var gibi duruyor. Birinçisi signing, ikincisi notarization. PowerShell ekibi muhtemelen aşağı yukarı buna benzer bir akış kullanıyordur (kendi build script’lerime bakınca böyle tahmin ediyorum):
# Önce binary'leri Developer ID ile imzala
codesign --force --options runtime \
--entitlements PowerShell.entitlements \
--sign "Developer ID Application: Microsoft Corporation" \
/path/to/pwsh
#.pkg installer'ı imzala
productsign --sign "Developer ID Installer: Microsoft Corporation" \
PowerShell-unsigned.pkg PowerShell-signed.pkg
# Apple'a notarization için gönder
xcrun notarytool submit PowerShell-signed.pkg \
--apple-id "build@microsoft.com" \
--team-id "UBF8T346G9" \
--password "@keychain:AC_PASSWORD" \
--wait
# Notary ticket'ı pakete iliştir (stapling)
xcrun stapler staple PowerShell-signed.pkgStapling kısmı önemli; çünkü internet yokken bile macOS ticket’ı paketin içinde bulup doğrulayabiliyor. Yani offline kurulum yapan biri ya da VPN arkasında izole çalışan kullanıcı bile boşuna uğraşmıyor.
Tarball İçin Permission Düzeltmesi
Bir detay daha var, önü atlamayayım: tarball içindeki dosya izinleri de düzeltilmiş durumda. Eskiden .tar.gz‘i açtıktan sonra chmod +x ile manuel olarak çalıştırılabilir hâle getirmek gerekebiliyordu — özellikle bazı CI/CD senaryolarında bunu defalarca gördüm. Şimdi paket içinde permission bit’leri doğru set ediliyor. Küçük gibi duruyor ama otomasyon yazıyorsanız bilirsiniz; böyle ufak şeyler üst üste binince can sıkıyor.
Bunu Türkiye’deki Şirketler Açısından Değerlendirelim
Bakın, Türkiye’de kurumsal dünyada Maç kullanımı son 5-6 yılda baya arttı. En çok da de fintech ekipleri, — itiraz edebilirsiniz tabi — yazılım ajansları ve yeni nesil bankacılık startupları neredeyse tamamen Maç’e kaydı diyebilirim. Ama gerçek şu ki bizim IT departmanlarında hâlâ biraz Windows-first refleksi var; yani Maç için ayrı politika yazmak yerine çoğu yerde “Maç de Windows policy’siyle yürüsün” gibi pek işlemeyen beklentiler görüyoruz.
Hani, Bu güncellemeyle birlikte özellikle Azure Files Entra-Only: AD’siz SMB Devri Başladı yazısında konuştuğumuz hibrit yapılarda — yani hem AD’ye bağlı Windows makineler hem de MDM ile yönetilen Maç’ler varsa — PowerShell tabanlı script çalıştırmak çok daha rahat hâle geliyor. Mesela bir storage automation script’i düşün; artık hem Windows admin’in hem de Maç kullanan developer’ın aynı şekilde çalıştırabildiği ortak bir araca dönüşüyor.
Vallahi, KOBİ tarafında tablo biraz farklı tabii. Küçük ekiplerde MDM yoksa ve signed installer’ları manuel kuruyorsan zaten Gatekeeper etrafından dolaşmanın yollarını biliyordun büyük ihtimalle. Ama büyük kurumdaysan ve InfoSec ekibin “unsigned binary asla” diyorsa, bu güncelleme sana somut fayda sağlıyor. Compliance raporunda bir satır eksiliyor; küçük ama sevindirici.
Karşılaştırma: Önceki Durum vs Şimdi
| Senaryo | Eski Durum | Yeni Durum (7.4+) |
|---|---|---|
| İlk kurulum (GUI) | Gatekeeper uyarısı, sağ tık + Aç | Çift tık, bitti |
| Tarball ile kurulum | xattr -d com.apple.quarantine gerekli |
Doğrudan çalışıyor |
| MDM deployment | Manuel exception policy | Standart approved app |
| Permission bit’leri | Bazen chmod +x şart |
Otomatik doğru set ediliyor |
| InfoSec compliance | “Unsigned binary” alarmı | Apple Notary onaylı |
Peki Eksik Olan Bir Şey Var Mı?
Kısacası, açık konuşayım — her şey güllük gülistanlık değil ha; birkaç nokta hâlâ kafamı kurcalıyor.
Birinci mesele şu: Bu değişiklik sadece Microsoft’un resmî .pkg ve tarball dağıtımı için geçerli görünüyor (ki bu çoğu kişinin gözünden kaçıyor). Eğer işleri hızlandırmak için Homebrew üzerinden gidip brew install --cask powershell kullanıyorsan, cask formülünün güncellenmesini beklemen gerekebilir. Homebrew tarafı genelde hızlıdır ama yine de arada küçük bir geçiş süresi ölür.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili C# 16 Unsafe Yeniden Doğuyor: Bellek Güvenliğinde Yeni Çağ yazımıza da göz atmanızı tavsiye ederim.
İkinci nokta hardened runtime ile gelen kısıtlar. Mesela DTrace ile PowerShell process’ını incelemek isteyen düşük seviye debugging yapan birkaç arkadaş vardı; onların bazı alışkanlıkları entitlement yüzünden eskisi kadar rahat olmayabilir diye düşünüyorum. Çoğu kullanıcı bunu hissetmez ama performans araştırması yapan biriysen ufak bir geri adım sayılabilir. Bu konuyla ilgili Python Agent Skills: Üç Yöntem, Tek Provider Se… yazımıza da göz atmanızı tavsiye ederim.
Bence,
Bu konuyla ilgili MCP Sunucuları İçin Yönetişim: .NET’e Yeni Toolkit Geldi yazımıza da göz atmanızı tavsiye ederim.
<
Dördüncü ve bence en kritik konu işe şu: Bu güncelleme sadece
Pratik Geçiş Rehberi: Adım Adım Ne Yapmalısınız?
Şimdi gelelim asıl mevzuya. Diyelim ki elinizde bir Maç filosu var ve PowerShell güncellemesi yapacaksınız. İlk adım olarak şunları yapın:
- Mevcut sürümü kontrol edin: Terminal’de
pwsh --versionkomutuyla bakın.7..4 ‘ ün altındaysa upgrade planlayın. - Test grubu oluşturun:5 -10 kişilik pilot grup seçin. Bunlar tipik geliştirici/sysadmin profili olsun.
- MDM policy ‘ lerini gözden geçirin: Daha önce PowerShell için yazdığınız Gatekeeper exception ‘ ları varsa, artık gereksiz. Temizleyin — bunlar attack surface ‘ i artırıyor.
- Otomasyon script ‘lerinizi test edin: Özellikle
xattrkullanan deployment script ‘ leri varsa, bunlar artık unutulmuş kod hâline geldi. Çıkarın. - Dökümantasyonu güncelleyin: Onboarding rehberlerinizde “PowerShell kurulumu” bölümünü sadeleştirin. End-user’a5 adım yerine1 adım sunun.
Bence evet, hem de fazlasıyla. Microsoft’un PowerShell tarafında son dönemde ciddi olgunlaşma var. Şunu hatırlayın — PowerShell Core ilk çıktığında(2016 falandı), Maç ve Linux desteği biraz “biz de varız ” havasındaydı. Çalışıyordu ama kurumsal kullanım için tam pişmemişti. Şimdi notarization, hardened runtime, düzgün permission yönetimi… Bunlar artık ciddi platform sinyalleri.
Hatta şunu söyleyeyim: AZ -104 ve AZ -400 sınavlarına hazırlanırken cross-platform PowerShell senaryolarına ne kadar yer verildiğine dikkat etmiştim. Eski sınavlarda neredeyse hiç yoktu, son revize edilen müfredatlarda artık net olarak Maç ve Linux üzerinden Azure yönetimi soruluyor. Yani Microsoft kendi sertifikasyon tarafından da bu yöne gidiyor.
Tabii bu, “Microsoft Maç’i Windows kadar iyi destekleyecek ” anlamına gelmiyor. Hâlâ bazı modüller(eski Active Directory cmdlet ‘leri, bazı RSAT araçları) sadece Windows’ta çalışıyor (yanlış duymadınız). Ama günlük DevOps işleri, Azure yönetimi, Graph API çağrıları — bunların hepsi artık Maç’te native experience seviyesinde. Bu da bir Azure danışmanı olarak benim için çok önemli, çünkü müşteri görüşmelerinde MacBook’um’u açtığımda artık ekstra adım atmıyorum.
Sıkça Sorulan Sorular
Notarize edilmiş PowerShell hangi macOS sürümlerinde çalışıyor?
PowerShell 7.4 ve üzeri, yani Apple’ın hâlâ desteklediği macOS Big Sur (11) ve üstünde sorunsuz çalışıyor. Apple Silicon (M1/M2/M3) ve Intel Maç’ler için ayrı paketler var, bence bu ayrımı gözden kaçırmamak önemli. Daha eski bir macOS’ünüz varsa upgrade etmeniz gerekiyor.
Mevcut kurulumumu manuel güncellemem gerekiyor mu?
Hayır. Aslında otomatik bir geçiş yok ama bir sonraki bakım sürümünü kurduğunuzda zaten notarize edilmiş paketi alıyorsunuz. Homebrew kullanıyorsanız brew upgrade --cask powershell komutu yeterli; hani tek uyarı şu: cask güncellemesi Microsoft’un resmî sürümünden birkaç gün geride kalabiliyor.
Eski script’lerimde xattr komutları var, bunları çıkarmalı mıyım?
Evet, kesinlikle çıkarın. Artık gereksizler. Üstelik açıkçası bu tür kalıntılar kod tabanında gereksiz soru işaretleri bırakıyor; mesela yeni gelen ekip arkadaşları “bu neden burada?” diye soruyor. Onboarding süreci gereksiz yere uzuyor. Temiz kod adına silin gitsin.
Çok konuştum, örnekle göstereyim.
Hardened runtime PowerShell modüllerimi etkiler mi?
Çoğu modül için sorun yok. Yani etkilenenler genellikle düşük seviyeli native binary çağıran, runtime’da kod injection yapan ya da unsigned dynamic library yükleyen modüller oluyor. Tecrübeme göre üretim öncesi test ortamında kendi modüllerinizi bir gözden geçirmeniz yeterli (yanlış duymadınız)
MDM ile dağıtımda ek bir ayar gerekiyor mu?
Şöyle söyleyeyim, Hayır, gerekmiyor. Notarize edilmiş paketler Jamf, Intune, Kandji gibi MDM çözümlerinin standart “trusted developer” politikalarına otomatik olarak giriyorlar. Microsoft’un Developer ID Team ID’sını (UBF8T346G9) allow list’inize. Tahmin eder mısınız? Eklediyseniz, aslında yapmanız gereken başka bir şey yok (ki bu çoğu kişinin gözünden kaçıyor)
Kaynaklar ve İleri Okuma
PowerShell is now notarized and hardened for macOS – PowerShell Team Blog
Install PowerShell 7 on macOS – Microsoft Learn
Notarizing macOS Software Before Distribution – Apple Developer Documentation
Bunu yaşayan biri olarak söyleyeyim, PowerShell GitHub Releases – Resmî Sürüm Notları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
