iTerm2 के लिए महत्वपूर्ण सुरक्षा अपडेट की घोषणा
(iterm2.com)- iTerm2 3.5.11 2 जनवरी 2025 को बिल्ड की गई रिलीज़ है, और SSH Integration से जुड़ी महत्वपूर्ण सुरक्षा सुधार के कारण तुरंत अपडेट करने की सिफारिश की जाती है
- प्रभाव का दायरा SSH Integration फीचर का उपयोग करने वाले 3.5.6~3.5.10 और 3.5.6 के बाद के सभी beta वर्शन उपयोगकर्ताओं पर है
- यदि यह बग होता है, तो input और output रिमोट होस्ट के /tmp/framer.txt में रिकॉर्ड हो जाते हैं, और उसी रिमोट होस्ट के अन्य उपयोगकर्ता इस फ़ाइल को पढ़ सकते हैं
- शर्तें हैं:
it2sshका उपयोग किया गया हो, या प्रोफ़ाइल में Command"SSH"हो और"SSH Integration"चुना गया हो, तथा रिमोट होस्ट के डिफ़ॉल्ट search path में Python 3.7 या उससे ऊपर मौजूद हो - उपयोगकर्ताओं को 3.5.11 में upgrade करने के बाद, प्रभावित रिमोट होस्ट पर
/tmp/framer.txtहटाना चाहिए
प्रभाव का दायरा और होने की शर्तें
- iTerm2 3.5.11 एक ऐसी रिलीज़ है जिसमें महत्वपूर्ण सुरक्षा सुधार शामिल है, और तुरंत अपडेट करने की सिफारिश की जाती है
- जिन वर्शन पर प्रभाव पड़ सकता है, वे SSH Integration फीचर का उपयोग करने वाले निम्न वर्शन हैं
- 3.5.6
- 3.5.7
- 3.5.8
- 3.5.9
- 3.5.10
- 3.5.6 के बाद के सभी beta वर्शन
- यह बग SSH Integration फीचर में input और output को रिमोट होस्ट के
/tmp/framer.txtमें लिख देता है- इस फ़ाइल को रिमोट होस्ट के अन्य उपयोगकर्ता पढ़ सकते हैं
- यह समस्या तब होती है जब निम्न सभी शर्तें सही हों
it2sshकमांड का उपयोग किया गया हो- या
Settings > Profiles > Generalमें Command पॉपअप मेनू"SSH"पर सेट हो, और SSH settings डायलॉग में"SSH Integration"चुना गया हो"Login Shell","Command","Custom Command"सेटिंग्स इस शर्त में शामिल नहीं हैं
- रिमोट होस्ट के डिफ़ॉल्ट search path में Python 3.7 या उससे ऊपर इंस्टॉल हो
अपडेट और सत्यापन
- उपयोगकर्ताओं को तुरंत iTerm2 3.5.11 में upgrade करना चाहिए
- प्रभावित रिमोट होस्ट पर
/tmp/framer.txtफ़ाइल हटानी चाहिए - SSH Integration में log file लिखने वाला कोड हटा दिया गया है, और इसे दोबारा सार्वजनिक रिलीज़ में शामिल नहीं किया जाएगा
- zip फ़ाइल का SHA-256 मान निम्न है
655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
- zip फ़ाइल सत्यापन के लिए
https://keybase.io/verifyका उपयोग किया जा सकता है
2 टिप्पणियां
अरे, अभी चेक किया तो मेरा संस्करण 3.4.3 ही है। पिछले कुछ दिन से मैं टर्मिनल ठीक से इस्तेमाल नहीं कर रहा था, इसलिए ध्यान भी नहीं दिया और अपडेट भी शायद सही से नहीं हो पाए।
Hacker News की रायें
यह production में print() debugging चले जाने का मामला लगता है
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
verbose mode बंद करने वाला commit, पूरे framer log को हटाने से ठीक पहले वाला यह commit है: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
VERBOSE mode चालू करने वाला commit यह है: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
शायद implementation या debugging के दौरान इसे
VERBOSE=1में बदल दिया गया और commit से पहलेVERBOSE=0पर वापस करना भूल गएconsole.infoइस्तेमाल करते हैंprint debugging अपने-आप में ठीक है और कई बार काम आती है, लेकिन गलती से रह न जाए इसके लिए guardrails रखना अच्छा है। यह सच में बहुत आसान गलती है
SSH integrationfeature के bug की वजह से input और output remote host की/tmp/framer.txtfile में record हो रहे थे, और उस file को remote host के दूसरे users भी पढ़ सकते थे—यह काफी गंभीर हैजिन machines में पहले SSH से login किया था लेकिन अब access नहीं है, उन पर भी ऐसी files बची हो सकती हैं
it2sshcommand इस्तेमाल किया हो, या Settings > Profiles > General में Command popup menu"SSH"पर set हो और"SSH Integration"checked हो।"Login Shell","Command","Custom Command"पर यह लागू नहीं होताहालांकि अगर आप
bashयाzshकी जगहsshको default terminal command की तरह इस्तेमाल करने वालों में हैं, तो संभव है कि आप अन्य apps में भी कई unusual features इस्तेमाल करते हों; इसलिए सिर्फ iTerm ही नहीं, दूसरे attack surfaces पर भी ध्यान देना चाहिएमैं iTerm2 को लंबे समय से काम और निजी इस्तेमाल के लिए अच्छे से इस्तेमाल करता आया हूं, और आगे भी इसे इस्तेमाल करूंगा और पहले की तरह फिर donate करने का सोचता हूं
“मैं इस गलती पर गहरा अफसोस करता हूं और सुनिश्चित करने के लिए कदम उठाऊंगा कि ऐसा फिर कभी न हो” जैसी line देखकर हमेशा थोड़ी आह निकलती है
असली बात यह है कि वे कदम क्या होंगे, और मुझे भी ठीक से नहीं पता कि ऐसा दोबारा न हो इसके लिए क्या करना चाहिए। आप कोई automated tool बना सकते हैं जो हर feature चलाकर system calls capture करे और check करे कि कहीं files open या write तो नहीं हो रहीं, लेकिन GUI app में यह इतना मुश्किल लगता है कि शायद कोई कोशिश भी न करे। उससे कम किसी उपाय से यह guarantee करना मुश्किल लगता है कि यह फिर नहीं होगा
realistically, programmers के लिए इससे बहुत बेहतर करना मुश्किल लगता है, तो सारी जिम्मेदारी इस एक व्यक्ति पर डालना unfair है
लेकिन छोटा लिखने का मतलब यह नहीं कि वे गलती की गंभीरता नहीं समझते। फिर भी मुझे उम्मीद है कि इस तरह की follow-up details पर बाद में एक in-depth blog post आनी चाहिए
माफी न मांगना और खराब होता, और यह न कहना कि recurrence रोकने के कदम उठाएंगे, वह भी खराब होता। अगर अभी तुरंत सारे measures ready होते तो उल्टा अजीब लगता। पहले A) bug fix करना, B) fixed version release करना, C) bug और fix release की जानकारी देना, फिर D) postmortem करना चाहिए; इन सबको मिला देने से process बिखरा हुआ approach लगेगा
यह दावा करना भी अजीब होगा कि सभी bugs या हर unintended file write को रोका जा सकता है। यह prove करना असंभव है कि कोई चीज कभी file में नहीं लिखेगी
अच्छा starting point वही है जो उन्होंने किया: SSH logging हटाना, और file access verify करने के automated तरीकों की जांच करना। macOS development में ecosystem common tools से काफी आगे के tools हैं, इसलिए access-allowed paths की
NSArrayspecify करने वाली 1990s की technical documentation या Instruments के built-in dtrace integration जैसे तरीके हो सकते हैं। इसे CI में चलाना और test coverage पाना, संभवतः best effort के काफी करीब होगामुद्दा शायद यह है कि “मैं यह सुनिश्चित करने के लिए कदम उठाऊंगा कि ऐसा फिर कभी न हो” को आप “जब तक 100% हमेशा के लिए guarantee न हो कि ऐसा फिर कभी नहीं होगा, तब तक कदम उठाऊंगा” के रूप में पढ़ते हैं या नहीं। युवा और आसानी से प्रभावित होने वाले लोगों से कहूं तो, यह blog post अच्छी है और इससे बेहतर करने को बहुत कम बचता है
जो किया जा सकता है, वह यह है कि इसे lesson मानकर उस path में जाते समय ज्यादा सावधान हुआ जाए
console.logहोने पर merge न होने देने के लिए linter इस्तेमाल करने का तरीका बताया गया था, और मैं भी शायद ठीक वही approach अपनाऊंगाinvalid state को exist ही न करने देना काफी उपयोगी principle है
यह ज़्यादातर निजी पसंद की बात होगी, लेकिन 2025 में macOS के डिफ़ॉल्ट Terminal के बजाय iTerm2 इस्तेमाल करने की कोई बहुत मज़बूत वजह है?
बहुत लोगों ने इसकी सिफ़ारिश की है, लेकिन इस SSH bug जैसे security और privacy issues की वजह से मैं सतर्क था
एक और बात यह है कि अगर गलती से कोई tab या window बंद कर दें, तो कुछ सेकंड के अंदर ⌘z दबाने पर window ऐसे वापस आ जाती है जैसे बंद की ही न हो
और minimum colour contrast भी अच्छा है। अगर terminal colour theme और चल रहे program की colour theme खराब तरीके से मिलकर text को unreadable बना दें, तो iTerm इसे detect करके अपने-आप अधिक contrast वाले colours से override कर सकता है
हालांकि यह सिर्फ़ मेरे core features हैं। iTerm Word की तरह हज़ारों features वाला एक भारी-भरकम beast है। हर किसी को सब कुछ नहीं चाहिए, लेकिन किस feature की ज़रूरत है इस पर भी कोई consensus नहीं है
कई macOS release notes में भी
terminalसे search किया, लेकिन कुछ नहीं मिला। क्या किसी को पता है कि यह जानकारी कहाँ public होती है? या public नहीं होती?[1] https://developer.apple.com/documentation/macos-release-note...
[2] https://support.apple.com/en-us/120283
[3] https://support.apple.com/en-in/109035
[4] https://support.apple.com/en-us/106337
मैं चाहता था कि office machine पर SSH करने पर नीला रंग हो और home machine पर SSH करने पर बैंगनी। डिफ़ॉल्ट Terminal में भी कोशिश की, लेकिन session कैसे खत्म हुआ उसके हिसाब से confusion होता था, और लोगों ने कहा कि iTerm2 यह solve कर देता है। कम-से-कम मेरे case में तो सच में solve हुआ
https://ghostty.org/ के बारे में भी बहुत अच्छी बातें सुनी हैं, लेकिन अभी तक try नहीं किया
वैसे, मैंने सवाल को गलती से “alternatives क्या हैं” की तरह पढ़ लिया था
मेरे लिए सिर्फ़ इतना ही valuable है कि मैं native macOS full screen से अलग तरह का full-screen mode इस्तेमाल कर सकता हूँ। हालांकि शायद दुनिया में करीब सात ही लोग होंगे जिन्हें यह महत्वपूर्ण लगता हो
iTerm को relatively कम पैसे में develop करने वाले developer से मुझे गहरी सहानुभूति है। AI integration की वजह से उन्हें पहले ही ज़रूरत से ज़्यादा criticism मिला है
साथ ही, अब मुझे सच में चिंता है कि क्या मैं iTerm इस्तेमाल करना जारी रख सकता हूँ
HPC environments में connect करते समय access rights कभी-कभी सिर्फ़ थोड़े समय के लिए होते हैं, इस्तेमाल के बाद data को खुद साफ़ करना पड़ता है, और उम्मीद होती है कि data leak नहीं होगा। पिछले एक साल में अगर मैंने personal information वाले research data के साथ iTerm की SSH integration इस्तेमाल की होती, तो मुश्किल हो जाती। शायद मुझे admin को शर्मिंदगी भरा email भेजकर पूछना पड़ता कि क्या logs हैं और क्या वे मेरे हैं, और फिर public तौर पर बताना पड़ता कि data leak हो गया
मैं कुछ advanced features भी इस्तेमाल करता हूँ, लेकिन अब सवाल है कि क्या basic features से आगे कुछ इस्तेमाल करना ठीक है। अगर नहीं, तो शायद कोई दूसरा terminal इस्तेमाल कर लेना बेहतर होगा। Ghostty समेत, मुझे अभी तक iTerm जितना MacOS पर native महसूस होने वाला कोई cross-platform terminal नहीं मिला
यह कुछ ऐसा है जैसे एक बार tyre puncture होने पर car ही छोड़ देना। इसके advantages और features को देखते हुए iTerm अब भी सबसे अच्छा option हो सकता है
अगर किसी व्यक्ति को पूरे system और इस्तेमाल किए जा रहे हर software की security खुद verify करनी पड़े, तो उस organization में security है ही नहीं
security knowledge वाला सक्षम system administrator आसानी से configure कर सकता है कि SSH से connect करके बनाए गए files default रूप से everyone-readable permissions न रखें। user files को पूरी तरह isolate करने के लिए दूसरे locks भी लगाए जा सकते हैं, और
/tmp/जैसे globally writable folders को पूरी तरह disable भी किया जा सकता हैअगर कोई आपको insecure software इस्तेमाल करने के लिए दोष दे, तो उनसे पूछना चाहिए कि उनका system security के लिहाज़ से इतना कमजोर क्यों है
कुछ साल पहले मैंने report किया था कि iTerm2 sensitive search history को settings file में leak कर रहा था, और वह issue जल्दी fix हो गया था
लेकिन आज भी public dotfiles repositories में ऐसे लोग मिल जाते हैं जो अनजाने में search history leak कर रहे हैं
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
“बस iTerm2 इस्तेमाल मत करो” वाला सुझाव थोड़ा समझ में नहीं आता
इस तरह की समस्या किसी भी project में हो सकती है, और tool बदलने से कोई खास सुरक्षा नहीं मिलती। बल्कि ऐसे incident के बाद security practices अक्सर और मजबूत हो जाती हैं। यह उस पुराने मज़ाक जैसा है जिसमें गलती करने वाले engineer को निकालने की बात पर manager जवाब देता है, “निकालूँ क्यों? उसने अभी-अभी एक ऐसा सबक सीखा है जिसे वह कभी नहीं भूलेगा”
iTerm2 का इतिहास देखें तो लगता नहीं कि इसमें अक्सर गंभीर security issues रहे हैं, और यह भी नहीं लगता कि वही गलती दोहराई जाएगी। अगर दोहराई जाती है, तो उस समय फिर से आकलन किया जा सकता है
macOS Terminal app ज्यादा सरल है और उसके updates कम बार आते हैं, इसलिए वह कम जोखिम वाला लग सकता है। लेकिन वह closed source है, इसलिए audit नहीं किया जा सकता, और उसका अपना जोखिम भी है। अंत में हर tool में trade-offs होते हैं, और चुनाव जरूरी features व संभावित जोखिम के संतुलन से करना चाहिए
बहुत से लोग इन दोनों बातों को एक तर्कसंगत विश्वास मानते हैं। यह “हर project में bugs हो सकते हैं” वाली बात से कहीं ज्यादा nuanced नजरिया है। ऐसा black-and-white नजरिया risk assessment में ज्यादा मददगार नहीं होता
iTerm2 धीरे-धीरे बहुत ज्यादा जटिल और bloated हो गया है, और security issues भी बहुत ज्यादा लगते हैं
macOS पर नया terminal emulator देखे काफी समय हो गया, लेकिन अब लगता है कि समय आ गया है
GNU Screen भी रुका हुआ लगता है, इसलिए अब tmux पर जाने का टाला हुआ काम भी कर लेना चाहिए
निजी तौर पर मुझे iTerm2 इनमें से किसी भी श्रेणी में नहीं लगता
मैंने अभी तक कोई और terminal नहीं देखा जो इसी स्तर का tmux support देता हो
कोई दूसरा app इस्तेमाल करने से रोजमर्रा के उपयोग में सुधार हो, ऐसा Terminal में क्या कमी है?
Zellij Rust में बना terminal multiplexer है, देखने लायक है। खासकर key bindings को आसानी से discover कर पाना बहुत अच्छा है। TUI में जिस तरह की चीज़ की कल्पना की थी, उसके काफी करीब है
क्या यह सिर्फ SSH integration पर लागू होता है, और उस स्थिति पर नहीं जब iTerm में बस
"ssh"चलाया गया हो?जिन hosts से मैंने साधारण ssh के जरिए connect किया, उन पर मुझे
/tmp/framer.txtfile नहीं मिलीदूसरी condition enterprise distributions में भी आम तौर पर सही होने की संभावना है। उदाहरण के लिए RHEL 9 में Python 3.9 default install होता है