ผู้ดูแลแพ็กเกจ KeePassXC ของ Debian ลบฟีเจอร์เครือข่ายทั้งหมดออก

(fosstodon.org/@keepassxc)

1 คะแนน โดย GN⁺ 2024-05-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

หากแพ็กเกจ keepassxc ของ Debian ถูกเปลี่ยนเป็น แพ็กเกจฟีเจอร์ขั้นต่ำ ผู้ใช้ที่ต้องการคงความสามารถเดิมไว้จะต้องย้ายไปใช้ keepassxc-full
ขอบเขตการถอดฟีเจอร์ไม่ได้มีแค่ระบบเครือข่าย แต่รวมถึง YubiKey, auto-type, การผสานรวมกับเบราว์เซอร์, SSH agent, FDO secrets, การดาวน์โหลด favicon และ HIBP ด้วย
คำอธิบายแพ็กเกจของ Debian ระบุว่า keepassxc แบบพื้นฐานจะให้เพียง “bare minimal functionality” เท่านั้น และจัดหมวดเครือข่าย, SSH agent, ปลั๊กอินเบราว์เซอร์ และ FDO secret storage ว่าเป็น ความซับซ้อนด้านความปลอดภัย
ประกาศการเปลี่ยนแปลงจะสื่อสารผ่าน NEWS.Debian.gz และ apt-listchanges ขณะที่ผู้ใช้ stable ควรตรวจดูบันทึกประจำรุ่น
ชื่อแพ็กเกจและวิธีการเปลี่ยนผ่านยังอาจมีการปรับได้ และหลัง Trixie มีการพูดถึงแนวทางให้ apt install keepassxc แสดงตัวเลือกสองแบบ

การเปลี่ยนแปลงแพ็กเกจ `keepassxc` ของ Debian

Team KeePassXC แจ้งผู้ใช้ Debian ว่าผู้ดูแลแพ็กเกจ keepassxc ตั้งใจจะตัดฟีเจอร์ออกจำนวนมาก
หากการเปลี่ยนแปลงนี้ถูกนำออกไปนอก testing/sid ผู้ใช้ที่ต้องการฟีเจอร์เดิมจะต้องย้ายไปใช้ keepassxc-full
รายงานบั๊กของ Debian ดูเหมือนจะเป็นเพียงการปิดการใช้งานเครือข่าย แต่ Team KeePassXC โต้แย้งว่าการเปลี่ยนแปลงจริงนั้นใกล้เคียงกับ การถอดฟีเจอร์ทั้งชุดที่เกินกว่าเรื่องเครือข่าย

ขอบเขตของฟีเจอร์ที่ถูกถอดออก

Team KeePassXC ระบุว่าฟีเจอร์ที่จะถูกถอดมีดังนี้
- YubiKey
- auto-type
- การผสานรวมกับเบราว์เซอร์
- SSH agent
- FDO secrets
- ระบบเครือข่าย
- การดาวน์โหลด favicon
- HIBP

คำอธิบายแพ็กเกจของ Debian และเหตุผล

คำอธิบายแพ็กเกจ keepassxc ใน Debian sid ระบุว่าแพ็กเกจพื้นฐานจะมีเพียงฟังก์ชันขั้นต่ำ
คำอธิบายดังกล่าวมองว่าเครือข่าย, SSH agent, ปลั๊กอินเบราว์เซอร์ และ FDO secret storage เป็น ความซับซ้อนด้านความปลอดภัย และแนะนำให้ใช้ keepassxc-full หากจำเป็นจริง
มีการแชร์รายงานบั๊ก Debian ที่เกี่ยวข้องคือ #953529 - keepassxc: Compiling with disable networking support

จุดยืนของผู้ดูแล Debian

ผู้ดูแล Debian ระบุว่า จุดแรกที่ควรตรวจสอบเมื่อมีการเปลี่ยนแปลงที่ไม่คาดคิดคือ /usr/share/doc/<package>/NEWS.Debian.gz
ผู้ใช้ testing/unstable หากติดตั้ง apt-listchanges ไว้จะสามารถเห็นการเปลี่ยนแปลงได้อัตโนมัติ ส่วนผู้ใช้ stable ควรอ่านบันทึกประจำรุ่น
เขาระบุว่าการตัดสินใจนี้มีการพูดคุยมานาน 1 ปี และหลังเหตุการณ์ xz-utils ก็มีแนวโน้มให้ลดโค้ดที่รวมมาโดยปริยายให้มากที่สุด
ผู้ดูแลมองว่า กลุ่มผู้ใช้ที่ต้องการ Debian, KeePassXC และตัวจัดการรหัสผ่านที่มีฟีเจอร์จำนวนมากพร้อมกันนั้นไม่ได้ทับซ้อนกันมากนัก
เขาระบุว่าการใส่ “ช่องโหว่” ลงในตัวจัดการรหัสผ่านที่ใช้เฉพาะในเครื่องนั้นไม่มีเหตุผล

