Pengelola Debian KeePassXC Menghapus Semua Fitur Jaringan

(fosstodon.org/@keepassxc)

1 poin oleh GN⁺ 2024-05-12 | 1 komentar | Bagikan ke WhatsApp

Jika paket keepassxc di Debian diubah menjadi paket fitur minimal, pengguna yang ingin mempertahankan fitur yang ada harus beralih ke keepassxc-full
Cakupan penghapusan tidak hanya jaringan, tetapi juga mencakup YubiKey, auto-type, integrasi browser, SSH agent, FDO secrets, pengunduhan favicon, hingga HIBP
Deskripsi paket Debian menyatakan bahwa keepassxc bawaan hanya menyediakan “bare minimal functionality”, dan mengklasifikasikan networking, SSH agent, plugin browser, serta FDO secret storage sebagai kompleksitas dari sisi keamanan
Pengumuman perubahan disampaikan melalui NEWS.Debian.gz dan apt-listchanges; pengguna stable perlu memeriksa catatan rilis
Nama paket dan cara transisi masih mungkin disesuaikan, dan setelah Trixie ada opsi yang dibahas agar apt install keepassxc menampilkan dua pilihan

Perubahan Paket Debian `keepassxc`

Team KeePassXC memberi tahu pengguna Debian bahwa pengelola paket keepassxc berencana menghapus banyak fitur secara besar-besaran
Jika perubahan ini diterapkan di luar testing/sid, pengguna yang membutuhkan fitur yang ada harus beralih ke keepassxc-full
Laporan bug Debian tampak seperti menonaktifkan networking, tetapi Team KeePassXC membantah bahwa perubahan sebenarnya lebih dekat ke penghapusan seluruh fitur, bukan sekadar networking

Cakupan Fitur yang Dihapus

Menurut Team KeePassXC, target penghapusan adalah sebagai berikut
- YubiKey
- auto-type
- integrasi browser
- SSH agent
- FDO secrets
- networking
- pengunduhan favicon
- HIBP

Deskripsi Paket Debian dan Alasannya

Deskripsi paket keepassxc di Debian sid menjelaskan bahwa paket bawaan hanya mencakup fitur minimal
Deskripsi tersebut memandang networking, SSH agent, plugin browser, dan FDO secret storage sebagai kompleksitas dari sisi keamanan, dan menyarankan penggunaan keepassxc-full jika benar-benar diperlukan
Laporan bug Debian terkait yang dibagikan adalah #953529 - keepassxc: Compiling with disable networking support

Sikap Pengelola Debian

Pengelola Debian menyebut /usr/share/doc/<package>/NEWS.Debian.gz sebagai tempat pertama untuk memeriksa perubahan yang tidak terduga
Pengguna testing/unstable dapat melihat perubahan secara otomatis jika apt-listchanges terpasang, sedangkan pengguna stable harus membaca catatan rilis
Ia menjelaskan bahwa keputusan ini telah dibahas selama 1 tahun, dan setelah insiden xz-utils arahnya condong ke pengurangan sebanyak mungkin kode yang disertakan secara default
Pengelola tidak melihat adanya irisan besar antara kelompok pengguna yang sekaligus menginginkan Debian, KeePassXC, dan password manager dengan banyak fitur
Ia menyatakan bahwa memasukkan “lubang” ke password manager yang hanya lokal itu tidak masuk akal

Masalah Komunikasi antara Upstream dan Downstream

Seorang pengguna mempermasalahkan bahwa meski diskusi sudah berlangsung lama, para pengembang upstream tampak benar-benar terkejut
Pengelola Debian menjawab bahwa ini adalah urusan internal proyek Debian, dan ia telah meminta pendapat developer Debian lain di IRC
Ia menjelaskan bahwa posisi upstream sudah diketahui, upstream telah meninggalkan IRC beberapa tahun lalu, dan memaketkan versi baru saja sudah menguras energi
Team KeePassXC dan sebagian pengguna khawatir keputusan downstream ini dapat membuat laporan bug dan kebingungan menumpuk di upstream

Nama Paket dan Arah Transisi

