Tailscale स्टेट फ़ाइल एन्क्रिप्शन डिफ़ॉल्ट सेटिंग में निष्क्रिय

• Tailscale v1.92.5 वर्ज़न में Linux और Windows क्लाइंट्स के लिए state file encryption और hardware authentication key फीचर डिफ़ॉल्ट रूप से निष्क्रिय कर दिए गए हैं
• TPM डिवाइस रीसेट या बदल दिए जाने पर भी क्लाइंट सामान्य रूप से शुरू होगा, और hardware authentication key लोड फ़ेल होने पर execution नहीं रुकेगा
• Tailscale container image में hardware authentication key अब Kubernetes state Secrets में नहीं जोड़ी जाती, इसलिए container को दूसरे node पर शिफ्ट किया जा सकता है
• Tailscale Kubernetes Operator certificate renewal के समय डिफ़ॉल्ट रूप से ARI ordering method का उपयोग नहीं करता, और hardware authentication key को Secrets में स्टोर नहीं करता
• यह बदलाव Tailscale के security features की configuration को सरल बनाता है और अलग-अलग environments में deployment flexibility बढ़ाता है

---

Tailscale v1.92.5 अपडेट

• Linux और Windows क्लाइंट्स

  • Secure node state storage से जुड़े फीचर्स में state file encryption और hardware authentication key डिफ़ॉल्ट रूप से निष्क्रिय कर दिए गए हैं
  • TPM (Trusted Platform Module) डिवाइस रीसेट या बदल जाने पर भी क्लाइंट स्टार्टअप ब्लॉक नहीं होगा

• Tailscale container image

  • नया वर्ज़न Docker Hub और GitHub Packages पर उपलब्ध है
  • hardware authentication key Kubernetes state Secrets में नहीं जोड़ी जाती, इसलिए Tailscale container को दूसरे Kubernetes node पर ले जाया जा सकता है

• Tailscale Kubernetes Operator

  • नया वर्ज़न installation guide के अनुसार deploy किया जा सकता है
  • certificate renewal के समय ARI ordering method डिफ़ॉल्ट रूप से उपयोग नहीं किया जाता, जिससे ACME account key दोबारा बनने पर हो सकने वाली renewal failure से बचाव होता है
  • hardware authentication key Kubernetes state Secrets में नहीं जोड़ी जाती, इसलिए Operator को दूसरे node पर ले जाया जा सकता है

• Tailscale tsrecorder

  • Docker Hub पर नया वर्ज़न उपलब्ध है
  • इस release में सिर्फ library updates शामिल हैं, कोई feature change नहीं है

5 जनवरी 2026 — Workload Identity Federation API

• Tailscale API अब federated identities के creation, retrieval, modification और deletion को support करता है
• tailscale-client-go-v2 और Tailscale Terraform provider में भी यही capabilities configure की जा सकती हैं

23 दिसंबर 2025 — GitHub Action v4.1.1

• Tailscale GitHub Action को ठीक किया गया है ताकि macOS-आधारित GitHub Runner पर cache store और retrieval के दौरान सही architecture का उपयोग हो

[joyfui]

अरे, मुझे लगता है मैंने कुछ समय पहले इससे जुड़ा कोई utility जारी करने वाले किसी व्यक्ति की पोस्ट देखी थी...

[GN⁺]

Hacker News की टिप्पणियाँ

• मैं वह इंजीनियर हूँ जिसने Tailscale में node state encryption फीचर सबसे पहले लागू किया था (@awly on Github). इस बार 1.92.5 वर्ज़न में इसका डिफ़ॉल्ट बंद करने का फ़ैसला किया गया।
  जैसा कि दूसरे कमेंट्स में अनुमान लगाया गया था, यह फीचर support burden बहुत ज़्यादा पैदा कर रहा था। मूल रूप से इसे ऐसे डिज़ाइन किया गया था कि अगर TPM reset हो जाए या बदल दिया जाए, तो उसे हमेशा tampering माना जाए और client चलने से मना कर दे। लेकिन व्यवहार में TPM कई बार गैर-दुर्भावनापूर्ण वजहों से भी अस्थिर निकला।
  उदाहरण के तौर पर issue 17654, issue 18288, issue 18302 हैं।
  TPM तब बेहतरीन टूल है जब कोई संगठन अपने डिवाइसों पर अच्छा नियंत्रण रख सकता है, लेकिन Tailscale जैसी ऐसी सेवा के लिए, जिसे विभिन्न तरह के environments के डिवाइस support करने होते हैं, यह बहुत जटिल है। इसलिए अभी इसे security-sensitive users या admins के लिए manually enable करने के विकल्प के रूप में छोड़ा गया है। changelog में यह संदर्भ और बेहतर तरीके से डालना चाहिए था, उसके लिए खेद है
  • linked issues पढ़कर मैं हैरान रह गया। मुझे लगा था TPM की दिक्कतें सिर्फ़ पुराने हार्डवेयर या खास environments में होंगी, लेकिन यह Dell XPS और कई VM में भी हो रहा था।
    मैं अपनी ज़्यादातर Tailscale instances VM और containers में चलाता हूँ, और वास्तव में TPM encryption सिर्फ़ मेरे मुख्य PC, iPhone, और Linux server के host पर लागू हुआ था। VM या containers में यह बिल्कुल काम नहीं करता था, और मेरा laptop शायद बहुत पुराना था इसलिए support नहीं करता था
  • मुझे यह नीति बहुत ही तर्कसंगत लगती है। समझाने के लिए धन्यवाद
  • issue 17654 में एक user ने कहा था कि “TS_ENCRYPT_STATE=false” setting से भी समस्या हल नहीं हुई, लेकिन बाद की version 1.92.1 में दिक्कत गायब हो गई।
    ऐसे मामले में क्या यह सचमुच state encryption की समस्या थी, या कोई और वजह थी? अगर थोड़ा और समझा सकें तो अच्छा होगा
  • मैं भी TPM पर भरोसा करता था, लेकिन सिर्फ़ एक BIOS update ने TPM को पूरी तरह initialize/reset कर दिया। उसके बाद मैंने TPM पर निर्भर न रहने का फ़ैसला किया
  • इतनी ईमानदारी से समझाने के लिए धन्यवाद। changelog में अगर इस तरह की background थोड़ी भी हो तो अच्छा लगेगा।
    अगर मामला जटिल है, तो एक छोटा blog post अलग से लिख दिया जाए तो वह भी स्वागतयोग्य होगा
