NTLM Git/libcurl'de Sona Eriyor: Azure DevOps Server Ekiplerinin Gerçek Bir Geçiş Planına İhtiyacı Var

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

libcurl’de yaklaşan NTLM kaldırması, teknik görünen ancak aslında organizasyonel olan değişikliklerden biridir. Azure DevOps Server’a Git over HTTPS yolunuz hala NTLM’ye bağlıysa, sorununuz araç değil, kimlik borcudur.

Orijinal kaynak: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft bu konuda sert davranmakta haklıdır. NTLM bilinen kriptografik zayıflıklara sahiptir ve modern bir kurumsal varsayılan olmamalıdır. Tehlikeli kısım, birçok ortamın aslında sessiz SPNEGO geri dönüşüyle NTLM’ye hayatta kalırken Kerberos kullandıklarına inanmalarıdır. Bu yanılsama Eylül 2026’da ortadan kalkar.

Benim görüşüm: buna bir “istemci sürümü” sorunu olarak davranmayın. NTLM bayraklarını yeniden etkinleştirmek, eski Git derlemelerini sabitlemek veya geri dönüşün mevcut kalacağını ummak, uzun vadeli risk taşıyan kısa ömürlü bir geçici çözümdür. Düzeltme stratejiniz düşürme ve geciktirme ise, operasyonel kırılganlığı aktif olarak artırıyorsunuz demektir.

Pratik bir geçiş sırası açık ve ölçülebilir olmalıdır.

İlk olarak, mevcut kimlik doğrulama davranışını şimdi doğrulayın. Gerçek geliştirici ve derleme ajanı bağlamlarında, etki alanı dışı ve uzak ağ yolları dahil, izleme tabanlı kontroller ve bilet önbellek doğrulaması çalıştırın. İkinci olarak, Kerberos’u uçtan uca düzeltin: SPN’ler, DNS takma adları, yük dengeleyici ayarları, delegasyon ve etki alanı denetleyicisi erişilebilirliği. Üçüncü olarak, etki alanına katılmamış veya çalışma grubu senaryolarını erken belirleyin ve Kerberos’un güvenilir hale getirilemediği yerlerde bir SSH şeridi tasarlayın.

Ayrıca sahiplik netliğine ihtiyacınız var. Güvenlik ekipleri politika temellerini tanımlamalı, ancak platform mühendisliği uygulama hazırlığına sahip olmalıdır. Bu, bireysel repo yöneticileri için bir yan görev olamaz. IIS, AD, ağ ucu, CI ajanları ve geliştirici iş istasyonu rehberliği genelinde koordineli değişiklikler gerektirir.

İnce bir risk otomasyondur. Derleme ajanları ve hizmet hesapları, insan kullanıcılar sorunsuz olsa bile, genellikle Kerberos biletlerinin eksik veya geçersiz olduğu bağlamlarda çalışır. Yalnızca etkileşimli geliştirici iş akışlarını test ederseniz, en kritik kırılma noktalarını kaçırırsınız.

Olumlu tarafı gerçektir. Temiz bir şekilde Kerberos veya SSH’ye geçmek yalnızca kırılmayı önlemekle kalmaz, saldırı yüzeyini azaltır ve kimlik kontrollerini modern uyum beklentileriyle hizalar. Bu geçişe şimdi başlayan ekipler Eylül’ü sıradan bir olay olarak görecek. Bekleyen ekipler, sürüm baskısı altında kimlik doğrulama hatalarını ayıklıyor olacak.

Bu arşivlenecek bir uyarı değil. Karşılık verilmesi gereken bir son tarihtir.

Pull request'leri Visual Studio içinde incelemek tam da sevdiğim türden bir friksiyon azaltma

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinalini buradan okuyabilirsiniz.

Browser code review workflow’ünün çok büyük bir kısmını çok uzun süredir alıp götürüyor.

Bu yüzden Visual Studio’nun IDE içinde uçtan uca pull request review tarafına daha da ilerlediğini görmek beni çok mutlu ediyor.

Bu, büyük manşetler üretmeyebilecek ama günlük development’ı gerçekten iyileştirebilecek özelliklerden biri.

Ana değer basit: daha az context switching

Review loop’unuzun bir kısmı IDE’de, bir kısmı browser’da yaşıyorsa friction birikir:

PR’ı başka yerde aç
değişiklikleri bir tool’da incele
daha derin inceleme için solution’a geri dön
comment ya da approve için tekrar geçiş yap

Bu katastrofik değil. Sadece verimsiz.

Visual Studio size aynı çalışma ortamından PR açma, inceleme, yorum yapma, onaylama ve merge etme imkânı verirse, bu gerçek bir productivity win olur.

“checkout yapmadan review” seçeneği özellikle güzel

Özellikle hoşuma giden bir şey, PR branch’ini checkout etmeden review yapabilmek.

Küçük görünebilir ama şunlar için mükemmel:

hızlı review pass’leri
interrupt-driven feedback istekleri
mevcut branch ve local state’i olduğu gibi korumak

Bu, iyi code review araçlarının tam olarak ihtiyaç duyduğu esneklik.

Benim görüşüm

Bu devrimsel bir özellik değil.

Daha iyisi: pratik bir özellik.

Günün büyük kısmını Visual Studio’da geçiren ekipler için PR review desteğini sıkılaştırmak, workflow breaks’i azaltır ve incelemeden aksiyona giden yolu yumuşatır.

Bana göre bu, değerli bir iyileştirme.

Orijinal yazı: Visual Studio’dan çıkmadan pull request review yapın

Git | The .NET Blog

NTLM Git/libcurl'de Sona Eriyor: Azure DevOps Server Ekiplerinin Gerçek Bir Geçiş Planına İhtiyacı Var

Pull request'leri Visual Studio içinde incelemek tam da sevdiğim türden bir friksiyon azaltma

Ana değer basit: daha az context switching

“checkout yapmadan review” seçeneği özellikle güzel

Benim görüşüm