ปัญหาการสื่อสารระหว่าง upstream กับ downstream

ผู้ใช้รายหนึ่งตั้งข้อสังเกตว่า แม้จะมีการหารือกันมานาน แต่ฝั่งนักพัฒนา upstream กลับดูเหมือนเพิ่งทราบเรื่องทั้งหมดและประหลาดใจอย่างมาก
ผู้ดูแล Debian ตอบว่านี่เป็นประเด็นภายในโครงการ Debian และเขาได้สอบถามความเห็นจากนักพัฒนา Debian คนอื่นผ่าน IRC
เขาอธิบายว่ารับทราบจุดยืนของ upstream อยู่แล้ว, upstream ออกจาก IRC ไปเมื่อหลายปีก่อน และเพียงแค่การแพ็กเกจเวอร์ชันใหม่ก็ใช้พลังงานมากพออยู่แล้ว
Team KeePassXC และผู้ใช้บางส่วนกังวลว่าการตัดสินใจฝั่ง downstream อาจทำให้รายงานบั๊กและความสับสนหลั่งไหลไปที่ upstream

ชื่อแพ็กเกจและทิศทางการเปลี่ยนผ่าน

ผู้ใช้หลายคนเสนอว่า แทนที่จะเปลี่ยน keepassxc แบบเดิมให้เป็นแพ็กเกจฟีเจอร์ขั้นต่ำ ควรใช้ชื่ออย่าง keepassxc-minimal หรือ keepassxc-light และคง keepassxc เดิมไว้เป็นแพ็กเกจฟีเจอร์เต็มเพื่อหลีกเลี่ยงความสับสน
ข้อเสนอหนึ่งมีโครงสร้างดังนี้
- keepassxc-light
- keepassxc-full
- keepassxc พึ่งพา keepassxc-full ในฐานะ แพ็กเกจเปลี่ยนผ่าน
- อธิบายการเปลี่ยนแปลงผ่าน NEWS.Debian
ผู้ดูแล Debian ตอบว่าการเปลี่ยนชื่อขึ้นอยู่กับการอนุมัติของ ftpteam และแนวทางแพ็กเกจเปลี่ยนผ่านสำหรับ Trixie อาจเป็นข้อเสนอที่ดีที่สุด
หลัง Trixie ยังมีการพูดถึงแนวทางเอาแพ็กเกจเปลี่ยนผ่านออก แล้วให้ apt install keepassxc แสดงตัวเลือกสองแบบ

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

GN⁺ 2024-05-12

ความเห็นจาก Hacker News

การนำฟีเจอร์ที่ upstream ใส่ไว้ในซอฟต์แวร์ออก จำนวนมาก แล้วแจกจ่ายภายใต้ชื่อเดิม อย่างมองในแง่ดีก็ยังน่าสงสัย
ถ้าจะไปในทิศทางนี้ก็ควรปล่อยเป็น fork ที่ใช้ชื่ออื่น และแบบนั้น upstream ก็จะไม่ต้องคอยรับเรื่องปัญหาจากผู้ใช้ต่อไป
มันทำให้นึกถึงตอนที่ผู้ดูแล Chromium ของ Debian ปิดความสามารถในการติดตั้งส่วนขยายแบบฝ่ายเดียว และสุดท้ายแพตช์นั้นก็ถูกย้อนกลับ
และยังนึกถึงสมัยนานมากแล้วที่ Debian เอา kernel interface สำหรับโหลด binary firmware ลงการ์ดเครือข่ายออก จนเครือข่ายของฉันพัง
- สิ่งที่ทำจริง ๆ คือแค่เปลี่ยน พารามิเตอร์บิลด์ XC_ALL เป็น OFF [0] และค่านี้ก็เป็นค่าเริ่มต้นใน CMakeLists.txt ของ upstream อยู่แล้ว 1
  ถ้า upstream มองว่าฟีเจอร์นี้สำคัญขนาดนั้น ก็ควรแก้จากค่าเริ่มต้นก่อน
  หลังอัปเกรดแล้วฟีเจอร์หยุดทำงานอาจทำให้ผู้ใช้สับสนได้ แต่แพ็กเกจที่ไม่มี suffix ตรงกับค่าเริ่มต้นของ upstream ก็ถือว่าสมเหตุสมผลอยู่พอควรในตัวมันเอง
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- บทบาทของผู้ดูแลไม่ได้มีแค่คัดลอก upstream มาแปะ
  พวกเขามีสิทธิ์ตัดสินว่าอะไรเหมาะสมกับผู้ใช้ปลายทางของดิสทริบิวชัน
  ในกรณีนี้ดูเหมือนจะมี เหตุผลด้านความปลอดภัย ที่สมเหตุสมผล และก็มีแพ็กเกจทางเลือกให้ด้วย
