iTerm2 ประกาศอัปเดตความปลอดภัยสำคัญ

 (iterm2.com)
2 คะแนน โดย GN⁺ 2025-01-03 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • iTerm2 3.5.11 เป็นรีลีสที่บิลด์เมื่อวันที่ 2 มกราคม 2025 และแนะนำให้อัปเดตทันทีเนื่องจากมี การแก้ไขความปลอดภัยสำคัญ ที่เกี่ยวข้องกับ SSH Integration
  • ขอบเขตผลกระทบคือผู้ใช้เวอร์ชัน 3.5.6~3.5.10 ที่ใช้ฟีเจอร์ SSH Integration และผู้ใช้เบต้าทุกเวอร์ชันหลัง 3.5.6
  • เมื่อเกิดบั๊ก อินพุตและเอาต์พุตจะถูกบันทึกไว้ที่ /tmp/framer.txt บนโฮสต์ระยะไกล และผู้ใช้อื่นบนโฮสต์ระยะไกลเดียวกันอาจอ่านไฟล์นี้ได้
  • เงื่อนไขคือการใช้ it2ssh หรือกรณีที่ Command ในโปรไฟล์เป็น "SSH" และเลือก "SSH Integration" โดยโฮสต์ระยะไกลต้องมี Python 3.7 ขึ้นไป อยู่ในเส้นทางค้นหาเริ่มต้น
  • ผู้ใช้ควร อัปเกรดเป็น 3.5.11 แล้วลบ /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
  • บั๊กทำให้ฟีเจอร์ SSH Integration บันทึก อินพุตและเอาต์พุต ไปยัง /tmp/framer.txt บนโฮสต์ระยะไกล
    • ไฟล์นี้อาจถูกอ่านได้โดยผู้ใช้อื่นบนโฮสต์ระยะไกล
  • ปัญหาจะเกิดขึ้นเมื่อเงื่อนไขต่อไปนี้เป็นจริงทั้งหมด
    • ใช้คำสั่ง it2ssh
    • หรือใน Settings > Profiles > General เมนูป๊อปอัป Command ถูกตั้งเป็น "SSH" และในกล่องโต้ตอบการตั้งค่า SSH เลือก "SSH Integration"
      • การตั้งค่า "Login Shell", "Command", "Custom Command" ไม่รวมอยู่ในเงื่อนไขนี้
    • มี Python 3.7 ขึ้นไป ติดตั้งอยู่ในเส้นทางค้นหาเริ่มต้นของโฮสต์ระยะไกล

การอัปเดตและการตรวจสอบ

  • ผู้ใช้ควรอัปเกรดเป็น iTerm2 3.5.11 ทันที
  • บนโฮสต์ระยะไกลที่ได้รับผลกระทบ ควรลบไฟล์ /tmp/framer.txt
  • โค้ดที่เขียนไฟล์ล็อกใน SSH Integration ถูกลบออกแล้ว และจะไม่ถูกเผยแพร่ในรีลีสสาธารณะอีก
  • ค่า SHA-256 ของไฟล์ zip มีดังนี้
    • 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
  • สามารถใช้ https://keybase.io/verify เพื่อตรวจสอบไฟล์ zip ได้

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
xguru 2025-01-03

ตอนฉันลองตรวจดูแล้วพบว่าเวอร์ชันของฉันคือ 3.4.3 ครับ ช่วงนี้แทบไม่ค่อยได้ใช้งานเทอร์มินัล เลยไม่ค่อยดูแลตัวเองด้วย ทำให้การอัปเดตก็ไม่ค่อยเกิดขึ้น
 
