Người quản lý gói KeePassXC trên Debian loại bỏ mọi tính năng mạng

(fosstodon.org/@keepassxc)

1 điểm bởi GN⁺ 2024-05-12 | 1 bình luận | Chia sẻ qua WhatsApp

Khi gói keepassxc của Debian được chuyển thành gói chức năng tối thiểu, người dùng muốn giữ các tính năng hiện có sẽ phải chuyển sang keepassxc-full
Phạm vi bị loại bỏ không chỉ là mạng mà còn gồm YubiKey, auto-type, tích hợp trình duyệt, SSH agent, FDO secrets, tải favicon và HIBP
Mô tả gói Debian cho biết keepassxc mặc định chỉ cung cấp “bare minimal functionality”, đồng thời xếp mạng, SSH agent, plugin trình duyệt và kho bí mật FDO vào nhóm độ phức tạp về bảo mật
Thông báo thay đổi sẽ được gửi qua NEWS.Debian.gz và apt-listchanges, còn người dùng stable cần kiểm tra ghi chú phát hành
Tên gói và cách chuyển đổi vẫn còn có thể điều chỉnh, và sau Trixie có đề xuất để apt install keepassxc hiển thị hai lựa chọn

Thay đổi đối với gói `keepassxc` trên Debian

Team KeePassXC thông báo tới người dùng Debian rằng người quản lý gói keepassxc đang muốn cắt giảm mạnh các tính năng
Nếu thay đổi này được đưa ra ngoài testing/sid, người dùng cần các tính năng hiện có sẽ phải chuyển sang keepassxc-full
Báo cáo lỗi Debian trông như chỉ vô hiệu hóa mạng, nhưng Team KeePassXC phản bác rằng thay đổi thực tế gần với việc loại bỏ toàn bộ tính năng vượt quá mạng

Phạm vi các tính năng bị loại bỏ

Theo Team KeePassXC, các tính năng bị loại bỏ gồm:
- YubiKey
- auto-type
- tích hợp trình duyệt
- SSH agent
- FDO secrets
- mạng
- tải favicon
- HIBP

Mô tả gói Debian và lý do

Mô tả gói keepassxc trên Debian sid cho biết gói mặc định chỉ bao gồm chức năng tối thiểu
Mô tả này coi mạng, SSH agent, plugin trình duyệt và kho bí mật FDO là độ phức tạp về bảo mật, và hướng dẫn dùng keepassxc-full nếu thực sự cần
Báo cáo lỗi Debian liên quan được chia sẻ là #953529 - keepassxc: Compiling with disable networking support

Lập trường của người quản lý Debian

Người quản lý Debian cho biết nơi đầu tiên để kiểm tra các thay đổi bất ngờ là /usr/share/doc/<package>/NEWS.Debian.gz
Người dùng testing/unstable có thể tự động xem thay đổi nếu đã cài apt-listchanges, còn người dùng stable thì cần đọc ghi chú phát hành
Họ cho biết quyết định này đã được thảo luận suốt 1 năm, và sau sự cố xz-utils, xu hướng là giảm tối đa lượng mã được включено theo mặc định
Người quản lý cho rằng nhóm người dùng đồng thời muốn Debian, KeePassXC và một trình quản lý mật khẩu nhiều tính năng không thực sự chồng lấn lớn
Họ nói việc tạo một “lỗ hổng” trong một trình quản lý mật khẩu chỉ dùng cục bộ là điều không hợp lý

Vấn đề giao tiếp giữa upstream và downstream

Một người dùng cho rằng thật đáng lo khi cuộc thảo luận đã kéo dài lâu như vậy mà các nhà phát triển upstream lại có vẻ hoàn toàn bất ngờ
Người quản lý Debian trả lời rằng đây là vấn đề nội bộ của dự án Debian, và họ đã hỏi ý kiến các nhà phát triển Debian khác trên IRC
Họ giải thích rằng đã biết lập trường của upstream, nhưng upstream đã rời IRC từ vài năm trước và họ cũng không còn đủ năng lượng chỉ riêng cho việc đóng gói phiên bản mới
Team KeePassXC và một số người dùng lo ngại rằng quyết định từ downstream có thể khiến upstream bị dồn báo cáo lỗi và sự nhầm lẫn