• यह फीचर शुरू से ही डिफ़ॉल्ट रूप से enabled नहीं होना चाहिए था। admin को स्पष्ट रूप से चुनना चाहिए कि वह TPM इस्तेमाल करना चाहता है।
  changelog में भी लिखा है कि TPM reset या replace होने पर hardware auth key लोड नहीं हो पाती थी और client start नहीं होता था।
  कई deployment environments में यह फीचर वास्तव में ज़रूरी होता है, लेकिन Tailscale इतने तरह के OS और डिवाइसों पर चलता है कि अनपेक्षित conflicts बहुत ज़्यादा सामने आए
  • जब भी TPM को encryption के लिए इस्तेमाल करने की कोशिश करते हैं, अंत में recovery password या backup key की ज़रूरत पड़ती ही है। लेकिन तब TPM का मूल उद्देश्य ही कमज़ोर पड़ जाता है।
    एक छोटी सी गलती से user की keys पूरी तरह गायब हो सकती हैं, इसलिए व्यवहार में इसे इस्तेमाल करना कठिन लगता है
  • क्या Windows डिफ़ॉल्ट रूप से TPM इस्तेमाल नहीं करता? अगर करता है, तो लाखों Windows users को समस्या आनी चाहिए थी।
    इसलिए यह थोड़ा overreaction जैसा लगता है। कुछ TPM edge cases की वजह से पूरा फीचर बंद कर देना अफ़सोसजनक है।
    कोई बीच का रास्ता होना चाहिए था, जैसे optional enablement
  • अगर TPM reset हो जाए या बदल दिया जाए और तब access block हो, तो क्या यह physical attack defense के नज़रिए से सही behavior नहीं है?
• इस PR में disable करने की वजह समझाई गई है।
  कहा गया है कि TPM quality में बहुत ज़्यादा variance होने से तरह-तरह की समस्याएँ पैदा हुईं
• changelog देखकर लगता है कि दिक्कत डिफ़ॉल्ट enablement की वजह से थी (मेरे पास अंदरूनी जानकारी नहीं है)।
  लेकिन अगर यह समस्या हल हो जाए, तो क्या इसे फिर से डिफ़ॉल्ट रूप से enable करने की योजना है?
  मैं Tailscale टीम पर भरोसा करता हूँ, लेकिन आजकल surveillance concerns बढ़ रहे हैं, इसलिए मैं स्पष्ट कारण सुनना चाहता हूँ कि यह बदलाव कहीं सरकारी दबाव की वजह से तो नहीं है
  • मुझे लगता है समस्या की जड़ Tailscale नहीं बल्कि TPM hardware की अस्थिरता है।
    इसलिए यह फीचर controlled environments में ही selectively इस्तेमाल होना चाहिए
• पुराने हार्डवेयर वाले NixOS machine पर Tailscale लगातार crash हो रहा था और मुझे कारण समझ नहीं आ रहा था, लेकिन इस बदलाव की वजह से अब कारण पता चल गया। वजह TPM encryption थी
• मेरा अनुमान है कि इसे बहुत ज़्यादा support requests की वजह से disable किया गया
• पिछले एक महीने से Tailscale लगातार खराब चल रहा था, और आज आए patch ने वह समस्या ठीक कर दी।
  वजह BIOS update थी, जिसके बाद Tailscale “Starting” स्टेट पर अटका रहता था और कोई error भी नहीं दिखाता था
• मैं USB पर installed Linux को desktop और laptop पर बारी-बारी से boot करता हूँ, और एक दिन अचानक Tailscale ने काम करना बंद कर दिया।
  मुझे लगा था यह सिर्फ़ मेरे case में अनोखी समस्या है, लेकिन अब पता चला कि TPM-based encryption दूसरी वजहों से भी fail हो सकती है
• Linux में /etc/default/tailscaled में FLAGS="--encrypt-state" जोड़ने से यह enable होता दिखता है।
  logs में "migrated ... to TPM-sealed format" message दिख रहा है, इसलिए लगता है सही काम कर रहा है
• इसी वजह से mass market में ऐसा फीचर जिसे 1% cases में भी break होने की संभावना हो डिफ़ॉल्ट नहीं बनाया जा सकता।
  अंत में सबसे कम सामान्य हरजाने वाले स्तर पर आना पड़ता है, और perfect security से ज़्यादा stability को प्राथमिकता देनी पड़ती है।
  अगर मैं Tailscale चला रहा होता, तो शायद कहता, “जिनका TPM टूटा है वे खुद ठीक करें, हम डिफ़ॉल्ट रूप से security बनाए रखेंगे।”
  फिर भी मैं समझता हूँ कि Avery के इस फ़ैसले के पीछे कारण हैं