Beberapa pengguna menyarankan agar, alih-alih mengubah keepassxc bawaan menjadi paket fitur minimal, lebih tidak membingungkan jika menggunakan nama seperti keepassxc-minimal atau keepassxc-light dan mempertahankan fitur penuh pada keepassxc yang ada
Salah satu usulannya adalah struktur berikut
- keepassxc-light
- keepassxc-full
- keepassxc menjadi paket transisi yang bergantung pada keepassxc-full
- Menjelaskan perubahan melalui NEWS.Debian
Pengelola Debian menjawab bahwa perubahan nama bergantung pada persetujuan ftpteam, dan untuk paket transisi Trixie, arah usulan itu mungkin yang terbaik
Setelah Trixie, opsi untuk menghapus paket transisi dan membuat apt install keepassxc menampilkan dua pilihan juga dibahas

1 komentar

GN⁺ 2024-05-12

Komentar Hacker News

Mendistribusikan perangkat lunak dengan nama yang sama setelah menghapus secara besar-besaran fitur yang dimasukkan upstream ke dalamnya, paling baik pun terlihat mencurigakan
Kalau ingin mengambil arah ini, seharusnya didistribusikan sebagai fork dengan nama berbeda, supaya upstream tidak terus direpotkan oleh laporan masalah dari pengguna
Ini mengingatkan pada dulu ketika maintainer Chromium Debian secara sepihak menonaktifkan fitur instalasi ekstensi, lalu akhirnya patch itu dibatalkan
Juga teringat kejadian jauh lebih lama ketika Debian menghapus antarmuka kernel untuk memuat firmware biner ke kartu jaringan sehingga jaringan saya rusak
- Yang sebenarnya dilakukan hanyalah mengubah parameter build XC_ALL menjadi OFF [0], dan nilai ini juga merupakan default di CMakeLists.txt upstream 1
  Kalau upstream menganggap fitur ini sepenting itu, mereka harus memperbaiki default-nya terlebih dahulu
  Pengguna bisa saja bingung karena fitur berhenti bekerja setelah upgrade, tetapi paket tanpa sufiks yang sesuai dengan default upstream pada dasarnya cukup masuk akal
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- Peran maintainer lebih dari sekadar menyalin-tempel upstream
  Mereka berhak menilai apa yang tepat bagi pengguna akhir distribusi
  Dalam kasus ini tampaknya ada alasan keamanan yang masuk akal, dan paket alternatif juga disediakan
- Debian sepertinya satu-satunya distro dengan sikap aneh yang mengabaikan upstream
  Pada dua proyek upstream yang saya kelola pun, Debian secara sepihak mengganti nama paketnya
  Yang satu baru saya ketahui jauh kemudian, dan yang lain tetap dilakukan dengan cara yang benar-benar tidak masuk akal meskipun saya secara eksplisit menentangnya
  Pada akhirnya sayalah yang harus menjelaskannya kepada pengguna
  
  Sunting: Anda bisa melihat arogansi Julian dari pihak Debian di sini: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — inilah yang saya maksud
- Mereka tidak “mencungkil” sesuatu yang dibuat upstream
  Mereka mendistribusikan versi tanpa plugin, dan membuat versi -full yang menyertakan plugin
  Kalau plugin sudah tertancap secara default, itu bukan plugin melainkan fitur bawaan, dan pendekatan ini tepat
- Kalau Apple mengatakan “kami memodifikasi aplikasi Anda karena menurut kami lebih baik dari sisi keamanan,” orang-orang pasti sudah keluar membawa obor dan garpu rumput
  Namun ketika maintainer deb yang melakukannya, ini menjadi bahan perdebatan
  Jika ada masalah keamanan, versi yang tidak aman seharusnya sama sekali tidak disediakan, tetapi dalam kasus ini pun bukan itu yang terjadi
  Di dunia seperti App Store, peran maintainer harus berubah
  Tugasnya adalah membuat perangkat lunak berjalan di distribusi, bukan membuat fork semu sesuai selera sendiri sambil mempertahankan namanya
