GitHub HTTPS’te SHA-1’i Emekliye Ayırıyor: Ne Değişecek?

Şöyle söyleyeyim, Açık konuşayım: SHA-1’in TLS tarafında hâlâ bir yerlerde nefes alıyor olması, benim için bile ufak bir sürpriz oldu. Geçen hafta bir müşteriyle — büyük bir sigorta şirketinin altyapı ekibiyle — görüşürken GitHub’dan gelen duyuruyu paylaştım. Ekipten biri “abi SHA-1 zaten 2017’de ölmemiş miydi?” dedi. Haklıydı aslında. Sertifika imzalama tarafında çoktan gömülmüştü. Ama TLS handshake sırasında kullanılan imza algoritmaları listesinde hâlâ bir köşede, sessiz sakin duruyordu.

İtiraf edeyim, İşte o köşe de kapanıyor. GitHub 14 Temmuz 2026’da brownout başlatacak, 15 Eylül 2026’da ise SHA-1’i tamamen kapatıyor — hem github.com hem de partner CDN’ler için (ilk duyduğumda inanamadım). Hadi gelin, bu iş ne anlama geliyor, kimi etkiliyor, Türkiye’deki kurumsal ekipler ne yapmalı, hepsini tek tek konuşalım. Peki neden şimdi? Çünkü geciktikçe iş büyüyor, o kadar basit.

Tam Olarak Ne Kapatılıyor?

Şöyle bir yanlış anlaşılma olmasın: Git commit hash’lerinden bahsetmiyoruz. O ayrı mesele, o kendi başına başka bir konu (GitHub Git tarafında SHA-256’ya geçiş planlarını ayrıca yürütüyor). Burada konuştuğumuz şey sadece ve sadece HTTPS/TLS katmanında SHA-1 imzalı algoritma desteği. Kafa karıştırıyor, evet.

Yani bir istemci GitHub’a HTTPS ile bağlandığında, TLS handshake sırasında “ben şu imza algoritmalarını destekliyorum” diye bir liste gönderiyor. Eğer o listede sadece SHA-1 varsa — ki çok eski sistemlerde hâlâ böyle — GitHub “kusura bakma, seninle konuşamam” diyecek. O kadar. Basit gibi duruyor. Değil; çünkü arka tarafta kaç tane eski agent, kaç tane unutulmuş script var, insan bazen şaşırıyor (yanlış duymadınız)

Etkilenen yerler:

• github.com üzerinden siteyi açan tarayıcılar — bunu es geçmeyin
• GitHub API’sini kullanan neredeyse tüm yazılımlar, botlar, CI pipeline’ları
• HTTPS üzerinden push/pull yapan Git istemcileri
• GitHub Enterprise Cloud (Data Residency dahil)

Şöyle söyleyeyim, Etkilenmeyen: GitHub Enterprise Server. Yani kendi sunucunuzda çalıştırdığınız kurumsal kurulum bu değişiklikten muaf. Bu iyi haber — çünkü regüle sektörlerde (banka, telekom, kamu) GHES hâlâ epey yaygın.

Takvim Net Ama Önemli Bir Detay Var

Brownout kavramını bilmeyenler için şöyle anlatayım: Elektrik kesintisi gibi düşünün. Tamamen kapatmadan önce kısa süreliğine kapatıp “bakın, kapatıyoruz, hazır mısınız?” diye uyarı veriliyor (buna dikkat edin). GitHub’ın brownout planı da tam olarak buna benziyor; biraz sert ama dürüstçe söylüyorlar işi.

Tarih	Ne Oluyor?	Süre
14 Temmuz 2026	Brownout — SHA-1 geçici olarak kapatılır	00:00 – 18:00 UTC (18 saat)
15 Eylül 2026	Kalıcı kapatma — SHA-1 tamamen gider	Sonsuza kadar