- Debian ดูเหมือนเป็นดิสทริบิวชันเดียวที่มีท่าทีแปลก ๆ แบบไม่สน upstream
  แม้แต่ในสองโปรเจกต์ upstream ที่ฉันดูแล Debian ก็เปลี่ยนชื่อแพ็กเกจฝ่ายเดียว
  อันหนึ่งฉันมารู้เอาหลังจากผ่านไปนานมาก ส่วนอีกอันฉันคัดค้านอย่างชัดเจนแล้ว แต่ก็ยังเดินหน้าต่อแบบไม่มีเหตุผลเอาเสียเลย
  สุดท้ายคนที่ต้องอธิบายให้ผู้ใช้ฟังคือฉัน
  
  แก้ไข: ดูความหยิ่งยโสของ Julian ฝั่ง Debian ได้ที่นี่: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — นี่แหละสิ่งที่ฉันพูดถึง
- มันไม่ใช่การ “เฉือนทิ้ง” สิ่งที่ upstream สร้างมา
  แต่มันคือการแจกจ่ายเวอร์ชันที่ไม่มีปลั๊กอิน และทำ เวอร์ชัน -full ที่รวมปลั๊กอินไว้
  ถ้าปลั๊กอินถูกเสียบมาเป็นค่าเริ่มต้น มันก็ไม่ใช่ปลั๊กอินแล้วแต่เป็นฟีเจอร์ในตัว และวิธีนี้ถือว่าถูกต้อง
- ถ้า Apple บอกว่า “เราแก้แอปของคุณเพราะคิดว่าปลอดภัยกว่า” คนคงถือคบเพลิงกับส้อมมาประท้วงกันแล้ว
  แต่พอเป็นผู้ดูแล deb กลับกลายเป็นประเด็นให้ถกเถียงกัน
  ถ้ามีปัญหาด้านความปลอดภัย เวอร์ชันที่ไม่ปลอดภัยก็ควรจะไม่ถูกแจกจ่ายเลย แต่กรณีนี้ก็ไม่ใช่แบบนั้น
  ในโลกแบบ App Store บทบาทของผู้ดูแลต้องเปลี่ยนไป
  หน้าที่คือทำให้ซอฟต์แวร์ใช้งานได้บนดิสทริบิวชัน ไม่ใช่สร้าง กึ่ง fork ตามรสนิยมตัวเองโดยยังใช้ชื่อเดิม
ดูเป็นการตัดสินใจที่สมเหตุสมผลทีเดียว
ฟีเจอร์เครือข่าย และการรวมกับเบราว์เซอร์เป็นช่องโหว่ที่อาจเกิดขึ้นได้มากและเป็นจุดเริ่มต้นของการโจมตี
ถ้ารันโดยไม่มีฟีเจอร์เกี่ยวกับเครือข่ายและใช้แค่ฐานข้อมูลที่เชื่อถือได้ ต่อให้เจอช่องโหว่ก็น่าจะแทบเป็นไปไม่ได้ที่จะนำเครื่องมือนี้ไปใช้โจมตี ซึ่งเป็นคุณสมบัติที่พึงประสงค์มากสำหรับเครื่องมือสำคัญอย่างตัวจัดการรหัสผ่าน
เดิมทีผู้ดูแลเองก็เห็นด้วย 1
Debian ก็ยังมีแพ็กเกจเต็มที่เปิดเครือข่ายไว้ ดังนั้นผู้ใช้ที่ต้องการก็แค่ apt install keepassxc-full เพื่อใช้ฟีเจอร์เครือข่ายทั้งหมดได้
แต่การเรียก upstream ว่า “crappy”[0] ไม่ใช่ท่าทีที่สร้างสรรค์สำหรับผู้ดูแลแพ็กเกจ และชื่อแพ็กเกจก็น่าจะเข้าใจง่ายกว่าสำหรับผู้ใช้ Debian ถ้าใช้ keepassxc-lite กับ keepassxc-full แทน keepassxc กับ keepassxc-full