Tên gói và hướng chuyển đổi

Nhiều người dùng đề xuất rằng thay vì biến keepassxc mặc định thành gói tối thiểu, nên dùng tên như keepassxc-minimal hoặc keepassxc-light, còn keepassxc hiện tại vẫn giữ đầy đủ tính năng để giảm bớt nhầm lẫn
Một đề xuất có cấu trúc như sau:
- keepassxc-light
- keepassxc-full
- keepassxc phụ thuộc vào keepassxc-full như một gói chuyển tiếp
- giải thích thay đổi bằng NEWS.Debian
Người quản lý Debian trả lời rằng việc đổi tên phụ thuộc vào phê duyệt của ftpteam, và với Trixie thì hướng gói chuyển tiếp có thể là phương án tốt nhất
Sau Trixie, cũng có phương án bỏ gói chuyển tiếp và để apt install keepassxc hiển thị hai lựa chọn

1 bình luận

GN⁺ 2024-05-12

Ý kiến trên Hacker News

Việc loại bỏ hàng loạt các tính năng mà upstream đã đưa vào phần mềm rồi phân phối dưới cùng một tên, nhìn theo hướng tích cực nhất thì cũng đáng ngờ
Nếu muốn đi theo hướng này thì nên phân phối dưới dạng một fork với tên khác, để upstream không tiếp tục bị làm phiền bởi các vấn đề do người dùng nêu ra
Việc này làm tôi nhớ đến chuyện trước đây maintainer Chromium của Debian đã đơn phương vô hiệu hóa tính năng cài đặt extension, rồi cuối cùng bản vá đó bị hoàn tác
Cũng nhớ đến chuyện còn lâu hơn nữa, khi Debian loại bỏ giao diện kernel dùng để tải firmware nhị phân cho card mạng, khiến mạng của tôi bị hỏng
- Thực ra việc họ làm chỉ là đổi tham số build XC_ALL sang OFF [0], và giá trị này cũng chính là mặc định trong CMakeLists.txt của upstream 1
  Nếu upstream coi tính năng này quan trọng đến vậy thì trước hết nên sửa giá trị mặc định
  Người dùng có thể bối rối vì tính năng ngừng hoạt động sau khi nâng cấp, nhưng việc gói không có hậu tố khớp với mặc định của upstream tự thân nó là khá hợp lý
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- Vai trò của maintainer không chỉ là sao chép và dán upstream
  Họ có quyền phán đoán điều gì là phù hợp với người dùng cuối của bản phân phối
  Trong trường hợp này có vẻ có cơ sở bảo mật hợp lý, và cũng có gói thay thế được cung cấp
- Debian có vẻ là bản phân phối duy nhất có thái độ kỳ lạ là phớt lờ upstream
  Ngay cả trong hai dự án upstream mà tôi quản lý, Debian cũng đã đơn phương đổi tên gói
  Một cái thì mãi về sau tôi mới biết, còn cái kia thì dù tôi phản đối rõ ràng, họ vẫn làm theo một cách hoàn toàn vô lý
  Cuối cùng người phải giải thích cho người dùng lại là tôi
  
  Sửa: có thể thấy sự ngạo mạn của Julian phía Debian ở đây: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — ý tôi nói chính là những chuyện như thế này
- Không phải là “cắt xén” thứ upstream tạo ra
  Họ phân phối phiên bản không có plugin và tạo ra phiên bản -full có kèm plugin
  Nếu plugin được cắm sẵn theo mặc định thì đó không còn là plugin nữa mà là tính năng tích hợp sẵn, và cách làm này là đúng