Hani, Bir detay daha var: Brownout sadece github.com’u etkiliyor, CDN’leri etkilemiyor. Kalıcı kapatmada ise CDN’ler de dahil oluyor. Yani Temmuz’daki test sizin CI pipeline’ınızda release assets indirmeyi tam anlamıyla sınamaz — onlar genelde CDN’den geliyor. Mantıklı değil mi? Eylül’ü beklemeyin demiyorum; ama asıl kırılma orada olacak gibi duruyor.

Evet, doğru duydunuz.

Peki Kimler Gerçekten Etkilenecek?

Bakın, Dürüst olayım — modern bir sistemdeyseniz, büyük ihtimalle hiçbir şey hissetmeyeceksiniz. Son 5-6 yılda çıkan her şey SHA-256 ve üzerini zaten destekliyor. Ama işte o “büyük ihtimalle” kelimesi var ya (yanlış duymadınız). asıl mesele orada dönüyor.

Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de durum biraz karışık; çünkü hâlâ üretimde CentOS 6, Ubuntu 14.04, hatta Windows Server 2008 R2 çalışan sistemler görüyoruz. Geçen yıl bir bankada (söylemesi ayıp) tam olarak böyle bir tabloyla karşılaştık — eski bir jump server üzerinden deployment yapılıyordu, üzerinde OpenSSL 1.0.1 vardı (ilk duyduğumda inanamadım). O sunucudan GitHub’a bağlantı patlayacak mı? Evet, patlayacaktı.

Ve işler burada ilginçleşiyor.

Risk Altındaki Tipik Senaryolar

Kendi deneyimimden listeleyeyim; çünkü bu tür konularda teorik liste pek işe yaramıyor: .NET MAUI 11’de Harita Pin Kümeleme: Pratik Rehber yazımızda bu konuya da değinmiştik.

1. Eski Jenkins sunucuları: 2017-2018’den kalma Jenkins master’ları, özellikle Java 7 veya eski Java 8 ile çalışanlar. Git plugin HTTPS üzerinden repo çekerken takılabilir.
2. Legacy build agent’lar: Windows Server 2012 üzerindeki build ajanları..NET Framework 4.5 ve altı TLS 1.2 için özel ayar gerektiriyor; SHA-256 desteği de otomatik gelmiyor.
3. Eski mobil cihazlar: Android 7 öncesi, iOS 11 öncesi cihazlar. Dev ekip telefonundan GitHub mobil açmaya çalışıyorsa dertlenir.
4. Python 2.7 ile yazılmış otomasyon scriptleri: Evet, biliyorum, Python 2 emekli oldu ama cron’da hâlâ çalışan ne çok script var, insan şaşırıyor açıkçası.
5. Git for Windows’un çok eski versiyonları: 2.20 öncesi kritik sayılır; OpenSSL backend’i eski kalıyor.

Benim kişisel tahminim: Türkiye’de etkilenecek sistemlerin %70’i “unutulmuş” build sunucuları olacak. Kimse dokunmuyor, çalışıyor sanılıyor, kimse log okumuyor; sonra Eylül’de sessizce tökezleyecekler.

Hazırlık İçin Pratik Adımlar

İşin aslı şu ki test etmek çok basit görünüyor ama küçük bir ayrıntı yüzünden saç baş yoldurabiliyor da. GitHub bunun için ön cephe hazırlamış: github.dev. Bu subdomain’de SHA-1 zaten kapalı. Yani yapmanız gereken tek şey — tarayıcınızdan, CI agent’ınızdan ya da script’inizden — oraya bağlantı denemek. Açılıyorsa fena değil; en azından yarın sabah sürpriz yaşamazsınız. Bu konuyla ilgili .NET Nisan 2026 Güvenlik Güncellemeleri: CVE Analizi yazımıza da göz atmanızı tavsiye ederim.

Komut Satırından Hızlı Test

Ben genelde şöyle test ediyorum; kendi kayıtlarımdan paylaşayım:

# Sunucunun desteklediği TLS imza algoritmalarını görmek için
openssl s_client -connect github.com:443 -sigalgs 'RSA+SHA256:RSA+SHA384:ECDSA+SHA256' </dev/null
# Eski SHA-1 ile bağlanmayı denemek (başarısız olmalı ileride)
openssl s_client -connect github.dev:443 -sigalgs 'RSA+SHA1' </dev/null
# Git istemci versiyonu
git --version
# 2.30+ rahatsınız, 2.20 altı tehlike
# Curl versiyonu ve TLS backend
curl --version

Eğer github.dev‘e bağlanırken “handshake failure” veya “no shared signature algorithms” hatası alıyorsanız — hoş geldiniz, iş var demektir. Şey gibi düşünün; sorun hemen görünmez ama köşede bekliyordur.

Enterprise Ekipler İçin Envanter Stratejisi

Büyük bir kurumdaysanız 200 kişilik dev ekibi tek tek dolaşacak haliniz yok tabii ki. Ben müşterilere genelde şu sırayı öneriyorum; biraz sıkıcı ama işe yarıyor:

Önce CI/CD altyapısını tara. Çünkü sorun orada çıkarsa production deployment ölür ve işin rengi değişir. Jenkins, GitLab Runner, Azure DevOps self-hosted agent, TeamCity — ne varsa listele; her biri için OS versiyonu, Git versiyonu ve OpenSSL/Schannel versiyonunu çıkarın (evet parantez içinde söyleyeyim). Bu envanter Temmuz brownout’undan önce bitmeli.

Sonra otomasyon scriptleri. Bilhassa de API kullanan botlar burada öne çıkıyor ama yanlış yere bakmayın; webhook alıcıları değil bunlar çünkü onlar GitHub’dan gelen trafiği alıyor. Etkilenmezler. Asıl dert giden trafikte: release notlarını çeken scriptler, issue sync eden araçlar, Dependabot benzeri custom çözümler… Bunlar bazen yıllarca el değmeden yaşıyor.

Kısa bir not düşeyim buraya.

Neyse uzattım biraz ama son adım daha kolay geliyor: geliştirici makineleri. Bu aslında en rahat kısım çünkü geliştiriciler çoğu zaman kendi aletlerini güncel tutuyor (tamam hepsi değil). Sadece kısa bir duyuru ve net bir kontrol listesi yeterli oluyor (ben de ilk duyduğumda şaşırmıştım) Daha fazla bilgi için Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımıza bakabilirsiniz.

Türkiye’deki Kurumlar İçin Özel Notlar

İnanın, Kendi pazarımıza dönelim biraz da burada iş daha yavaş akıyor açıkçası. Türkiye’deki kurumsal müşteri profilim şunu gösteriyor: regüle sektörlerde (BDDK, SPK, EPDK’ye bağlı kurumlar) değişiklik yönetimi ağır ilerliyor; bazen sinir bozucu derecede ağır bile diyebilirim (inanın bana). Bir Git istemcisini güncellemek bile üç ay sürebiliyor çünkü önce güvenlik ekibi onaylayacak, sonra değişiklik komitesi toplanacak, sonra pilot yapılacak… sonra da yaygınlaştırma geliyor.

Bu yüzden benim tavsiyem net: Temmuz brownout’unu beklemeyin. Mart-Nisan 2026’da envanter çıkarmaya başlayın derim ben. Çünkü hazırlık sadece “güncelleme yap” demek değil; test var, onay var, değişiklik penceresi var, rollback planı var… Hepsi vakit yiyor ve insan bunu çoğu zaman son anda fark ediyor.

Ayrıca şu da var: GitHub Status Sayfası Yenilendi: Şeffaflık Dönemi Başladı yazımda anlattığım gibi GitHub artık incident ve bakım bildirimlerini daha detaylı paylaşıyor. Temmuz brownout’unda olası sorunları takip etmek için bir kişi görevlendirin derim; ciddiyim bu konuda.

