2 पॉइंट द्वारा GN⁺ 2025-01-03 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 टिप्पणियां

 
xguru 2025-01-03

अरे, अभी चेक किया तो मेरा संस्करण 3.4.3 ही है। पिछले कुछ दिन से मैं टर्मिनल ठीक से इस्तेमाल नहीं कर रहा था, इसलिए ध्यान भी नहीं दिया और अपडेट भी शायद सही से नहीं हो पाए।

 
GN⁺ 2025-01-03
Hacker News की रायें
  • यह production में print() debugging चले जाने का मामला लगता है
    https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
    https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

    • code अपने-आप में अजीब नहीं है; यह केवल verbose mode चालू होने पर ही file में लिखने वाला structure है
      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 पर वापस करना भूल गए
    • TypeScript development में हमने console.log को lint error बना दिया है ताकि वह merge न हो सके, और कभी-कभी जायज जरूरत हो तो console.info इस्तेमाल करते हैं
      print debugging अपने-आप में ठीक है और कई बार काम आती है, लेकिन गलती से रह न जाए इसके लिए guardrails रखना अच्छा है। यह सच में बहुत आसान गलती है
    • क्या यह 3 साल तक मौजूद था?
  • SSH integration feature के bug की वजह से input और output remote host की /tmp/framer.txt file में record हो रहे थे, और उस file को remote host के दूसरे users भी पढ़ सकते थे—यह काफी गंभीर है
    जिन machines में पहले SSH से login किया था लेकिन अब access नहीं है, उन पर भी ऐसी files बची हो सकती हैं

    • इसके लिए दोनों conditions पूरी होनी चाहिए
      1. आपने it2ssh command इस्तेमाल किया हो, या Settings > Profiles > General में Command popup menu "SSH" पर set हो और "SSH Integration" checked हो। "Login Shell", "Command", "Custom Command" पर यह लागू नहीं होता
      2. remote host के default search path में Python 3.7 या उससे ऊपर installed होना चाहिए
    • लगता है यह bug बहुत कम trigger हुआ होगा। क्योंकि यह बहुत खास तरह का feature है, जिसे यहां मौजूद 99% लोगों ने शायद सुना भी नहीं होगा, इस्तेमाल करना तो दूर
      हालांकि अगर आप 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 करना मुश्किल लगता है कि यह फिर नहीं होगा

    • Chrome/Chromium fuzzing पर बहुत पैसा खर्च हुआ है, फिर भी हर साल दर्जनों गंभीर vulnerabilities मिलती हैं। दूसरे बड़े products के साथ भी यही है
      realistically, programmers के लिए इससे बहुत बेहतर करना मुश्किल लगता है, तो सारी जिम्मेदारी इस एक व्यक्ति पर डालना unfair है
    • security notice छोटा है, इससे लगता है कि author घटना से जुड़ी details जल्द-से-जल्द public करना चाहते थे
      लेकिन छोटा लिखने का मतलब यह नहीं कि वे गलती की गंभीरता नहीं समझते। फिर भी मुझे उम्मीद है कि इस तरह की follow-up details पर बाद में एक in-depth blog post आनी चाहिए
    • यह sentence कही जा सकने वाली बातों में सबसे कम खराब है, और साथ ही सबसे अच्छी भी है
      माफी न मांगना और खराब होता, और यह न कहना कि 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 की NSArray specify करने वाली 1990s की technical documentation या Instruments के built-in dtrace integration जैसे तरीके हो सकते हैं। इसे CI में चलाना और test coverage पाना, संभवतः best effort के काफी करीब होगा
      मुद्दा शायद यह है कि “मैं यह सुनिश्चित करने के लिए कदम उठाऊंगा कि ऐसा फिर कभी न हो” को आप “जब तक 100% हमेशा के लिए guarantee न हो कि ऐसा फिर कभी नहीं होगा, तब तक कदम उठाऊंगा” के रूप में पढ़ते हैं या नहीं। युवा और आसानी से प्रभावित होने वाले लोगों से कहूं तो, यह blog post अच्छी है और इससे बेहतर करने को बहुत कम बचता है
    • अगर आप software engineer हैं, तो ऐसे मामले scale चाहे जो हो, होते रहेंगे। आखिरकार गलती होनी ही है
      जो किया जा सकता है, वह यह है कि इसे lesson मानकर उस path में जाते समय ज्यादा सावधान हुआ जाए
    • दूसरे comment में PR में console.log होने पर merge न होने देने के लिए linter इस्तेमाल करने का तरीका बताया गया था, और मैं भी शायद ठीक वही approach अपनाऊंगा
      invalid state को exist ही न करने देना काफी उपयोगी principle है
  • यह ज़्यादातर निजी पसंद की बात होगी, लेकिन 2025 में macOS के डिफ़ॉल्ट Terminal के बजाय iTerm2 इस्तेमाल करने की कोई बहुत मज़बूत वजह है?
    बहुत लोगों ने इसकी सिफ़ारिश की है, लेकिन इस SSH bug जैसे security और privacy issues की वजह से मैं सतर्क था

    • मेरे लिए मुख्य feature Edit > Selection Respects Soft Boundaries है। यह terminal के अंदर define की गई window, जैसे tmux या emacs split pane के अंदर का text copy करने देता है, और iTerm pipe character जैसी चीज़ों को window boundary के रूप में पहचान लेता है
      एक और बात यह है कि अगर गलती से कोई 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 नहीं है
    • मैं पूछने ही वाला था कि क्या Terminal में कभी security issue नहीं रहा, फिर release notes page ढूँढने की कोशिश की लेकिन नहीं मिला
      कई 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
    • iTerm2 पर switch करने की मेरी इकलौती वजह यह थी कि SSH से दूसरे hosts पर connect करते समय terminal colours बदलें
      मैं चाहता था कि office machine पर SSH करने पर नीला रंग हो और home machine पर SSH करने पर बैंगनी। डिफ़ॉल्ट Terminal में भी कोशिश की, लेकिन session कैसे खत्म हुआ उसके हिसाब से confusion होता था, और लोगों ने कहा कि iTerm2 यह solve कर देता है। कम-से-कम मेरे case में तो सच में solve हुआ
    • Kitty(https://sw.kovidgoyal.net/kitty) को मैं कई सालों से primary terminal की तरह इस्तेमाल कर रहा हूँ और tmux के साथ यह बढ़िया है
      https://ghostty.org/ के बारे में भी बहुत अच्छी बातें सुनी हैं, लेकिन अभी तक try नहीं किया
      वैसे, मैंने सवाल को गलती से “alternatives क्या हैं” की तरह पढ़ लिया था
    • आखिरकार यह इस पर निर्भर करता है कि आपने macOS कितने समय तक इस्तेमाल किया है और आपकी कौन-सी छोटी-छोटी आदतें और quirks बन गई हैं
      मेरे लिए सिर्फ़ इतना ही 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 नहीं मिला

    • wezterm की मैं ज़ोरदार सिफ़ारिश करता हूँ
    • इतने लंबे समय में सिर्फ़ एक issue आया है, तो क्या इस वजह से दूसरे terminal पर switch करना चाहिए?
      यह कुछ ऐसा है जैसे एक बार tyre puncture होने पर car ही छोड़ देना। इसके advantages और features को देखते हुए iTerm अब भी सबसे अच्छा option हो सकता है
    • अगर आप researcher हैं, तो secure computing environment बनाए रखना आपकी व्यक्तिगत ज़िम्मेदारी नहीं है
      अगर किसी व्यक्ति को पूरे 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 के लिहाज़ से इतना कमजोर क्यों है
    • मैं Panic का Prompt इस्तेमाल करता हूँ
  • कुछ साल पहले मैंने 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 व संभावित जोखिम के संतुलन से करना चाहिए

    • क्या आपको लगता है कि development practices security bugs की दर को प्रभावित करती हैं? और क्या past history उस security bugs की दर को दर्शाती है?
      बहुत से लोग इन दोनों बातों को एक तर्कसंगत विश्वास मानते हैं। यह “हर project में bugs हो सकते हैं” वाली बात से कहीं ज्यादा nuanced नजरिया है। ऐसा black-and-white नजरिया risk assessment में ज्यादा मददगार नहीं होता
  • iTerm2 धीरे-धीरे बहुत ज्यादा जटिल और bloated हो गया है, और security issues भी बहुत ज्यादा लगते हैं
    macOS पर नया terminal emulator देखे काफी समय हो गया, लेकिन अब लगता है कि समय आ गया है
    GNU Screen भी रुका हुआ लगता है, इसलिए अब tmux पर जाने का टाला हुआ काम भी कर लेना चाहिए

    • हाल में Ghostty इस्तेमाल किया और उसके बाद iTerm2 से पूरी तरह switch कर लिया। परिचित भी लगता है और काफी polished भी है
    • “बहुत जटिल” और “bloated” हर जगह इस्तेमाल होने वाले शब्द हैं, इसलिए इन्हें थोड़ा और साफ तौर पर समझाने की जरूरत है
      निजी तौर पर मुझे iTerm2 इनमें से किसी भी श्रेणी में नहीं लगता
    • मैं iTerm2 का tmux integration काफी इस्तेमाल करता हूँ। यह tmux window में mouse scroll को natural तरीके से काम करने देता है
      मैंने अभी तक कोई और terminal नहीं देखा जो इसी स्तर का tmux support देता हो
    • मैं 10.0 से Terminal.app इस्तेमाल कर रहा हूँ, और कभी इसे बदलने की जरूरत महसूस नहीं हुई
      कोई दूसरा app इस्तेमाल करने से रोजमर्रा के उपयोग में सुधार हो, ऐसा Terminal में क्या कमी है?
    • क्या आप अब भी GNU Screen इस्तेमाल करते हैं? GNU Screen और tmux दोनों में पहले security issues रहे हैं, लेकिन GNU Screen वाले ज्यादा गंभीर थे, इसलिए मैंने switch कर लिया
      Zellij Rust में बना terminal multiplexer है, देखने लायक है। खासकर key bindings को आसानी से discover कर पाना बहुत अच्छा है। TUI में जिस तरह की चीज़ की कल्पना की थी, उसके काफी करीब है
  • क्या यह सिर्फ SSH integration पर लागू होता है, और उस स्थिति पर नहीं जब iTerm में बस "ssh" चलाया गया हो?
    जिन hosts से मैंने साधारण ssh के जरिए connect किया, उन पर मुझे /tmp/framer.txt file नहीं मिली

    • release notes देखने पर लगता है कि यह सिर्फ तब लागू होता है जब built-in SSH integration इस्तेमाल किया गया हो और server पर Python का अपेक्षाकृत हाल का version हो
      दूसरी condition enterprise distributions में भी आम तौर पर सही होने की संभावना है। उदाहरण के लिए RHEL 9 में Python 3.9 default install होता है