Tailscale durum dosyası şifreleme özelliği varsayılan ayarda devre dışı bırakıldı

• Tailscale v1.92.5 sürümünde Linux ve Windows istemcilerindeki durum dosyası şifreleme (state file encryption) ve donanım doğrulama anahtarı özelliği varsayılan olarak devre dışı bırakıldı
• TPM aygıtı sıfırlansa veya değiştirilse bile istemci normal şekilde başlatılıyor; donanım doğrulama anahtarının yüklenememesi çalışmayı engellemiyor
• Tailscale container image içinde donanım doğrulama anahtarı artık Kubernetes durum Secrets nesnelerine eklenmiyor; böylece container başka bir node'a taşınabiliyor
• Tailscale Kubernetes Operator, sertifika yenilemelerinde varsayılan olarak artık ARI sipariş yöntemini kullanmıyor ve donanım doğrulama anahtarını Secrets içinde saklamıyor
• Bu değişiklik, Tailscale'in güvenlik özelliklerini yapılandırma biçimini sadeleştiren ve farklı ortamlardaki dağıtım esnekliğini artıran bir güncelleme niteliğinde

---

Tailscale v1.92.5 güncellemesi

• Linux ve Windows istemcileri

  • Secure node state storage ile ilgili özellikler arasında durum dosyası şifreleme ve donanım doğrulama anahtarı varsayılan olarak devre dışı bırakıldı
  • TPM (Trusted Platform Module) aygıtı sıfırlansa veya değiştirilse bile istemcinin başlatılması engellenmiyor

• Tailscale container image

  • Yeni sürüm Docker Hub ve GitHub Packages üzerinden sunuluyor
  • Donanım doğrulama anahtarı Kubernetes durum Secrets nesnelerine eklenmediği için Tailscale container'ı başka bir Kubernetes node'una taşınabiliyor

• Tailscale Kubernetes Operator

  • Yeni sürüm, kurulum kılavuzu izlenerek dağıtılabiliyor
  • Sertifika yenilemelerinde ARI sipariş yöntemi varsayılan olarak kullanılmadığından, ACME hesap anahtarı yeniden oluşturulduğunda oluşabilecek yenileme hataları önleniyor
  • Donanım doğrulama anahtarı Kubernetes durum Secrets nesnelerine eklenmediği için Operator başka bir node'a taşınabiliyor

• Tailscale tsrecorder

  • Yeni sürüm Docker Hub üzerinden sunuluyor
  • Bu sürümde yalnızca kütüphane güncellemeleri var, işlev değişikliği yok

5 Ocak 2026 — Workload Identity Federation API

• Tailscale API, federated identities oluşturma, görüntüleme, düzenleme ve silme işlemlerini destekliyor
• Aynı özellikler tailscale-client-go-v2 ve Tailscale Terraform provider üzerinden de yapılandırılabiliyor

23 Aralık 2025 — GitHub Action v4.1.1

• Tailscale GitHub Action, macOS tabanlı GitHub Runner üzerinde cache kaydetme ve geri çağırma sırasında doğru mimariyi kullanacak şekilde düzeltildi

[joyfui]

Şey, sanırım kısa süre önce bununla ilgili bir yardımcı araç paylaşan birinin yazısını görmüştüm...

[GN⁺]

Hacker News yorumları

• Ben, Tailscale'de node state encryption özelliğini ilk uygulayan mühendisim (@awly on Github). Bu kez 1.92.5 sürümünde varsayılanı kapatma kararı aldık.
  Diğer yorumlarda tahmin edildiği gibi, bu özelliğin destek yükü çok fazla. Başlangıçta TPM sıfırlanırsa veya değiştirilirse bunu koşulsuz olarak kurcalama kabul edip istemcinin çalışmayı reddetmesi için tasarlamıştık. Ama pratikte TPM'in kötü niyetli olmayan nedenlerle kararsız olduğu birçok durum vardı.
  Örnek olarak issue 17654, issue 18288, issue 18302 var.
  TPM, bir kuruluş ekipmanlarını iyi kontrol edebildiğinde harika bir araç, ancak Tailscale gibi çeşitli ortamlardaki cihazları desteklemek zorunda olan bir hizmet için fazla karmaşık. Bu yüzden şimdilik bunu güvenliğe duyarlı kullanıcıların veya yöneticilerin kendilerinin etkinleştirmesine bıraktık. Changelog'a bu bağlamı daha fazla koymalıydık; bu konuda üzgünüm
  • Bağlantı verilen issue'ları okuyunca şaşırdım. TPM sorunlarının sadece eski donanımlarda ya da özel ortamlarda olacağını sanıyordum, ama Dell XPS ve çeşitli VM'lerde de oluyormuş.
    Tailscale örneklerimin çoğunu VM ve container üzerinde çalıştırıyorum; gerçekten TPM şifrelemesi uygulananlar yalnızca ana PC'm, iPhone'um ve Linux sunucusunun host'u olmuş. VM'lerde ve container'larda hiç çalışmadı, dizüstü bilgisayarım da muhtemelen desteklemeyecek kadar eski
  • Politikanın oldukça makul olduğunu düşünüyorum. Açıkladığın için teşekkürler
  • issue 17654'te bir kullanıcı “TS_ENCRYPT_STATE=false” ayarıyla da çözülmediğini söylemiş, ama sonraki 1.92.1 sürümünde sorunun kaybolduğunu belirtmiş.
    Bu tür bir durumda bunun gerçekten state encryption sorunu mu, yoksa başka bir neden mi olduğu konusunda biraz daha açıklama yapabilir misin diye merak ediyorum
  • Ben de TPM'e güveniyordum ama tek bir BIOS güncellemesi TPM'i tamamen sıfırladı. O zamandan beri TPM'e bağımlı olmamaya karar verdim
  • Bu kadar dürüstçe açıkladığın için teşekkürler. Changelog'da buna benzer bir arka plan bilgisinin biraz olsun yer alması iyi olurdu.
    Durum karmaşıksa, kısa bir blog yazısı ile ayrıca toparlaman da memnuniyetle karşılanır