- Nếu Apple nói “chúng tôi đã sửa ứng dụng của bạn vì nghĩ như vậy an toàn hơn”, mọi người hẳn đã cầm đuốc và chĩa ba kéo đến
  Nhưng khi maintainer deb làm thì lại thành chuyện gây tranh luận
  Nếu có vấn đề bảo mật thì phiên bản không an toàn lẽ ra không nên được cung cấp ngay từ đầu, nhưng trường hợp này cũng không phải như vậy
  Trong một thế giới kiểu App Store, vai trò của maintainer cần phải thay đổi
  Việc cần làm là khiến phần mềm chạy được trong bản phân phối, chứ không phải giữ nguyên tên rồi tạo ra một fork gần giống theo sở thích của mình
Có vẻ là một quyết định khá hợp lý
Tính năng mạng và tích hợp trình duyệt là những lỗ hổng tiềm tàng lớn cũng như điểm vào cho tấn công
Nếu chỉ chạy một cơ sở dữ liệu đáng tin cậy mà không có các tính năng liên quan đến mạng, thì ngay cả khi phát hiện lỗ hổng, việc lạm dụng công cụ này cũng gần như phải là bất khả thi; đây là một đặc tính rất đáng mong muốn đối với công cụ quan trọng như trình quản lý mật khẩu
Maintainer ban đầu cũng đồng ý 1
Gói đầy đủ có bật mạng cũng có trong Debian, nên người dùng muốn dùng chỉ cần apt install keepassxc-full là có thể sử dụng mọi tính năng mạng
Tuy nhiên, gọi upstream là “crappy”[0] không phải là thái độ mang tính xây dựng đối với một maintainer gói, và tên gói keepassxc-lite và keepassxc-full có lẽ sẽ dễ hiểu hơn cho người dùng Debian so với keepassxc và keepassxc-full

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

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Rất nhiều thứ là lỗ hổng tiềm tàng lớn và điểm vào cho tấn công, đồng thời cũng hữu ích
  “Tính hữu ích” có thể tăng cường bảo mật
  Vì nếu trình quản lý mật khẩu khó dùng, mọi người sẽ ngừng sử dụng nó
  Xem kỹ hơn thì cũng không rõ việc dùng clipboard có nhất thiết an toàn hơn tích hợp trình duyệt hay không
  Chỉ riêng lỗi sao chép/dán cũng có thể bù trừ phần lớn gánh nặng bảo mật của tích hợp trình duyệt
  Ngày xưa tôi từng làm hợp đồng cho một công ty lớn; laptop của các quản lý tài khoản có mật khẩu mã hóa đĩa, mật khẩu đăng nhập Windows và mật khẩu đăng nhập AD, tất cả đều phải khác nhau, phải đổi vài tháng một lần, và yêu cầu độ phức tạp cũng rất nặng
  Trên mọi chiếc laptop tôi thấy, không ngoại lệ, đều có giấy note dán ghi cả ba mật khẩu
  Ý chính là kiểu bảo mật tưởng tượng của dân mê bảo mật không giống với bảo mật trong thực tế
  Ít nhất là không phải lúc nào cũng giống, và ở đây cần có sự đánh đổi thực sự

1: Chúng tôi, với tư cách nhà thầu bên ngoài, đã bảo trì laptop cho một số nhân viên
Lẽ ra không nên làm vậy, nhưng nếu đi qua hệ thống IT của công ty thì vì quan liêu nên mất quá nhiều thời gian, còn cách này nhanh và dễ hơn nhiều
Đó là kiểu công ty như vậy
Bản thân việc này dĩ nhiên cũng là một “rủi ro bảo mật”, vì về nguyên tắc một kỹ thuật viên bất kỳ ở cửa hàng máy tính không nên động vào laptop chứa dữ liệu tuyệt mật của công ty
Tuy vậy tôi nghĩ cũng không có quá nhiều thứ cần bảo vệ. Chủ yếu chỉ là số liệu kinh doanh/khách hàng, và là thông tin chỉ hữu ích với một nhóm người rất hạn chế