GN⁺ 2025-01-03
ความเห็นจาก Hacker News

  • ดูเหมือนเป็นกรณีที่มี การดีบักด้วย print() หลุดเข้า production
    https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
    https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

    • ตัวโค้ดเองไม่ได้แปลกอะไร เพียงแต่ถูกออกแบบให้เขียนลงไฟล์เฉพาะตอนเปิด โหมด verbose เท่านั้น
      คอมมิตที่ปิดโหมด verbose คือคอมมิตนี้ซึ่งเกิดขึ้นก่อนลบ framer log ทั้งหมดไม่นาน: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
      ส่วนคอมมิตที่เปิดโหมด VERBOSE คืออันนี้: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
      น่าจะเป็นไปได้ว่าระหว่างทำ implementation หรือดีบัก มีการเปลี่ยนเป็น VERBOSE=1 แล้วลืมเปลี่ยนกลับเป็น VERBOSE=0 ก่อนคอมมิต
    • ในงานพัฒนา TypeScript เราตั้งให้ console.log เป็น lint error เพื่อไม่ให้ merge ได้ และเวลามีเหตุผลจำเป็นจริง ๆ บางทีก็ใช้ console.info แทน
      การดีบักด้วย print เองก็ไม่ใช่เรื่องผิดและมีจังหวะที่ควรใช้ แต่ควรมีมาตรการป้องกันไม่ให้เผลอทิ้งมันไว้ เป็นความผิดพลาดที่เกิดขึ้นได้ง่ายมากจริง ๆ
    • นี่อยู่มานานตั้ง 3 ปีเลยเหรอ?

  • บั๊กของฟีเจอร์ SSH integration ทำให้ input และ output ถูกบันทึกลงไฟล์ /tmp/framer.txt บน remote host และผู้ใช้อื่นบน remote host นั้นก็อาจอ่านไฟล์ได้ ถือว่าค่อนข้างร้ายแรง
    แม้แต่เครื่องที่เคยเชื่อมต่อผ่าน SSH ในอดีต แต่ตอนนี้ไม่มีสิทธิ์เข้าถึงแล้ว ก็อาจยังมีไฟล์แบบนี้หลงเหลืออยู่

    • ต้องเข้าเงื่อนไขทั้งสองข้อพร้อมกัน
      1. ต้องใช้คำสั่ง it2ssh หรือใน Settings > Profiles > General มีการตั้งค่าเมนูป๊อปอัป Command เป็น "SSH" และติ๊ก "SSH Integration" ไว้ "Login Shell", "Command", "Custom Command" ไม่เข้าข่าย
      2. ต้องมี Python 3.7 ขึ้นไป ติดตั้งอยู่ใน default search path ของ remote host
    • บั๊กนี้น่าจะเกิดขึ้นได้น้อยมาก เพราะมันเป็น ฟีเจอร์เฉพาะทางมาก ถึงขนาด 99% ของคนที่นี่อาจไม่เคยได้ยินหรือไม่เคยใช้เลย
      แต่ถ้าคุณเป็นคนประเภทที่ใช้ ssh เป็นคำสั่งพื้นฐานของเทอร์มินัลแทน bash หรือ zsh ก็มีโอกาสสูงว่าคุณน่าจะใช้ฟีเจอร์แปลก ๆ ในแอปอื่นอีกเยอะเหมือนกัน ดังนั้นไม่ใช่แค่ iTerm ที่ควรกังวล แต่ควรใส่ใจกับพื้นผิวการโจมตีอื่นด้วย

  • ใช้ iTerm2 มานานมากทั้งเรื่องงานและเรื่องส่วนตัว และจะยังใช้ต่อไป พร้อมทั้งตั้งใจจะกลับไปบริจาคอีกครั้งเหมือนเมื่อก่อน

  • เวลาเห็นประโยคอย่าง “ผม/ฉันเสียใจอย่างยิ่งกับความผิดพลาดครั้งนี้ และจะดำเนินมาตรการเพื่อไม่ให้เรื่องแบบนี้เกิดขึ้นอีก” ก็อดถอนหายใจเบา ๆ ไม่ได้เสมอ
    ประเด็นสำคัญคือจะใช้มาตรการอะไร ซึ่งผม/ฉันเองก็ไม่แน่ใจว่าควรทำอะไรจึงจะป้องกันไม่ให้เรื่องแบบนี้เกิดซ้ำได้ อาจสร้างเครื่องมืออัตโนมัติที่รันทุกฟีเจอร์แล้วดักจับ system call เพื่อตรวจว่าไม่มีการเปิดหรือเขียนไฟล์ก็ได้ แต่สำหรับ GUI app มันดูยากเกินไปจนไม่น่าจะลงมือทำเลย ถ้าน้อยไปกว่านั้นก็รู้สึกว่ายากจะรับประกันได้ว่าจะไม่เกิดซ้ำ

    • มีการทุ่มเงินมหาศาลให้กับการ fuzzing ของ Chrome/Chromium แต่ทุกปีก็ยังเจอ ช่องโหว่ร้ายแรง หลายสิบรายการอยู่ดี ผลิตภัณฑ์ใหญ่อื่น ๆ ก็ไม่ต่างกัน
      ในทางปฏิบัติดูเหมือนยากมากที่โปรแกรมเมอร์จะทำได้ดีกว่านี้มากนัก ถ้าอย่างนั้นการโยนความรับผิดทั้งหมดให้คน ๆ เดียวก็ดูไม่ยุติธรรม
    • จากที่ประกาศด้านความปลอดภัยสั้นมาก ดูเหมือนผู้เขียนอยากเปิดเผยรายละเอียดที่เกี่ยวกับเหตุการณ์นี้ให้เร็วที่สุด
      แต่การเขียนสั้นไม่ได้แปลว่าเขาไม่เข้าใจขนาดของความผิดพลาด ถึงอย่างนั้นก็ยังคาดหวังว่าในภายหลังควรมี บล็อกเชิงลึก ที่ลงรายละเอียดติดตามเรื่องแบบนี้
    • นี่เป็นทั้งคำพูดที่แย่น้อยที่สุดเท่าที่จะพูดได้ และในเวลาเดียวกันก็เป็นคำพูดที่ดีที่สุดด้วย
      ถ้าไม่ขอโทษก็แย่กว่านี้ และถ้าไม่บอกว่าจะมีมาตรการป้องกันการเกิดซ้ำก็ยิ่งแย่กว่าเดิม ถ้าบอกว่าตอนนี้มีมาตรการทุกอย่างพร้อมแล้วกลับจะดูแปลกด้วยซ้ำ ควรทำ A) แก้บั๊กก่อน B) ปล่อยเวอร์ชันแก้ไข C) แจ้งเรื่องบั๊กและการปล่อยแพตช์ แล้วค่อย D) ทำ postmortem ถ้าเอาทั้งหมดมาปนกันจะดูเป็นกระบวนการที่ไม่เป็นระเบียบ
      จะอ้างว่าสามารถป้องกันบั๊กทุกตัวหรือการเขียนไฟล์โดยไม่ตั้งใจทุกกรณีก็ดูแปลกเหมือนกัน เพราะการพิสูจน์ว่าไม่มีทางเขียนไฟล์ได้เลยนั้นเป็นไปไม่ได้
      จุดเริ่มต้นที่ดีคือการลบ SSH logging อย่างที่ทำไปจริง ๆ และศึกษาวิธีทำ automation เพื่อตรวจสอบการเข้าถึงไฟล์ ในการพัฒนา macOS มีเครื่องมือที่ก้าวหน้ากว่าเครื่องมือกลางของ ecosystem มาก จึงอาจมีวิธีอย่างการกำหนด NSArray ของ path ที่อนุญาตให้เข้าถึงจากเอกสารเทคนิคยุค 1990 หรือการใช้ dtrace integration ที่มีอยู่ใน Instruments หากนำสิ่งเหล่านี้ไปรันใน CI และมี test coverage ที่ดี ก็น่าจะใกล้เคียงกับสิ่งที่ดีที่สุดเท่าที่ทำได้
      ประเด็นเหมือนจะอยู่ที่ว่าคุณตีความ “จะดำเนินมาตรการเพื่อไม่ให้เรื่องแบบนี้เกิดขึ้นอีก” ว่าเป็น “จะทำจนกว่าจะรับประกันได้ 100% ว่าจะไม่มีวันเกิดอีกตลอดไป” หรือไม่ สำหรับคนอายุน้อยและชักจูงได้ง่าย บล็อกโพสต์นี้ถือว่ายอดเยี่ยมและแทบไม่มีอะไรให้ทำได้ดีกว่านี้แล้ว
    • ถ้าเป็นวิศวกรซอฟต์แวร์ เรื่องแบบนี้จะเกิดขึ้นเรื่อย ๆ ไม่ว่าขนาดเล็กใหญ่แค่ไหน สุดท้ายคุณก็ต้องพลาดอยู่ดี
      มาตรการที่ทำได้คือใช้เรื่องนี้เป็นบทเรียน เพื่อให้ระมัดระวังมากขึ้นเมื่อเข้าไปแตะเส้นทางนั้นอีกครั้ง
    • มีคนในคอมเมนต์อื่นพูดถึงการใช้ linter ที่ไม่ยอมให้ merge PR ถ้ามี console.log อยู่ ซึ่งผม/ฉันก็คงเลือกแนวทางแบบนั้นเหมือนกัน
      หลักการที่ทำให้สถานะที่ไม่ถูกต้องไม่สามารถเกิดขึ้นได้เลยนั้นค่อนข้างมีประโยชน์มาก

  • โดยรวมก็อาจเป็นเรื่องรสนิยมส่วนบุคคล แต่ในปี 2025 ยังมีเหตุผลที่โน้มน้าวได้อย่างหนักแน่นอยู่ไหมที่จะใช้ iTerm2 แทน Terminal พื้นฐานของ macOS?
    มีคนแนะนำมาเยอะก็จริง แต่พอมีประเด็นด้านความปลอดภัยและความเป็นส่วนตัวอย่างบั๊ก SSH ครั้งนี้ก็เลยยังกังวลและระวังตัวอยู่

    • สำหรับฉัน ฟีเจอร์สำคัญคือ Edit > Selection Respects Soft Boundaries มันช่วยให้คัดลอกข้อความภายในหน้าต่างที่นิยามอยู่ในเทอร์มินัลได้ เช่น ในพื้นที่แบ่งของ tmux หรือ emacs และ iTerm ก็รู้จักสิ่งอย่างตัวอักษร pipe ว่าเป็นขอบเขตของหน้าต่าง
      อีกอย่างคือถ้าเผลอปิดแท็บหรือหน้าต่างไป ก็สามารถกด ⌘z ภายในไม่กี่วินาทีเพื่อให้หน้าต่างกลับมาเหมือนไม่เคยปิดได้
      และ ค่าคอนทราสต์สีขั้นต่ำ ก็ดีมาก ถ้าธีมสีของเทอร์มินัลกับธีมสีของโปรแกรมที่กำลังรันอยู่ผสมกันแล้วอ่านไม่ออก iTerm จะตรวจจับได้และแทนที่ด้วยสีที่มีคอนทราสต์สูงกว่าโดยอัตโนมัติ
      แต่ทั้งหมดนี้ก็เป็นเพียงฟีเจอร์หลักสำหรับฉันเท่านั้น iTerm เป็นสัตว์ประหลาดตัวใหญ่เทอะทะที่มีฟีเจอร์นับพันเหมือน Word ไม่ใช่ทุกคนจะต้องใช้ทั้งหมด และก็ไม่มีฉันทามติด้วยว่าควรต้องการฟีเจอร์ไหนบ้าง
    • กำลังจะถามว่า Terminal ไม่เคยมีประเด็นด้านความปลอดภัยเลยหรือ แต่พอจะหาหน้า release notes ก็หาไม่เจอ
      ลองค้นคำว่า terminal ใน release notes ของ macOS หลายชุดแล้วก็ไม่เจออะไรเลย มีใครรู้ไหมว่าข้อมูลพวกนี้เผยแพร่ไว้ที่ไหน? หรือว่าไม่ได้เปิดเผย?
      [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 คืออยากให้ สีของเทอร์มินัล เปลี่ยนตอนเชื่อมต่อไปยังโฮสต์อื่นผ่าน SSH
      อยากให้ตอน SSH เข้าเครื่องที่บริษัทเป็นสีน้ำเงิน และตอนเข้าเครื่องที่บ้านเป็นสีม่วง ลองทำในเทอร์มินัลพื้นฐานแล้วแต่มีปัญหาชวนสับสนขึ้นอยู่กับว่าเซสชันจบลงอย่างไร และมีคนแนะนำว่า iTerm2 แก้ปัญหานี้ได้ อย่างน้อยในกรณีของฉัน มันก็แก้ได้จริง
    • ใช้ Kitty(https://sw.kovidgoyal.net/kitty) เป็นตัวหลักมาหลายปีแล้ว และเมื่อใช้ร่วมกับ tmux ก็ยอดเยี่ยมมาก
      ได้ยินมาว่า https://ghostty.org/ ก็ดีเหมือนกัน แต่ยังไม่ได้ลองดู
      เพิ่มเติมคือ ตอนแรกอ่านคำถามผิดเป็น “มีทางเลือกอะไรบ้าง”
    • สุดท้ายแล้วมันขึ้นอยู่กับว่าคุณใช้ macOS มานานแค่ไหน และมี นิสัยยิบย่อยกับความเฉพาะตัว อะไรติดมาบ้าง
      สำหรับฉัน แค่สามารถใช้โหมดเต็มหน้าจอที่ต่างจากโหมดเต็มหน้าจอแบบเนทีฟของ macOS ก็คุ้มแล้ว แต่บางทีคนที่ให้ความสำคัญกับเรื่องนี้อาจมีอยู่ทั้งโลกแค่สักเจ็ดคน

  • ฉันเห็นอกเห็นใจนักพัฒนาที่พัฒนา iTerm ด้วยเงินค่อนข้างจำกัดอย่างมาก ก่อนหน้านี้เขาก็โดนวิจารณ์มากเกินความจำเป็นเพราะเรื่องการรวม AI เข้าไปแล้วด้วย
    ในขณะเดียวกัน ตอนนี้ฉันก็กังวลมากว่าตัวเองยังควรใช้ iTerm ต่อไปหรือไม่
    เวลาต่อเข้าไปยังสภาพแวดล้อม HPC บางครั้งอาจมีสิทธิ์เข้าถึงได้เพียงช่วงสั้น ๆ ต้องจัดการลบข้อมูลด้วยตัวเองหลังใช้งาน และคาดหวังว่าจะไม่มีข้อมูลรั่วไหล หากตลอดหนึ่งปีที่ผ่านมาใช้การรวม SSH ของ iTerm ขณะทำงานกับข้อมูลงานวิจัยส่วนบุคคล ก็คงแย่ไม่น้อย อาจต้องส่งอีเมลน่าอึดอัดถึงผู้ดูแลระบบเพื่อขอให้ตรวจดูว่ามี log หรือไม่ และเป็นของฉันหรือเปล่า จากนั้นก็อาจต้องเปิดเผยต่อไปว่ามีข้อมูลรั่วไหลเกิดขึ้น
    ฉันก็ใช้ฟีเจอร์ขั้นสูงอยู่บ้าง แต่ตอนนี้เริ่มสงสัยแล้วว่ายังควรใช้มากกว่าฟีเจอร์พื้นฐานหรือไม่ ถ้าเป็นอย่างนั้น ใช้เทอร์มินัลตัวอื่นไปเลยก็คงได้ จนถึงตอนนี้รวมถึง Ghostty ด้วย ฉันยังไม่เจอ เทอร์มินัลข้ามแพลตฟอร์ม ตัวไหนที่ให้ความรู้สึกเนทีฟบน MacOS ได้เท่า iTerm

    • ขอแนะนำ wezterm แบบหนักแน่น
    • จะมีเหตุผลอะไรให้เปลี่ยนไปใช้เทอร์มินัลตัวอื่น เพียงเพราะมีปัญหาอยู่หนึ่งครั้งตลอดช่วงเวลายาวนานที่มันมีอยู่?
      มันก็คล้ายกับโยนรถทิ้งเพียงเพราะยางรั่วครั้งหนึ่ง เมื่อพิจารณาจากข้อดีและฟีเจอร์ที่มี iTerm ก็อาจยังเป็นตัวเลือกที่ดีที่สุดอยู่ดี
    • ถ้าเป็นนักวิจัย การรักษาสภาพแวดล้อมการคอมพิวต์ให้ปลอดภัยไม่ใช่ความรับผิดชอบส่วนบุคคล
      ถ้าคนคนหนึ่งต้องตรวจสอบความปลอดภัยของทั้งระบบและซอฟต์แวร์ทุกตัวที่ใช้งานด้วยตัวเอง องค์กรนั้นก็เท่ากับไม่มีความปลอดภัย
      ผู้ดูแลระบบที่มีความสามารถและมีความรู้ด้านความปลอดภัยสามารถตั้งค่าได้ไม่ยาก เพื่อไม่ให้ไฟล์ที่สร้างผ่าน SSH มีสิทธิ์แบบที่ทุกคนอ่านได้เป็นค่าเริ่มต้น และยังสามารถเพิ่มกลไกล็อกอื่น ๆ เพื่อแยกไฟล์ของผู้ใช้ออกจากกันอย่างสมบูรณ์ได้ รวมถึงปิดการใช้งานโฟลเดอร์ที่เขียนได้ทั่วระบบอย่าง /tmp/ ไปเลยก็ยังได้
      ถ้ามีคนตำหนิว่าใครบางคนใช้ซอฟต์แวร์ที่มีช่องโหว่ด้านความปลอดภัย ก็ควรถามกลับว่าทำไมระบบของพวกเขาถึงเปราะบางด้านความปลอดภัยขนาดนั้น
    • ใช้ Prompt ของ Panic

  • หลายปีก่อนเคยรายงานว่า iTerm2 มีปัญหา ทำให้ประวัติการค้นหาที่มีความอ่อนไหวรั่วไปยังไฟล์ตั้งค่า และปัญหานั้นก็ถูกแก้ไขอย่างรวดเร็ว
    แต่แม้ตอนนี้ก็ยังสามารถพบคนที่เผลอเปิดเผยประวัติการค้นหาในที่เก็บ dotfiles แบบสาธารณะได้อยู่
    [1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
    [2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...

  • ข้อเสนอที่ว่า “ก็แค่เลิกใช้ iTerm2” ฟังดูไม่ค่อยสมเหตุสมผลนัก
    ปัญหาประเภทนี้เกิดขึ้นได้กับทุกโปรเจกต์ และการเปลี่ยนเครื่องมือก็ไม่ได้ให้การป้องกันที่มีความหมายแต่อย่างใด ตรงกันข้าม หลังเหตุการณ์แบบนี้ หลายครั้งแนวปฏิบัติด้านความปลอดภัยกลับแข็งแกร่งขึ้นด้วย ซ้ำยังคล้ายกับมุกเก่าเรื่องจะไล่วิศวกรที่ทำพลาดออกไหม แล้วผู้จัดการตอบว่า “จะไล่ออกทำไม? เขาเพิ่งได้บทเรียนที่ไม่มีวันลืมไปนี่เอง”
    ถ้าดูจากประวัติของ iTerm2 ก็ไม่ได้เหมือนว่าจะมีปัญหาความปลอดภัยระดับร้ายแรงบ่อยนัก และก็ดูไม่น่าจะทำพลาดแบบเดิมซ้ำอีก ถ้าเกิดซ้ำจริง ค่อยกลับมาประเมินกันใหม่ตอนนั้นก็ได้
    แอป Terminal ของ macOS อาจดูเสี่ยงต่ำกว่าเพราะเรียบง่ายกว่าและอัปเดตไม่บ่อย แต่ก็เป็น ซอร์สโค้ดปิด จึงตรวจสอบไม่ได้ และนั่นก็เป็นความเสี่ยงในตัวเองอยู่ดี สุดท้ายแล้วทุกเครื่องมือล้วนมี trade-off และควรเลือกจากสมดุลระหว่างความสามารถที่ต้องการกับความเสี่ยงที่อาจเกิดขึ้น

    • คุณคิดว่าแนวปฏิบัติในการพัฒนามีผลต่ออัตราการเกิดบั๊กด้านความปลอดภัยไหม? แล้วคิดว่าประวัติที่ผ่านมาเป็นตัวสะท้อนอัตราการเกิดบั๊กด้านความปลอดภัยนั้นหรือเปล่า?
      หลายคนเชื่อทั้งสองอย่างนี้อย่างมีเหตุผล มันเป็นมุมมองที่ละเอียดกว่าคำพูดว่า “ทุกโปรเจกต์ย่อมมีบั๊กได้” มาก มุมมองแบบขาวดำเช่นนั้นแทบไม่ช่วยอะไรในการประเมินความเสี่ยง

  • ดูเหมือน iTerm2 จะค่อยๆ ซับซ้อนเกินไปและอืดเทอะทะเกินไป แถมยังเหมือนมีประเด็นด้านความปลอดภัยมากเกินไปด้วย
    ฉันมองหา terminal emulator ตัวใหม่บน macOS มานานแล้ว แต่ตอนนี้ดูเหมือนจะถึงเวลาเสียที
    GNU Screen ก็ดูเหมือนจะหยุดนิ่งไปแล้ว งั้นคงถึงเวลาทำสิ่งที่ผัดวันมานานและย้ายไป tmux

    • เพิ่งลองใช้ Ghostty ไม่นานมานี้ และหลังจากนั้นก็ย้ายออกจาก iTerm2 แบบเต็มตัวแล้ว ใช้งานคุ้นมือและงานก็ออกมาลงตัวมาก
    • คำว่า “ซับซ้อนเกินไป” กับ “อืดเทอะทะ” เป็นคำที่ใช้ได้กับทุกอย่าง จึงน่าจะต้องอธิบายให้เฉพาะเจาะจงกว่านี้
      ส่วนตัวฉันไม่รู้สึกว่า iTerm2 เข้าข่ายข้อไหนเลย
    • ฉันใช้ การผสานรวม tmux ของ iTerm2 ค่อนข้างเยอะ มันทำให้การเลื่อนเมาส์ในหน้าต่าง tmux ทำงานได้อย่างเป็นธรรมชาติ
      ยังไม่เคยเห็นเทอร์มินัลตัวอื่นที่รองรับ tmux ได้ดีในระดับเดียวกัน
    • ฉันใช้ Terminal.app มาตั้งแต่ 10.0 และไม่เคยรู้สึกว่าจำเป็นต้องเปลี่ยนเลย
      Terminal ขาดอะไรอยู่หรือ ถึงขนาดที่การใช้แอปอื่นจะช่วยให้การใช้งานประจำวันดีขึ้นอย่างชัดเจน?
    • ยังใช้ GNU Screen อยู่เหรอ? ทั้ง GNU Screen และ tmux ต่างก็เคยมีประเด็นด้านความปลอดภัยในอดีต แต่ฝั่ง GNU Screen หนักกว่า และนั่นคือเหตุผลที่ฉันย้าย
      Zellij เป็น terminal multiplexer ที่เขียนด้วย Rust ก็น่าลองดู โดยเฉพาะตรงที่มันทำให้ค้นพบคีย์ไบน์ดิงได้ง่ายมาก จุดนี้ดีมากจริงๆ ใกล้เคียงกับรูปแบบ TUI ที่ฉันเคยอยากได้เสมอ

  • อันนี้ใช้กับเฉพาะการผสานรวม SSH เท่านั้นใช่ไหม ไม่ใช่กรณีที่แค่รัน "ssh" ใน iTerm ตามปกติ?
    บนโฮสต์ที่ฉันเชื่อมต่อด้วย ssh แบบธรรมดา ฉันหาไฟล์ /tmp/framer.txt ไม่เจอ

    • จาก release notes ดูเหมือนว่ากรณีนี้ใช้ การผสานรวม SSH แบบฝังมาในตัว และจะเกิดเฉพาะเมื่อบนเซิร์ฟเวอร์มี Python เวอร์ชันค่อนข้างใหม่เท่านั้น
      เงื่อนไขอย่างหลังนี้มีแนวโน้มว่าจะตรงแม้แต่ในดิสโทรสาย enterprise ด้วย เช่น RHEL 9 ก็ติดตั้ง Python 3.9 มาเป็นค่าปริยาย