• Bu özellik en başta varsayılan olarak etkin olmamalıydı. Yöneticinin TPM kullanmayı açıkça seçmesi gerekirdi.
  Changelog'da da yazdığı gibi, TPM sıfırlanırsa veya değiştirilirse donanım kimlik anahtarı yüklenemediği için istemcinin başlamaması sorunu vardı.
  Birçok dağıtım ortamında bu özellik gerçekten gerekli, ancak Tailscale çok farklı OS ve cihazlarda çalıştığı için öngörülemez çakışmalar çok fazlaydı
  • TPM'i şifreleme amacıyla kullanmaya çalıştığım her seferinde sonunda kurtarma parolası veya yedek anahtar ihtiyacı doğuyor. Ama bu da TPM'in amacını baştan anlamsızlaştırıyor.
    Küçük bir hatayla kullanıcının anahtarları tamamen kaybolabilir; bu yüzden pratikte kullanması zor geliyor
  • Windows varsayılan olarak TPM kullanmıyor mu? Öyleyse milyonlarca Windows kullanıcısının sorun yaşaması gerekirdi.
    Bu yüzden bu biraz aşırı tepki gibi görünüyor. Bazı TPM istisna durumları yüzünden tüm özelliğin kapatılması üzücü.
    Bir ara aşama (ör. isteğe bağlı etkinleştirme) olsaydı iyi olurdu
  • TPM sıfırlanırsa veya değiştirilirse engellemenin, aslında fiziksel saldırılara karşı savunma açısından doğru davranış olup olmadığı sorusu akla geliyor
• Bu PR'da devre dışı bırakma nedeni açıklanıyor.
  TPM kalitesindeki değişkenlik çok büyük olduğu için çeşitli sorunlara yol açtığı söylenmiş
• Changelog'a bakınca, varsayılan etkinleştirmenin yol açtığı sorunlar nedeniyle böyle yapılmış gibi görünüyor (içeriden bilgim yok).
  Yine de bu sorun çözülürse yeniden varsayılan olarak etkinleştirmeyi planlayıp planlamadıklarını merak ediyorum.
  Tailscale ekibine güveniyorum ama gözetim endişelerinin arttığı bu dönemde, böyle bir değişikliğin devlet talebi nedeniyle olmadığını net bir gerekçeyle duymak isterim
  • Sorunun kaynağının Tailscale değil, TPM donanımının kendisinin kararsızlığı olduğunu düşünüyorum.
    Bu yüzden bu özelliğin yalnızca kontrollü ortamlarda seçmeli olarak kullanılması gerektiği görüşündeyim
• Eski donanımdaki bir NixOS makinesinde Tailscale sürekli çöküyordu ve nedenini bilmiyordum; bu değişiklik sayesinde sebebi öğrenmiş oldum. TPM şifrelemesinden kaynaklanıyormuş
• Sanırım destek talepleri çok arttığı için devre dışı bıraktılar
• Son bir aydır Tailscale sürekli bozuluyordu; bugün çıkan yama bu sorunu çözdü.
  Sebep bir BIOS güncellemesiydi ve sonrasında Tailscale “Starting” durumunda takılı kalıyor, hiçbir hata da göstermiyordu
• Ben USB'ye kurulu bir Linux'u masaüstü ve dizüstü bilgisayar arasında dönüşümlü olarak açıyorum; bir gün aniden Tailscale çalışmamaya başladı.
  Bunun sadece bana özgü tuhaf bir durum olduğunu sanıyordum, ama TPM tabanlı şifrelemenin başka nedenlerle de başarısız olabildiğini öğrenmiş oldum
• Linux'ta /etc/default/tailscaled içine FLAGS="--encrypt-state" ekleyince oluyor gibi görünüyor.
  Log'da "migrated ... to TPM-sealed format" mesajı görünüyor, yani düzgün çalışıyor gibi
• İşte bu yüzden kitlesel pazarda %1 oranında bile bozulan bir özellik varsayılan yapılamaz.
  Sonunda en düşük ortak paydaya uymak zorundasınız ve kusursuz güvenlikten ziyade önce kararlılık tercih ediliyor.
  Ben Tailscale'i işletiyor olsaydım, “TPM'i bozulanlar bunu kendileri düzeltsin; biz varsayılan olarak güvenliği koruyacağız” diyebilirdim.
  Ama Avery'nin bu kararı vermek için nedenleri olduğunu anlıyorum