Tích hợp trình duyệt có một khía cạnh giúp tăng bảo mật so với việc sao chép/dán thủ công
Tiện ích mở rộng trình duyệt kiểm tra URL của trang trước khi điền thông tin xác thực, còn sao chép/dán thủ công thì dễ bị tấn công qua tên miền gõ nhầm hoặc phishing bằng ký tự đồng hình
Tôi đồng ý rằng tính năng mạng và tích hợp trình duyệt là những lỗ hổng tiềm tàng lớn, nhưng như những người tham gia trong issue trên GitHub đã nói, điều quan trọng là các bản build rút gọn hầu như không được kiểm thử so với bản build đầy đủ, và các tổ hợp cờ build tùy ý thì hoàn toàn không được kiểm thử
Như đã được nêu ở chỗ khác, một trong các cờ “tùy chọn” bị vô hiệu hóa là hỗ trợ yubikey, và vì thế người dùng nâng cấp lên gói mới bị hỏng đang bị khóa khỏi trình quản lý mật khẩu của họ
Chỉ cần bật lại riêng cờ đó thì thực tế cũng rơi vào trạng thái không ai kiểm thử
Nếu giả định người dùng hiện tại đã được chuyển sang keepassxc-full, tôi đồng ý rằng cái tên keepassxc-lite lẽ ra đã tránh được vấn đề
Nhưng đó chính là điểm mấu chốt
Lấy giải pháp an toàn nhất làm mặc định là hợp lý, nhưng maintainer không nên phá vỡ chức năng hiện có trừ khi upstream hoặc người dùng muốn vậy, và đặc biệt không được làm người dùng bị khóa khỏi trình quản lý mật khẩu của họ
Việc đăng từ “crappy” lên GitHub là quá thô lỗ, đến mức nếu tôi đang dùng Debian thì tôi đã cân nhắc lại việc sử dụng
Nếu gói đó đầy rẫy những tính năng tệ hại như vậy thì tôi không hiểu tại sao còn mất công duy trì nó
Thà bỏ hẳn đi và để người dùng tự tìm cách cài đặt đúng còn hơn
Tôi thấy tội cho các nhà phát triển KeepassXC; duy trì dự án mã nguồn mở vốn đã khó, lại còn phải chịu thêm chuyện này
Ngay khi thấy cách dùng từ crappy, tôi lập tức mất sự tôn trọng dành cho julian-klode
Giải pháp mà drawks đề xuất rõ ràng có vẻ là lựa chọn đúng:

Giải pháp phù hợp có lẽ là đóng gói cả hai phiên bản "-full" và "-minimal" của phần mềm, định nghĩa quan hệ Conflicts giữa hai gói bằng trường metadata của gói Debian, gắn nhãn để cả hai đều Provides keepassxc, và thêm cả nhãn Replaces: keepassxc cho bản build -full. Khi đó, trong quá trình nâng cấp gói, người dùng hiện tại sẽ nhận phiên bản tiếp tục cung cấp các tính năng của gói đang được nâng cấp/thay thế, còn người dùng mới có thể tự chọn phiên bản muốn cài

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

Tôi không hiểu vì sao đây lại có thể không phải là lựa chọn hiển nhiên
- Vì maintainer có quan điểm riêng, và đã nói rõ là muốn thay đổi mặc định
- Đó không chỉ là lựa chọn hiển nhiên, mà thực tế trong Debian đã diễn ra chính xác như vậy: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  Bài gốc chỉ là clickbait viết sai mà thôi
  Không có gì bị loại bỏ cả, chỉ được chuyển sang gói keepassxc-full thôi
Trong khi đó ở phía Arch, gói fwupd có lẽ được cài khá phổ biến trong nhóm người dùng, đã âm thầm được đặt phụ thuộc vào passim, và passim thì dựng một web server mở trên 0.0.0.0:275001 mà không có sự đồng ý rõ ràng của người dùng
Hơn nữa passim dùng GnuTLS, vốn nổi tiếng là có nhiều lỗ hổng hơn cả pho mát Thụy Sĩ 2
Tôi thấy thật vô lý, và sẽ không ngạc nhiên nếu ở đâu đó trong chuỗi này có ẩn một exploit kiểu xz
- Cũng không cần phải tìm đến fwupd
  systemd-resolved có mặt khắp nơi có thể, khi được yêu cầu, mở một server LLMNR trên cổng 5355, tức thứ còn được gọi là mDNS và thuộc dòng Microsoft NetBIOS ngày xưa
  Vì Internet of Things mà giờ ai cũng có thể truy cập LAN của tôi, và họ đang khiến Linux cũng tham gia vào mớ hỗn độn đó
  
  Cách sửa fwupd là như sau, vì file cấu hình mặc định chất lượng kém và thậm chí không có giá trị mặc định được comment sẵn:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  Cách sửa resolved là trong /etc/systemd/resolved.conf, đặt LLMNR=no vốn đang bị comment, và có lẽ bạn cũng sẽ muốn DNSStubListener=no
  Giá trị mặc định ổn nên như sau:
```
# /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  
```
- Rất đáng biết
  Tôi nghĩ chuyện này có thể được đăng thành một bài riêng
Người quản lý gói nên hành động theo nguyên tắc ít gây bất ngờ nhất, và không nên vô hiệu hóa các tính năng cốt lõi trừ khi có rủi ro đã được ghi nhận hoặc ít nhất là hợp lý
Trong phần bình luận này, từ “plugin” hiện xuất hiện 25 lần, nhưng thứ đang được nói đến ở đây không phải là plugin
KeePassXC có nhiều tính năng, nhưng dường như không có thứ gì tự thân nó, khi không có thao tác rõ ràng từ người dùng, lại là nguồn lỗ hổng có khả năng cao
Tích hợp trình duyệt phải được bật trước khi cấu hình, và các tính năng khác bị vô hiệu hóa bởi cờ này có lẽ cũng tương tự, nên một gói -minimal sẽ phù hợp hơn
Sự bất tiện nghiêm trọng đối với những người đang dùng tích hợp trình duyệt lớn hơn rất nhiều so với số cực nhỏ người dùng có thể được lợi từ thay đổi này trong một tương lai bất định
Tích hợp trình duyệt nhìn chung cũng là một tính năng an toàn hơn nhiều so với truy cập clipboard
Điều này dường như cũng không phù hợp với tầm nhìn của dự án:

Mục tiêu là tạo ra một ứng dụng mà ai cũng có thể sử dụng, đồng thời vẫn cung cấp các tính năng nâng cao cho những người cần chúng
Vì hoàn toàn có thể tạo ra sự phân tách này mà không làm hỏng trải nghiệm của người dùng hiện tại, thật khó xem đây là gì khác ngoài một quyết định tệ của người quản lý gói Debian
Việc có thể dùng KeepassXC không có chức năng mạng rõ ràng là tốt, nhưng coi tích hợp trình duyệt là một tính năng ngách thì quá xa rời thực tế
Tôi dám cá rằng hơn một nửa, có lẽ là nhiều hơn rất nhiều, người dùng KeepassXC trên Debian hiện nay muốn những tính năng sẽ bị vô hiệu hóa không báo trước theo cách làm lần này
Rốt cuộc quyền quyết định là của họ, nhưng điều đó không có nghĩa đây là một quyết định đúng, và tôi cho là không
Lời của người bảo trì KeePassXC:

Trước khi luồng này bắt đầu, chúng tôi đã nhận được ba báo cáo rằng cách đóng gói mới này đã phá hỏng quy trình làm việc của mọi người. Một trường hợp là người dùng không còn mở được cơ sở dữ liệu nữa vì chức năng yubikey đã bị gỡ bỏ. Hãy suy nghĩ một chút. Một người không truy cập được các bí mật quan trọng nhất của mình có thể hoảng loạn và đôi khi hành động phi lý trí

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Nếu dùng trình quản lý mật khẩu ngoại tuyến mà không có bản sao lưu, thì có thể coi như đã mất hết
  Điều này nghe giống như tống tiền cảm xúc
  Không biết đã bao nhiêu lần người ta mất tất cả vì hỏng phần cứng, bản cập nhật làm hỏng hệ điều hành, dùng dd nhầm ổ, v.v.
