GitHub asenkron birleştirme API'sini açtı: Yoğun depolarda bekleme düzeni değişiyor
1 Ekim genel dağıtımı, otomasyonun talep gönderme ile sonucu takip etme adımlarını ayırıyor.
2 Ekim'de tamamlanan dağıtım, entegrasyonların gizli anahtarları nasıl sakladığını yeniden kontrol etmeyi gerektiriyor.
Duyuru / olay tarihi:

GitHub, 2 Ekim 2026'da GitHub App kurulum tokenlarının yeni biçimine geçişin tamamlandığını açıkladı. Nisan ayında başlayan aşamalı dağıtımın ardından yeni üretilen tokenlar varsayılan olarak stateless biçimi kullanıyor. ghs_ ön eki korunuyor, fakat uzunluk yaklaşık 40 karakterden 520 karaktere çıkıyor. Bu değişiklik, bir entegrasyonun kimlik doğrulama yetkisinden çok, tokenı taşıdığı ve sakladığı yerlerdeki varsayımları ilgilendiriyor. Küçük görünen uzunluk farkı eski sistemlerde somut uyum sorununa dönüşebilir.
Resmî açıklamaya göre izinler, depo kapsamı ve bir saatlik geçerlilik süresi değişmiyor. Token üretme API'sinin yolu da korunuyor. Mayıs tarihli geçiş duyurusu, yeni biçimi denemeye yarayan geçici başlığı açıklamıştı; bu başlığın desteği 30 Kasım 2026'da kaldırılacak. GitHub'ın token oluşturma belgesi temel işleyişi doğruluyor. Eski tokenlar kendi süreleri dolana kadar kullanılabiliyor. Buradan tokenların daha uzun süre geçerli olduğu veya daha geniş erişim kazandığı sonucu çıkarılmamalı.
Mizan'ın değerlendirmesi: Bir gizli anahtarın tam uzunluğunu uygulama mantığına sabitlemek, dış hizmetin biçim değişikliğinde sorun yaratabilir. Token bir veri tabanı alanına, ortam değişkenine veya ağ geçidine uğruyorsa her noktanın kabul ettiği uzunluk önem kazanır. İşlemin başlangıçta doğru token üretmesi, sonraki adımda kesilmediğini garanti etmez. Bu yüzden değişiklik yalnızca ana uygulamada değil, tüm aktarım zincirinde incelenir.
Eski doğrulama kuralları da yeni biçimi reddedebilir. Bir kod parçası yalnızca önceki uzunluğa uyan değeri kabul ediyorsa yetkisi doğru tokenla bile giriş başarısız olabilir. Bunun kullanıcıya görünen sonucu genel bir bağlantı hatasıdır; gerçek neden daha dar bir veri kontrolünde kalabilir. Ekibin hata kayıtlarında hangi aşamanın başarısız olduğunu ayırabilmesi, sorunu kısa sürede açıklamaya yardımcı olacaktır.
Kayıt sistemleri ve gizli bilgi maskeleme kuralları ayrıca ele alınır. Tokenın biçimi değiştiğinde yalnızca eski deseni arayan maskeleme, beklenen korumayı sağlamayabilir. Buradaki mesele yeni tokenı çözümlemek değil, onu hassas bir değer olarak doğru taşımaktır. GitHub, tokenların iç yapısına bağlı varsayımlar yerine dışarıdan kullanılan opak değerler olarak ele alınmasını istiyor. Bu yaklaşım gelecekteki değişikliklerde de entegrasyonun dayanıklılığı açısından anlamlı.
2 Ekim geçişi, geliştirici altyapısındaki küçük sözleşme değişikliklerinin iş sürekliliğini etkileyebileceğini gösteriyor. Ekipler mevcut entegrasyonda tokenın üretildiği, saklandığı ve gönderildiği adımları birlikte kontrol edebilir. Kasım sonundaki geçici başlık takvimi de bu incelemenin zaman boyutunu oluşturuyor. Haber açısından değişen şey erişimin kapsamı değil, kullanılan kimlik değerinin biçimi. Başarılı uyum, sisteme gizli uzunluk varsayımları yerleştirmeden doğru değeri baştan sona taşıyabilmekle sağlanacak.
Kaynak kontrolü: 2026-10-03. Metin yapay zekâ desteğiyle hazırlanmıştır.
■ MİZAN HABER