Ini terlihat seperti keputusan yang cukup masuk akal
Fitur jaringan dan integrasi browser adalah lubang potensial besar sekaligus titik masuk serangan
Jika hanya menjalankan basis data tepercaya tanpa fitur terkait jaringan, meski ditemukan kerentanan pun alat itu seharusnya hampir mustahil disalahgunakan, dan itu sifat yang sangat diinginkan untuk alat sepenting pengelola kata sandi
Maintainer aslinya juga setuju 1
Paket lengkap dengan jaringan aktif juga ada di Debian, jadi pengguna yang menginginkannya cukup menjalankan apt install keepassxc-full untuk memakai semua fitur jaringan
Namun menyebut upstream “crappy”[0] bukan sikap yang produktif sebagai maintainer paket, dan nama paket keepassxc-lite serta keepassxc-full mungkin akan lebih mudah dipahami pengguna Debian daripada keepassxc dan keepassxc-full

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

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Banyak hal merupakan lubang potensial besar sekaligus titik masuk serangan, dan pada saat yang sama juga berguna
  “Kegunaan” bisa meningkatkan keamanan
  Sebab jika pengelola kata sandi sulit digunakan, orang akan berhenti memakainya
  Setelah melihat lebih jauh, belum jelas juga apakah penggunaan clipboard pasti lebih aman daripada integrasi browser
  Kesalahan copy/paste saja bisa mengimbangi sebagian besar beban keamanan dari integrasi browser
  Dulu saya pernah mengerjakan kontrak di sebuah perusahaan besar; laptop para account manager memiliki kata sandi enkripsi disk, kata sandi login Windows, dan kata sandi login AD, semuanya harus berbeda, harus diganti tiap beberapa bulan, dan persyaratan kompleksitasnya juga berat
  Pada setiap laptop yang saya lihat, tanpa kecuali, ada Post-it berisi ketiga kata sandi itu
  Intinya, keamanan ala penggila keamanan yang hipotetis tidak sama dengan keamanan nyata di lapangan
  Setidaknya tidak selalu sama, dan di sini diperlukan kompromi nyata

1: Kami sebagai kontraktor eksternal pernah melakukan pemeliharaan laptop sebagian karyawan
Sebenarnya itu tidak boleh, tetapi lewat sistem IT perusahaan akan terlalu lama karena birokrasi, jadi cara itu jauh lebih cepat dan mudah
Memang perusahaan tipe seperti itu
Hal itu sendiri tentu saja juga merupakan “risiko keamanan”, karena teknisi acak dari toko komputer seharusnya memang tidak menangani laptop berisi data perusahaan yang sangat rahasia
Namun menurut saya tidak banyak yang perlu dilindungi. Hanya sekitar angka penjualan/pelanggan, dan itu informasi yang hanya berguna bagi sangat sedikit orang

Integrasi browser punya satu sisi yang meningkatkan keamanan dibanding salin/tempel manual
Ekstensi browser memeriksa URL halaman sebelum mengisi kredensial, sedangkan salin/tempel manual rentan terhadap domain salah ketik atau phishing dengan karakter homograf
Saya setuju bahwa fitur jaringan dan integrasi browser adalah lubang potensial besar, tetapi seperti yang dikatakan para peserta di issue GitHub, poin pentingnya adalah pengujian build yang diperkecil hampir tidak ada dibanding build penuh, dan kombinasi flag build sembarang sama sekali tidak diuji
Seperti yang juga disebutkan di tempat lain, salah satu flag “opsional” yang dinonaktifkan adalah dukungan yubikey, dan karena ini pengguna yang meng-upgrade ke paket baru yang rusak menjadi terkunci dari password manager mereka
Mengaktifkan kembali satu flag itu saja sudah membuatnya berada dalam kondisi yang pada praktiknya tidak diuji siapa pun
Dengan asumsi pengguna lama dipindahkan ke keepassxc-full, saya setuju bahwa nama keepassxc-lite akan mencegah masalah
Namun justru itulah intinya
Menjadikan solusi paling aman sebagai default itu masuk akal, tetapi maintainer tidak boleh merusak fitur yang sudah ada kecuali upstream atau pengguna menginginkannya, terutama jangan sampai membuat pengguna terkunci dari password manager mereka
Menulis “crappy” di GitHub itu sangat tidak sopan, sampai-sampai kalau saya pengguna Debian, saya akan mempertimbangkan ulang pemakaiannya
Kalau paket itu penuh dengan fitur buruk seperti itu, saya tidak mengerti kenapa repot-repot memeliharanya
Lebih baik hapus saja dan biarkan pengguna mencari sendiri cara memasangnya dengan benar
Saya kasihan pada para pengembang KeepassXC; memelihara proyek open source saja sudah sulit, masih harus menghadapi hal seperti ini
Begitu melihat ungkapan crappy, rasa hormat saya kepada julian-klode langsung hilang
Solusi yang diusulkan drawks jelas terlihat sebagai pilihan yang benar:

Solusi yang tepat mungkin adalah memaketkan baik versi "-full" maupun "-minimal" dari software tersebut, mendefinisikan relasi Conflicts antara kedua paket melalui field metadata paket Debian, menandai keduanya agar Provides keepassxc, dan pada build -full juga menambahkan tag Replaces: keepassxc. Dengan begitu, saat upgrade paket, pengguna lama akan mendapatkan versi yang tetap menyediakan fitur dari paket yang di-upgrade/diganti, sedangkan pengguna baru bisa memilih sendiri versi yang ingin dipasang

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

Saya tidak mengerti kenapa ini bisa bukan opsi yang jelas
- Karena maintainer punya pandangannya sendiri, dan secara eksplisit ingin mengubah default
- Itu bukan hanya pilihan yang jelas, tetapi di Debian sebenarnya terjadi persis seperti itu: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  Tulisan aslinya hanyalah clickbait yang ditulis buruk
  Tidak ada yang dihapus; hanya dipindahkan ke paket keepassxc-full
Sementara itu di sisi Arch, paket fwupd yang mungkin cukup umum terpasang di basis penggunanya diam-diam dibuat bergantung pada passim, dan passim menjalankan server web terbuka di 0.0.0.0:275001 tanpa persetujuan eksplisit pengguna
Selain itu, passim menggunakan GnuTLS yang terkenal punya lubang lebih banyak daripada keju Swiss 2
Menurut saya ini benar-benar keterlaluan, dan saya tidak akan kaget kalau ada exploit tipe xz yang tersembunyi di suatu tempat dalam rantainya
- Tidak perlu sampai mencari fwupd
  systemd-resolved yang ada di mana-mana bisa membuka server LLMNR pada port 5355 saat diminta, alias mDNS, yang juga merupakan bagian dari keluarga Microsoft NetBIOS lama
  Di era ketika semua orang bisa mengakses LAN saya karena Internet of Things, kini Linux juga dibuat ikut masuk ke kekacauan itu
  
  Perbaikan untuk fwupd: file konfigurasi default-nya berkualitas rendah dan tidak ada nilai default yang dikomentari, jadi lakukan seperti ini:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  Perbaikan untuk resolved: di /etc/systemd/resolved.conf, LLMNR=no dikomentari, dan Anda mungkin juga menginginkan DNSStubListener=no
  Default yang masuk akal seperti ini:
```
# /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  
```
- Bagus untuk diketahui
  Sepertinya ini layak dijadikan postingan tersendiri
Pengelola paket seharusnya bertindak sesuai prinsip least surprise, dan tidak menonaktifkan fitur inti kecuali ada risiko yang terdokumentasi atau setidaknya masuk akal
Di bagian komentar ini kata “plugin” saat ini muncul 25 kali, tetapi yang dibicarakan di sini bukan plugin
KeePassXC memang punya banyak fitur, tetapi tampaknya tidak ada yang dengan sendirinya, tanpa tindakan eksplisit dari pengguna, kemungkinan besar menjadi sumber kerentanan
Integrasi browser harus diaktifkan dulu sebelum dikonfigurasi, dan fitur-fitur lain yang dinonaktifkan oleh flag ini mungkin juga demikian, jadi paket -minimal akan lebih tepat
Ketidaknyamanan besar bagi orang-orang yang memakai integrasi browser jauh lebih besar daripada segelintir kecil pengguna yang mungkin mendapat manfaat dari perubahan ini di masa depan yang tidak pasti
Integrasi browser juga umumnya merupakan fitur yang jauh lebih aman daripada akses clipboard
Ini juga tampaknya tidak sejalan dengan visi proyek:

Tujuannya adalah membuat aplikasi yang bisa digunakan siapa saja, sekaligus menyediakan fitur lanjutan bagi mereka yang membutuhkannya
Karena pemisahan ini bisa dibuat tanpa merusak pengguna yang sudah ada, sulit melihatnya selain sebagai keputusan buruk dari pengelola paket Debian
Jelas bagus jika bisa memakai KeepassXC tanpa fitur jaringan, tetapi menganggap integrasi browser sebagai fitur niche itu sangat jauh dari kenyataan
Saya berani bertaruh lebih dari separuh pengguna KeepassXC di Debian saat ini, mungkin jauh lebih banyak, menginginkan fitur yang akan dinonaktifkan tanpa pemberitahuan karena cara ini
Pada akhirnya keputusan memang ada di tangan mereka, tetapi itu tidak berarti keputusannya bagus, dan menurut saya bukan
Perkataan pengelola KeePassXC:

Sebelum thread ini dimulai, kami menerima tiga laporan bahwa cara packaging baru ini merusak alur kerja orang. Salah satunya adalah pengguna yang fitur yubikey-nya dihapus sehingga tidak bisa lagi membuka database. Coba pikirkan sebentar. Orang yang tidak bisa mengakses rahasia paling pentingnya bisa panik dan kadang bertindak tidak rasional

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Kalau memakai pengelola kata sandi offline dan tidak punya backup, anggap saja semuanya sudah hilang
  Ini terdengar seperti pemerasan emosional
  Entah sudah berapa sering orang kehilangan semuanya karena kegagalan hardware, pembaruan yang merusak sistem operasi, memakai dd pada drive yang salah, dan sebagainya
Jika pengelola downstream ingin mengubah paket dengan cara yang berbeda dari maksud proyek upstream, menurut saya paket itu harus didistribusikan dengan nama lain dan mereka sendiri harus menangani semua laporan bug yang muncul akibat versi modifikasi tersebut
- Build default mematikan networking
  Begitu juga Yubikey, integrasi browser, dan lainnya
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- Opsi build WITH_XC_NETWORKING secara default dimatikan, jadi jelas para developer memang memaksudkan konfigurasi ini sebagai pengaturan build yang valid
- Saya tahu ini biasanya tidak dipatuhi dengan baik, tetapi alur dasarnya memang begitu
  Jika memakai paket dari distribusi lalu menemukan bug, seharusnya bug dibuka pada paket distribusi, lalu pengelola memeriksanya dan, jika bug itu berasal dari upstream, meneruskannya ke proyek upstream
  Cara ini berguna karena 1. pengelola paket akrab dengan paket tersebut sehingga bisa melakukan triase dan analisis awal, bahkan mungkin langsung memperbaikinya sebelum sampai ke upstream, dan 2. seperti disebutkan, paket distribusi sering menyertakan patch, sehingga pengelola harus memastikan apakah masalahnya ada pada packaging atau pada source upstream
  Sayangnya banyak pengguna melapor lebih dulu ke upstream
  Jadi secara realistis ini memang layak dikhawatirkan, tetapi seharusnya tidak begitu
- Atau paket itu harus ditandai kepada pengguna akhir sebagai paket yang tidak didukung
  Misalnya ditampilkan sebagai KeePassXC-Debian atau KeePassXC-Unsupported, dan di About informasi kontak developer atau situs web dihapus lalu diganti dengan informasi dukungan Debian
  Perubahan kecil downstream untuk menyesuaikan dengan sistem operasi itu boleh saja
  Namun memodifikasi aplikasi untuk menghapus fitur inti dan membuat developer upstream menerima banyak sekali keluhan itu tidak boleh
- Saya tidak tahu kenapa orang berkomentar tanpa membaca tulisan 200 karakter yang ditautkan itu
  Pengelola menyalakan semua plugin, termasuk yang terkait jaringan, di paket keepassxc-full, sementara paket keepassxc hanya berisi fitur dasar dengan postur keamanan yang jauh lebih baik
  Ini jelas sepenuhnya baik-baik saja dan berada dalam wewenang pengelola
  Seluruh keluhannya adalah bahwa ini merupakan perubahan
Bagi yang berminat, issue di GitHub ini tampaknya memuat komentar-komentar terbaru

https://github.com/keepassxreboot/keepassxc/issues/10725
- Pandangan pengelola Debian Julian Klode cukup tajam:
  
  Maaf, tetapi itu tidak akan terjadi. Membangun dan mendistribusikan semua plugin secara default adalah kesalahan. Karena pengguna secara menjengkelkan tidak membaca file NEWS yang seharusnya mereka baca, ini akan menyakitkan selama sekitar satu tahun, tetapi hampir tidak ada yang bisa dilakukan.
  
  Tanggung jawab kami adalah memberikan opsi paling aman yang mungkin kepada pengguna sebagai default. Semua fitur ini tidak perlu dan sebenarnya tidak termasuk dalam pengelola database kata sandi lokal. Seluruh arah pengembangan seperti ini benar-benar keliru.
  
  Pengguna yang membutuhkan sampah ini bisa memasang versi sampahnya, tetapi tentu saja itu meningkatkan risiko serangan dari kontributor sambil lalu.
Judulnya salah
Tulisan aslinya mengatakan pengelola menghapus bukan hanya fitur jaringan, melainkan semua fitur, dan itu memang benar karena semua fitur opsional, bahkan fitur yang sepenuhnya offline, dimatikan saat build