[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- หลายอย่างก็เป็นทั้งช่องโหว่ที่อาจเกิดขึ้นได้มากและเป็นจุดเริ่มต้นของการโจมตี ขณะเดียวกันก็มีประโยชน์ด้วย
  “ความมีประโยชน์” อาจช่วยเพิ่มความปลอดภัยได้
  เพราะถ้าตัวจัดการรหัสผ่านใช้งานยาก คนก็จะเลิกใช้มัน
  พอดูเพิ่มอีกหน่อยก็ยังไม่ชัดว่าการใช้ clipboard ปลอดภัยกว่าการรวมกับเบราว์เซอร์จริงหรือไม่
  ความผิดพลาดจากการคัดลอก/วางอย่างเดียวก็อาจหักล้างภาระด้านความปลอดภัยส่วนใหญ่ของการรวมกับเบราว์เซอร์ได้แล้ว
  นานมาแล้วฉันเคยทำงานตามสัญญาให้บริษัทใหญ่แห่งหนึ่ง โน้ตบุ๊กของผู้ดูแลบัญชีมีทั้งรหัสผ่านเข้ารหัสดิสก์ รหัสผ่านล็อกอิน Windows และรหัสผ่านล็อกอิน AD ซึ่งทั้งหมดต้องไม่ซ้ำกัน ต้องเปลี่ยนทุกไม่กี่เดือน และยังมีข้อกำหนดด้านความซับซ้อนที่เข้มมาก
  โน้ตบุ๊กทุกเครื่องที่ฉันเห็นล้วนมีโพสต์อิตแปะไว้พร้อมรหัสผ่านทั้งสามโดยไม่มีข้อยกเว้น
  ประเด็นคือ ความปลอดภัยแบบหมกมุ่นเชิงทฤษฎี ไม่ได้เท่ากับความปลอดภัยจริงในโลกความเป็นจริง
  อย่างน้อยก็ไม่ได้เท่ากันเสมอไป และเรื่องนี้ต้องมีการแลกเปลี่ยนกันจริง ๆ

ตามปกติไม่ควรทำแบบนั้น แต่ถ้าผ่านระบบ IT ของบริษัทจะเสียเวลามากเกินไปเพราะระบบราชการ จึงเร็วและง่ายกว่ามาก
เป็นบริษัทประเภทนั้นแหละ
เรื่องนี้เองก็ถือเป็น “ความเสี่ยงด้านความปลอดภัย” อยู่แล้วแน่นอน เพราะจริง ๆ แล้วไม่ควรให้ช่างเทคนิคสุ่ม ๆ จากร้านคอมพิวเตอร์มาจับโน้ตบุ๊กที่มีข้อมูลองค์กรลับสุดยอด
แต่ผมคิดว่าไม่ได้มีอะไรให้ปกป้องมากขนาดนั้น ส่วนใหญ่ก็แค่ตัวเลขยอดขาย/ลูกค้า และเป็นข้อมูลที่มีประโยชน์กับคนจำนวนจำกัดมาก

การเชื่อมต่อกับเบราว์เซอร์มีข้อหนึ่งที่ปลอดภัยกว่าการคัดลอก/วางด้วยมือ
ส่วนขยายเบราว์เซอร์จะตรวจสอบ URL ของหน้าเว็บ ก่อนกรอกข้อมูลรับรอง แต่การคัดลอก/วางด้วยมือเสี่ยงต่อโดเมนสะกดผิดหรือฟิชชิงด้วยอักขระหน้าตาคล้ายกัน
ผมเห็นด้วยว่าฟังก์ชันเครือข่ายกับการเชื่อมต่อเบราว์เซอร์เป็นช่องโหว่ที่มีศักยภาพสูง แต่ประเด็นสำคัญคืออย่างที่ผู้ร่วมสนทนาใน GitHub issue บอกไว้ การทดสอบ บิลด์แบบตัดทอน แทบไม่มีเลยเมื่อเทียบกับบิลด์เต็ม และการผสมกันของ build flag แบบตามอำเภอใจก็ไม่ถูกทดสอบเลย
อย่างที่มีคนพูดไว้ที่อื่น หนึ่งใน flag “ตัวเลือก” ที่ถูกปิดคือการรองรับ yubikey และเพราะเหตุนี้ผู้ใช้ที่อัปเกรดไปเป็นแพ็กเกจที่พังใหม่จึงถูกล็อกออกจากตัวจัดการรหัสผ่าน
ต่อให้เปิด flag นั้นกลับมาอย่างเดียว ก็จะกลายเป็นสถานะที่ไม่มีใครทดสอบอยู่ดี
ถ้าตั้งอยู่บนสมมุติฐานว่าได้ย้ายผู้ใช้เดิมไปที่ keepassxc-full แล้ว ผมก็เห็นด้วยว่าชื่อ keepassxc-lite น่าจะช่วยป้องกันปัญหาได้
แต่นั่นแหละคือประเด็นสำคัญ
การตั้งค่าเริ่มต้นให้เป็นวิธีที่ปลอดภัยที่สุดเป็นเรื่องสมเหตุสมผล แต่ผู้ดูแลแพ็กเกจไม่ควรทำให้ฟีเจอร์เดิมพัง เว้นแต่ upstream หรือผู้ใช้ต้องการ และโดยเฉพาะอย่างยิ่งไม่ควรทำให้ผู้ใช้ถูกล็อกออกจากตัวจัดการรหัสผ่าน
การไปโพสต์คำว่า “crappy” บน GitHub นั้นเสียมารยาทเกินไป ถึงขั้นว่าถ้าผมใช้ Debian อยู่ก็คงต้องคิดใหม่ว่าจะใช้ต่อไหม
ถ้าแพ็กเกจนั้นเต็มไปด้วย ฟีเจอร์ห่วย ๆ ขนาดนั้น แล้วจะดูแลมันไปทำไม
เอาออกไปเลย แล้วปล่อยให้ผู้ใช้ไปหาวิธีติดตั้งแบบถูกต้องกันเองน่าจะดีกว่า
ผมสงสารนักพัฒนา KeepassXC มาก แค่ดูแลโปรเจกต์โอเพนซอร์สก็ยากพออยู่แล้ว ยังต้องมาเจอเรื่องแบบนี้อีก
ทันทีที่เห็น คำว่า crappy ความเคารพที่ผมมีต่อ julian-klode ก็หายไปทันที
วิธีแก้ที่ drawks เสนอชัดเจนว่าเป็นทางเลือกที่ถูกต้อง:

วิธีแก้ที่เหมาะสมน่าจะเป็นการแพ็กเกจซอฟต์แวร์ทั้งเวอร์ชัน "-full" และ "-minimal" กำหนดความสัมพันธ์ Conflicts ระหว่างสองแพ็กเกจด้วยฟิลด์ metadata ของแพ็กเกจ Debian ติดแท็กให้ทั้งคู่ Provides keepassxc และเพิ่มแท็ก Replaces: keepassxc ให้กับบิลด์ -full ด้วย แบบนี้ระหว่างการอัปเกรดแพ็กเกจ ผู้ใช้เดิมจะได้รับเวอร์ชันที่ยังคงมีฟังก์ชันของแพ็กเกจที่ถูกอัปเกรด/แทนที่อยู่ ส่วนผู้ใช้ใหม่ก็เลือกเองได้ว่าจะติดตั้งเวอร์ชันไหน

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

ผมไม่เข้าใจว่าทำไมสิ่งนี้ถึง ไม่ใช่ตัวเลือกที่ชัดเจน
- เพราะผู้ดูแลมีมุมมองของตัวเอง และต้องการ เปลี่ยนค่าเริ่มต้น อย่างชัดเจน
- ไม่ใช่แค่เป็นทางเลือกที่ชัดเจนเท่านั้น แต่ใน Debian ก็เกิดขึ้น แบบนั้นเป๊ะ ๆ จริง: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  โพสต์ต้นฉบับเขียนแบบคลิกเบตผิด ๆ เท่านั้น
  ไม่มีอะไรถูกลบออก แค่ย้ายไปอยู่ในแพ็กเกจ keepassxc-full
ขณะเดียวกันฝั่ง Arch เอง แพ็กเกจ fwupd ที่น่าจะถูกติดตั้งค่อนข้างบ่อยในกลุ่มผู้ใช้ กลับถูกตั้งค่าให้พึ่งพา passim แบบเงียบ ๆ และ passim ก็เปิดเว็บเซิร์ฟเวอร์บน 0.0.0.0:275001 โดยไม่มีการขอความยินยอมจากผู้ใช้อย่างชัดเจน
แถม passim ยังใช้ GnuTLS ซึ่งขึ้นชื่อว่ามีรูรั่วเยอะยิ่งกว่าชีสสวิส 2
ผมมองว่ามันเหลือเชื่อจริง ๆ และคงไม่แปลกใจถ้ามี exploit แบบ xz ซ่อนอยู่ตรงไหนสักแห่งในเชนนี้
- ไม่จำเป็นต้องไปไกลถึง fwupd ด้วยซ้ำ
  systemd-resolved ที่มีอยู่แทบทุกที่สามารถเปิดเซิร์ฟเวอร์ LLMNR บนพอร์ต 5355 ตามคำขอได้ หรือพูดอีกอย่างคือ mDNS ที่เรียกกันเช่นนั้น และเป็นสายตระกูล Microsoft NetBIOS แบบเก่า
  เพราะยุคนี้ทุกคนเข้าถึง LAN ของผมได้จากพวกอุปกรณ์ IoT กันหมดแล้ว ตอนนี้ก็เลยกำลังพา Linux เข้าร่วมความเละเทะนั้นด้วย
  
  การแก้ fwupd ทำได้แบบนี้ เพราะคุณภาพไฟล์ตั้งค่าเริ่มต้นต่ำและไม่มีค่าเริ่มต้นที่คอมเมนต์ไว้:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  ส่วนการแก้ resolved นั้น LLMNR=no ถูกคอมเมนต์ไว้ใน /etc/systemd/resolved.conf และคุณอาจต้องการ DNSStubListener=no ด้วย
  ค่าเริ่มต้นที่พอใช้ได้มีดังนี้:
```
# /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no  
```
- ดีเลยที่ได้รู้
  คิดว่าเรื่องนี้น่าจะตั้งเป็นโพสต์แยกต่างหากได้ด้วย
ผู้ดูแลแพ็กเกจควรยึดตาม หลักการไม่ทำให้ผู้ใช้ประหลาดใจเกินจำเป็น และไม่ควรปิดฟังก์ชันหลัก เว้นแต่จะมีการบันทึกไว้หรืออย่างน้อยไม่มีความเสี่ยงที่ดูสมเหตุสมผล
ในส่วนคอมเมนต์นี้มีคำว่า “ปลั๊กอิน” ปรากฏอยู่ตอนนี้ 25 ครั้ง แต่สิ่งที่พูดถึงที่นี่ไม่ใช่ปลั๊กอิน
KeePassXC มีฟีเจอร์มากมาย แต่ดูเหมือนไม่มีอะไรที่เป็นแหล่งช่องโหว่สำคัญได้ด้วยตัวมันเองโดยไม่มีการกระทำจากผู้ใช้อย่างชัดเจน
การเชื่อมต่อกับเบราว์เซอร์ต้องเปิดใช้งานก่อนจึงจะตั้งค่าได้ และฟีเจอร์อื่นที่ถูกปิดด้วยแฟล็กนี้ก็น่าจะเช่นเดียวกัน ดังนั้นแพ็กเกจ -minimal น่าจะเหมาะสมกว่า
ความไม่สะดวกอย่างรุนแรงที่จะเกิดกับคนที่ใช้การเชื่อมต่อกับเบราว์เซอร์นั้นมีมากกว่าผู้ใช้จำนวนน้อยมากที่อาจได้ประโยชน์จากการเปลี่ยนแปลงนี้ในอนาคตที่ยังไม่แน่นอน
โดยทั่วไปแล้วการเชื่อมต่อกับเบราว์เซอร์ยังเป็นฟีเจอร์ที่ปลอดภัยกว่าการเข้าถึงคลิปบอร์ดมาก
และก็ดูไม่สอดคล้องกับวิสัยทัศน์ของโครงการด้วย:

เป้าหมายคือการสร้างแอปพลิเคชันที่ทุกคนใช้ได้ และยังมีฟีเจอร์ขั้นสูงให้สำหรับผู้ที่ต้องการ
การแยกแบบนี้สามารถทำได้โดยไม่ทำให้ผู้ใช้เดิมใช้งานไม่ได้ ดังนั้นจึงยากจะมองเป็นอย่างอื่นนอกจากว่าเป็น การตัดสินใจที่แย่ ของผู้ดูแลแพ็กเกจ Debian
แน่นอนว่าการมี KeepassXC แบบไม่มีฟังก์ชันเครือข่ายให้ใช้ก็เป็นเรื่องดี แต่การมองว่าการเชื่อมต่อกับเบราว์เซอร์เป็นฟีเจอร์เฉพาะกลุ่มนั้นห่างไกลจากความเป็นจริงอย่างมาก
ฉันกล้าพนันได้เลยว่าผู้ใช้ KeepassXC บน Debian มากกว่าครึ่งหนึ่ง และน่าจะมากกว่านั้นมาก ต้องการฟีเจอร์ที่จะถูกปิดแบบไม่บอกล่วงหน้าจากวิธีนี้
สุดท้ายอำนาจตัดสินใจเป็นของพวกเขา แต่ไม่ได้แปลว่าเป็นการตัดสินใจที่ดี และฉันมองว่าไม่ใช่
คำพูดจากผู้ดูแล KeePassXC:

ก่อนที่เธรดนี้จะเริ่ม ฉันได้รับรายงานแล้วสามกรณีว่ารูปแบบการแพ็กเกจใหม่นี้ทำลายเวิร์กโฟลว์ของผู้คน หนึ่งในนั้นคือผู้ใช้ที่เปิดฐานข้อมูลไม่ได้อีกต่อไปเพราะฟังก์ชัน yubikey ถูกถอดออก ลองคิดดูสักครู่ เมื่อคนไม่สามารถเข้าถึงความลับที่สำคัญที่สุดของตนได้ พวกเขาอาจตื่นตระหนกและทำสิ่งที่ไม่สมเหตุสมผลได้ในบางครั้ง

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- หากใช้ตัวจัดการรหัสผ่านแบบออฟไลน์แล้ว ไม่มีแบ็กอัป ก็ถือว่าเหมือนทำทุกอย่างหายไปหมดแล้ว
  ฟังดูเหมือนการบีบคั้นทางอารมณ์
  ไม่รู้เหมือนกันว่าฉันเคยสูญเสียทุกอย่างไปกี่ครั้งจากฮาร์ดแวร์พัง อัปเดตที่ทำให้ระบบปฏิบัติการพัง หรือใช้ dd กับไดรฟ์ผิดลูก
ถ้าผู้ดูแลดาวน์สตรีมจะเปลี่ยนแพ็กเกจในแบบที่ต่างจากเจตนาของโครงการอัปสตรีม ก็ควรแจกจ่ายภายใต้ ชื่ออื่น และรับมือรายงานบั๊กทั้งหมดที่เกิดจากเวอร์ชันดัดแปลงนั้นเอง
- บิลด์ค่าเริ่มต้นปิด networking ไว้
  Yubikey, การเชื่อมต่อกับเบราว์เซอร์ และอย่างอื่นก็เช่นเดียวกัน
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- ตัวเลือกบิลด์ WITH_XC_NETWORKING ถูกปิดไว้โดยค่าเริ่มต้น ดังนั้นชัดเจนว่านักพัฒนาตั้งใจให้การตั้งค่านี้เป็น การตั้งค่าบิลด์ที่ใช้ได้
- แม้จะรู้ว่าโดยทั่วไปมักไม่ค่อยมีใครทำตาม แต่เดิมทีขั้นตอนก็ควรเป็นแบบนั้น
  ถ้าใช้แพ็กเกจที่ดิสทริบิวชันจัดมาให้แล้วพบบั๊ก ก็ควรเปิดบั๊กกับแพ็กเกจของดิสทริบิวชันก่อน แล้วผู้ดูแลจะตรวจดู และหากเป็นบั๊กจากอัปสตรีมจริงจึงค่อยส่งต่อไปยังโครงการอัปสตรีม
  เหตุผลที่วิธีนี้มีประโยชน์คือ 1. ผู้ดูแลแพ็กเกจคุ้นเคยกับแพ็กเกจนั้นและช่วยคัดแยกกับวิเคราะห์เบื้องต้นได้ หรืออาจแก้ได้ทันทีตั้งแต่ก่อนส่งไปอัปสตรีม และ 2. อย่างที่บอก แพ็กเกจจากดิสทริบิวชันมักมีแพตช์รวมอยู่ด้วย ดังนั้นผู้ดูแลต้องตรวจว่าปัญหาอยู่ที่แพ็กเกจจิ้งหรืออยู่ในซอร์สของอัปสตรีม
  น่าเสียดายที่ผู้ใช้จำนวนมากมักรายงานไปที่อัปสตรีมก่อน
  เพราะอย่างนั้นในทางปฏิบัติก็น่ากังวลอยู่ แต่โดยหลักแล้วไม่ควรเป็นแบบนั้น
- หรือไม่ก็ต้องทำเครื่องหมายให้ผู้ใช้ปลายทางรู้ว่าเป็น แพ็กเกจที่ไม่รองรับ
  เช่น ทำให้เห็นเป็น KeePassXC-Debian หรือ KeePassXC-Unsupported และในหน้า About ก็เอาช่องทางติดต่อหรือเว็บไซต์ของนักพัฒนาออก แล้วเปลี่ยนเป็นข้อมูลการสนับสนุนของ Debian แทน
  การเปลี่ยนแปลงเล็กน้อยฝั่งดาวน์สตรีมเพื่อให้เข้ากับระบบปฏิบัติการนั้นพอรับได้
  แต่การดัดแปลงแอปเพื่อตัดฟังก์ชันหลักออก แล้วทำให้นักพัฒนาอัปสตรีมต้องรับคำร้องเรียนจำนวนมหาศาลนั้นไม่โอเค
- ไม่เข้าใจว่าทำไมถึงมาคอมเมนต์ทั้งที่ยังไม่ได้อ่านโพสต์ยาว 200 ตัวอักษรที่ลิงก์ไว้
  ผู้ดูแลได้เปิดปลั๊กอินทั้งหมดรวมถึงส่วนที่เกี่ยวกับเครือข่ายไว้ในแพ็กเกจ keepassxc-full แล้ว และแพ็กเกจ keepassxc จะมีเฉพาะฟังก์ชันพื้นฐานที่มี สถานะความปลอดภัย ดีกว่ามาก
  เรื่องนี้ชัดเจนว่าโอเคโดยสมบูรณ์และอยู่ในขอบเขตอำนาจของผู้ดูแล
  ข้อไม่พอใจทั้งหมดคือสิ่งนี้เป็นการเปลี่ยนแปลง
สำหรับคนที่สนใจ ดูเหมือนอิชชูนี้บน GitHub จะมีคอมเมนต์ล่าสุดอยู่

https://github.com/keepassxreboot/keepassxc/issues/10725
- มุมมองของผู้ดูแล Debian อย่าง Julian Klode ค่อนข้าง แข็งกร้าว:
  
  น่าเสียดาย แต่คงไม่เป็นแบบนั้น การคอมไพล์และแจกจ่ายปลั๊กอินทั้งหมดเป็นค่าเริ่มต้นนั้นเป็นความผิดพลาด คงจะเจ็บปวดอยู่ราวหนึ่งปีเพราะผู้ใช้ไม่ยอมอ่านไฟล์ NEWS ที่ควรอ่านอย่างน่าหงุดหงิด แต่แทบไม่มีอะไรที่เราจะทำได้
  
  เป็นความรับผิดชอบของเราที่ต้องมอบตัวเลือกที่ปลอดภัยที่สุดเท่าที่เป็นไปได้ให้เป็นค่าเริ่มต้น ฟีเจอร์เหล่านี้ทั้งหมดไม่จำเป็น และจริง ๆ แล้วไม่ควรอยู่ในตัวจัดการฐานข้อมูลรหัสผ่านแบบโลคัลเลย ทิศทางการพัฒนาทั้งหมดนี้ผิดตั้งแต่ต้นจนจบ
  
  ผู้ใช้ที่ต้องการขยะพวกนี้ก็ไปติดตั้งเวอร์ชันขยะได้ แต่แน่นอนว่านั่นจะเพิ่มความเสี่ยงจากการโจมตีแบบผู้มีส่วนร่วมที่ผ่านทางมา
หัวข้อผิด
โพสต์ต้นฉบับบอกว่าผู้ดูแลลบไม่ใช่แค่ฟังก์ชันเครือข่าย แต่ลบ ทุกฟังก์ชัน และนั่นก็ถูกต้อง เพราะฟังก์ชันทางเลือกทั้งหมด แม้แต่ฟังก์ชันที่ออฟไลน์โดยสมบูรณ์ ก็ถูกปิดตอนบิลด์ด้วย