Küçük Ekip vs Kurumsal: Kim Ne Yapmalı?

Ayrımı burada yapmak lazım çünkü çözüm aynı değil hiç değilse ben öyle görüyorum.

5-10 kişilik startup’taysanız: (ciddiyim)

İnanın, Epey rahatsınız aslında.Herkes muhtemelen macOS ya da yeni Ubuntu kullanıyor,Git güncel,curl güncel,VS Code güncel.Tek yapmanız gereken github.dev‘e herkesin bağlanabildiğini kısa bir grup mesajıyla teyit etmek.10 dakikalık iş.

50-200 kişilik orta ölçek şirketteyseniz:

);

p

Sıkça Sorulan Sorular

Git commit hash’lerim etkilenir mi?

Hayır, etkilenmiyor. Bu değişiklik aslında sadece HTTPS/TLS katmanıyla ilgili, yani ağ iletişimi kısmı. Commit hash’leriniz, tag’leriniz, Git’in içsel SHA-1 kullanımı bunların hiçbiri bu işten nasibini almıyor. O tamamen ayrı bir konu — bence biraz kafa karıştırıcı bir isimlendirme, ama GitHub’ın o için de ayrı bir yol haritası var zaten.

GitHub Enterprise Server kullanıyorum, ne yapmam lazım?

Aslında bu değişiklik sizi doğrudan etkilemiyor, duyuruda da açıkça yazıyor bunu. Ama şunu sormak lazım: GHES’inizden github.com’a replikasyon veya sync yapıyor musunuz, mesela GitHub Connect gibi? O bağlantı etkilenebilir (ciddiyim). Tecrübeme göre bu tür şeyleri insanlar genelde atlar. Underlying OS ve OpenSSL versiyonunuzu bir kontrol edin, o kadar.

Ve işler burada ilginçleşiyor.

github.dev’e bağlanamıyorum, ne yapayım?

Önce hangi istemciyi kullandığınıza bakın. Tarayıcıysa son sürüme güncelleyin — Chrome 90+, Firefox 90+, Safari 14+ sorunsuz çalışıyor. Git istemcisiyse 2.30+ versiyona geçmeniz yeterli. Otomasyon scripti kullanıyorsanız iş biraz daha uzuyor: altta yatan TLS kütüphanesini güncellemek gerekiyor, yani OpenSSL 1.1.1+, LibreSSL 3.0+ ya da Schannel için Windows Server 2016+ (en azından benim deneyimim böyle)

Brownout’ta CI pipeline’ım çökerse ne yapmalıyım?

Brownout 14 Temmuz 2026, 00:00-18:00 UTC arası — Türkiye saatiyle 03:00-21:00 ediyor. Pipeline’ınız o saatlerde çalışacaksa ya o günü manuel olarak atlayın ya da build agent’larınızı önceden güncelleyin. Açıkçası brownout’un amacı tam da bu zaten, sizi uyandırmak. Çökerse Eylül’deki kalıcı kapanışa hazır değilsiniz demektir — ki o daha kötü.

Windows Server 2016 SHA-256 destekliyor mu?

Evet, Schannel üzerinden TLS 1.2 ve SHA-256 imza algoritmalarını tam destekliyor. Sorun yani asıl sıkıntı Windows Server 2012 R2 ve öncesinde. 2012 R2’de güncelleme paketleriyle destek ekleyebilirsiniz, ama bence o işletim sistemlerinden artık tamamen çıkmak daha doğru. Zaten 2023’te mainstream support bitti, devam ettirmenin pek mantığı yok.

Kaynaklar ve İleri Okuma

GitHub Changelog — Sunsetting SHA-1 in HTTPS on GitHub (Resmi Duyuru)
Microsoft Learn — TLS Registry Settings (Windows Schannel Yapılandırması)
OpenSSL Documentation — Signature Algorithms Configuration
SHAttered — SHA-1 Collision Saldırısı (Google Research, 2017)