Nếu người bảo trì downstream muốn thay đổi gói theo cách khác với ý định của dự án upstream, tôi cho rằng họ nên phân phối nó dưới tên khác và tự xử lý mọi báo cáo lỗi phát sinh từ phiên bản đã sửa đó
- Bản build mặc định tắt networking
  Yubikey, tích hợp trình duyệt, v.v. cũng vậy
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- Tùy chọn build WITH_XC_NETWORKING mặc định bị tắt, nên rõ ràng các nhà phát triển đã chủ ý xem cấu hình này là một thiết lập build hợp lệ
- Tôi biết thông thường điều này không được tuân thủ tốt, nhưng luồng mặc định vốn là như vậy
  Nếu dùng gói do bản phân phối cung cấp và gặp lỗi, bạn nên mở lỗi với gói của bản phân phối; người bảo trì xem xét, rồi nếu đó là lỗi từ upstream thì mới đưa lên dự án upstream
  Cách này hữu ích vì 1. người quản lý gói quen thuộc với gói đó nên có thể phân loại và phân tích ban đầu, thậm chí có thể sửa ngay trước khi chuyển lên upstream, và 2. như đã nói, gói của bản phân phối thường chứa các bản vá, nên người bảo trì cần xác định vấn đề nằm ở khâu đóng gói hay ở mã nguồn upstream
  Đáng tiếc là nhiều người dùng lại báo cáo lên upstream trước
  Vì vậy trên thực tế đây là điều đáng lo, nhưng đúng ra thì không nên như vậy
- Hoặc phải hiển thị cho người dùng cuối rằng đây là gói không được hỗ trợ
  Ví dụ, hiển thị là KeePassXC-Debian hoặc KeePassXC-Unsupported, và trong About thì bỏ thông tin liên hệ hoặc website của nhà phát triển, thay bằng thông tin hỗ trợ của Debian
  Những thay đổi nhỏ ở downstream để phù hợp với hệ điều hành thì ổn
  Nhưng sửa ứng dụng để loại bỏ các tính năng cốt lõi và khiến nhà phát triển upstream hứng chịu vô số phàn nàn thì không ổn
- Tôi không hiểu vì sao lại bình luận mà thậm chí không đọc bài viết 200 ký tự được liên kết
  Người bảo trì đã bật tất cả plugin, bao gồm cả những thứ liên quan đến mạng, trong gói keepassxc-full, còn gói keepassxc chỉ chứa các tính năng mặc định với tư thế bảo mật tốt hơn nhiều
  Điều này rõ ràng là hoàn toàn ổn và nằm trong phạm vi quyền hạn của người bảo trì
  Toàn bộ phàn nàn nằm ở việc đây là một thay đổi
Với những ai quan tâm, issue này trên GitHub dường như có các bình luận mới nhất

https://github.com/keepassxreboot/keepassxc/issues/10725
- Quan điểm của Julian Klode, người bảo trì Debian, khá gay gắt:
  
  Rất tiếc, nhưng chuyện đó sẽ không xảy ra. Việc build và phân phối tất cả plugin theo mặc định là một sai lầm. Sẽ đau đớn trong khoảng một năm vì người dùng khó chịu đến mức không chịu đọc file NEWS mà họ đáng lẽ phải đọc, nhưng chúng ta gần như không thể làm gì hơn.
  
  Trách nhiệm của chúng ta là cung cấp cho người dùng tùy chọn an toàn nhất có thể làm mặc định. Tất cả các tính năng này đều không cần thiết và thực sự không thuộc về một trình quản lý cơ sở dữ liệu mật khẩu cục bộ. Toàn bộ hướng phát triển này là hoàn toàn sai lầm.
  
  Người dùng cần thứ rác rưởi này có thể cài phiên bản rác rưởi, nhưng đương nhiên điều đó làm tăng nguy cơ bị tấn công bởi contributor thoáng qua.
Tiêu đề sai
Bài gốc nói rằng người bảo trì đã gỡ bỏ không chỉ chức năng mạng mà tất cả các chức năng, và thực tế là mọi tính năng tùy chọn, kể cả các tính năng hoàn toàn ngoại tuyến, đều bị tắt trong quá trình build, nên nói như vậy là đúng