1 poin oleh GN⁺ 2024-10-21 | 2 komentar | Bagikan ke WhatsApp
  • Build Bitwarden Desktop 2024.10.0 kini memerlukan dependensi @bitwarden/sdk-internal, dan muncul isu bahwa ketentuan lisensi SDK tersebut membatasi penggunaan untuk “pengembangan aplikasi untuk perangkat lunak selain Bitwarden atau pengembangan SDK lain”, sehingga melanggar syarat perangkat lunak bebas
  • Pihak yang mengangkat masalah menyatakan pembatasan ini melanggar freedom 0 dari GNU, dan tanpa menghapus dependensi tersebut, desktop-v2024.10.0 maupun master saat ini tidak dapat dibangun
  • Sebagai kasus reproduksi, jika direktori bitwarden_license dihapus dan node_modules dibersihkan lalu dilakukan build, build:preload gagal dengan 6 error TS2307 karena tidak dapat menemukan @bitwarden/sdk-internal dan modul WASM
  • Beberapa komentar menunjukkan SDK dipakai bukan hanya di Desktop tetapi juga pada browser, CLI, dan web clients sebagai feature flag, sementara pihak Bitwarden menjawab bahwa SDK dan klien adalah program terpisah, dan komunikasi lewat protokol standar saja tidak membuatnya menjadi satu program dalam perspektif GPLv3
  • Bitwarden kemudian menyesuaikan susunan kode dan packaging SDK agar build yang hanya memuat lisensi GPL/OSI dapat dilakukan, lalu memindahkan referensi sdk-internal dari klien ke repositori baru sdk-internal dan menandai isu ini selesai

Masalah yang diajukan: build Desktop 2024.10.0 dan lisensi SDK

  • Isu ini dibuka dengan keberatan bahwa Bitwarden Desktop 2024.10.0 bukan lagi perangkat lunak bebas
  • Perubahan utamanya adalah pull request #10974 yang memperkenalkan dependensi @bitwarden/sdk-internal ke build klien desktop
  • Lisensi dependensi tersebut memuat pembatasan berikut
    • “SDK ini tidak boleh digunakan untuk pengembangan aplikasi bagi perangkat lunak selain Bitwarden, termasuk implementasi yang tidak kompatibel dengan Bitwarden, dan tidak boleh digunakan untuk pengembangan SDK lain”
  • Pihak pelapor menilai klausul ini melanggar freedom 0 dalam definisi perangkat lunak bebas GNU
  • Ia juga menyatakan bahwa tanpa menghapus dependensi ini, desktop-v2024.10.0, dan kemungkinan juga master saat ini, tidak dapat dibangun

Kegagalan build yang berhasil direproduksi

  • Pihak pelapor mencoba build dengan cara lama, yaitu menghapus direktori bitwarden_license dan menggunakan node_modules yang sudah dibersihkan
  • Build gagal pada tahap build:preload di apps/desktop
  • Error yang muncul adalah TS2307 di beberapa file karena modul @bitwarden/sdk-internal atau deklarasi tipenya tidak ditemukan
    • libs/common/src/platform/abstractions/sdk/sdk.service.ts
    • libs/common/src/platform/abstractions/sdk/sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/default-sdk.service.ts
    • libs/common/src/platform/services/sdk/default-sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/noop-sdk-client-factory.ts
  • Muncul juga error bahwa path WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm tidak dapat ditemukan
  • Akibatnya, webpack 5.94.0 gagal melakukan kompilasi dengan 6 error, dan npm run build:preload keluar dengan kode 1

Reaksi komunitas dan kekhawatiran yang meluas

  • Salah satu komentar menyebut isu terkait bitwarden/sdk-sm#898, dan menyuarakan kekhawatiran bahwa Bitwarden mengiklankan diri sebagai open source sambil beralih ke perangkat lunak proprietari
  • Pengguna lain mengatakan masalah serupa pada rilis NPM klien CLI juga sudah dilaporkan dua bulan sebelumnya di #10648, tetapi tidak mendapat respons
  • Beberapa pengguna menyebut alternatif seperti fork versi lama, Vaultwarden, serta aplikasi desktop Tauri yang membungkus antarmuka web Vaultwarden
  • Salah satu komentar menegaskan bahwa karena ini adalah produk yang menangani kata sandi, berpindah ke “alternatif mana saja” harus dilakukan dengan hati-hati, dan fork klien saja masih menyisakan ketergantungan pada layanan server atau perangkat lunak server
  • Komentar lain menyatakan SDK dipakai bukan hanya pada rilis Desktop tetapi juga pada browser, CLI, dan web clients sebagai feature flag, dan menulis bahwa semua versi Bitwarden 2024.10.0 memakai SDK tersebut

Tanggapan awal dari Bitwarden

  • Anggota tim Bitwarden menjawab bahwa mereka memang telah memperluas cakupan penggunaan SDK di klien, tetapi tujuannya adalah agar penggunaan SDK tetap mempertahankan kompatibilitas GPL
  • Bitwarden mengajukan tiga dasar berikut
    • SDK dan klien adalah program yang terpisah
    • Kode masing-masing program berada di repositori yang terpisah
    • Hanya karena kedua program berkomunikasi lewat protokol standar bukan berarti keduanya menjadi satu program untuk tujuan GPLv3
  • Mereka juga menyatakan bahwa masalah aplikasi yang tidak bisa dibangun dengan cara yang dicoba pengguna adalah sebuah bug yang akan diperbaiki
  • Setelah itu, percakapan dikunci oleh Bitwarden dan dibatasi hanya untuk collaborator

Penyesuaian akhir dan penutupan

  • Bitwarden menyatakan telah menyesuaikan susunan kode SDK dan cara packaging-nya sehingga aplikasi dapat dibangun dan dijalankan dalam keadaan hanya memuat lisensi GPL/OSI
  • Referensi paket sdk-internal di klien diubah agar berasal dari repositori sdk-internal yang baru
  • Mereka menjelaskan bahwa repositori sdk-internal baru mengikuti model lisensi yang telah lama dipakai Bitwarden pada klien yang ada, dan merujuk ke LICENSE_FAQ.md sebagai informasi terkait
  • Saat ini, referensi sdk-internal hanya menggunakan lisensi GPL
  • Jika ke depan referensi tersebut memasukkan kode Bitwarden License, mereka mengatakan akan menyediakan cara untuk membuat beberapa varian build, mirip dengan build klien web vault
  • Repositori sdk lama berganti nama menjadi sdk-secrets, dan mempertahankan struktur Bitwarden SDK License yang ada untuk produk bisnis Secrets Manager
  • Karena kode di repositori dan paket sdk-secrets tidak digunakan oleh aplikasi klien, kode itu tidak lagi dirujuk dari aplikasi klien
  • Isu ini ditutup sebagai completed pada 25 Oktober 2024

2 komentar

 
tribela 2024-10-21

Saya penggemar Keepass, tetapi karena orang-orang terus membicarakan Bitwarden saya sempat berpikir untuk mencobanya; namun sepertinya saya akan tetap memakai Keepass. Karena sistemnya bukan berbasis server dan hanya perlu menyimpan file dengan baik, ketersediaannya jauh lebih tinggi, jadi menurut selera saya Keepass lebih cocok.

 
GN⁺ 2024-10-21
Opini Hacker News
  • Saya membayar karena berharap dapat mendukung open source, dan itulah sebabnya saya pindah dari LastPass ke Bitwarden.
    Kejadian ini terasa seperti pisau yang sudah menancap di punggung lalu diputar. Sepertinya mereka sedang bersiap untuk akuisisi karena CEO Michael Crandell telah mencapai titik infleksi finansial yang mirip dengan saat ia menjual RightScale: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Bahkan materi tahun 2022 di halaman itu, di bagian “Apa yang berubah?”, tertulis bahwa Bitwarden akan terus mempertahankan arsitektur open source.
      Sepertinya sekarang tidak lagi. Langkah yang berbahaya. Open source punya banyak sifat baik, tetapi yang penting di sini adalah keamanan. Selalu mengherankan ketika perusahaan mengklaim gumpalan biner yang tidak transparan sebagai sesuatu yang aman. Intel Management Engine juga begitu, dan sekarang Bitwarden bergabung dengan jajaran IME dan switch Juniper.
      Beralih ke closed source adalah pilihan berisiko tinggi. Selama ini saya tidak membayar untuk perangkat lunaknya itu sendiri, tetapi saya bisa membayar untuk keamanan, dan memang membayarnya. Saya membayar Bitwarden karena ia menyimpan hal-hal yang saya anggap sebagai informasi paling berharga dan pribadi. Namun pada akhirnya itu tetap hanya perangkat lunak, dan tidak penting byte yang disebut “bitwarden” itu berasal dari mana. Siapa pun bisa mem-fork dan menyediakan byte yang sama. Kalau ada yang menjalankan mirror Bitwarden yang hanya memakai perangkat lunak open source, uang saya akan mengalir ke sana. Akan lebih baik lagi jika ada instruksi build yang bisa mereproduksi secara identik biner yang berjalan dan biner yang saya unduh ke berbagai perangkat. Saya tidak menganggap kata sandi saya aman kecuali dikelola oleh perangkat lunak open source.
  • Langkah ini tidak terlalu mengejutkan. Dalam beberapa tahun terakhir Bitwarden bergerak kuat ke arah penjualan enterprise, dan selama itu sisi konsumen dibiarkan terbengkalai.
    Baru-baru ini mereka beralih dari basis MAUI sebelumnya ke aplikasi iOS native, tetapi aplikasi lama terasa sangat janggal dalam banyak hal. Klien iOS yang sekarang pun masih punya banyak hal untuk dikejar.
    Setelah menerima pendanaan ventura, tampaknya mereka makin condong ke pendapatan dan laba. Pilihan itu sendiri tidak salah, tetapi mereka mendorong ke arah yang cukup berbeda dari cara perusahaan ini bermula dan tumbuh.
    Proton Pass juga agak menarik, tetapi seperti layanan Proton lainnya, model harganya selalu terasa sedikit mahal. Saya sudah mencoba Proton Pass gratis untuk sementara, dan karena Bitwarden tidak membaik ke arah yang saya tunggu selama bertahun-tahun, saya akan melihat apakah layak pindah ke alternatif itu.
    Pengelola kata sandi bawaan iOS juga cukup baik, tetapi hanya khusus kata sandi dan tidak mendukung penyimpanan, pencarian, serta autofill untuk jenis data lain.

    • Ironis. Sebagian perusahaan mungkin justru memakai Bitwarden karena ia terbuka, dan karena tidak perlu melewati panggilan sales enterprise hanya untuk memakai sesuatu yang sangat berguna.
      Jika produk dibuat sulit digunakan, Anda kehilangan pelanggan dan peluang penjualan. Ini mengingatkan saya pada panggilan-panggilan buruk yang baru-baru ini saya alami dengan Postman. Daripada harus melakukan satu panggilan lagi, sekarang Hoppscotch terlihat jauh lebih baik.
    • Mengapa pendanaan ventura hampir selalu merusak segalanya?
  • Jawaban CTO mengatakan bahwa mereka telah memperluas cakupan penggunaan SDK ke lebih banyak kasus klien, tetapi tujuannya adalah agar SDK digunakan dengan cara yang tetap menjaga kompatibilitas GPL.
    Menurutnya, SDK dan klien adalah program terpisah, kode masing-masing program ada di repositori terpisah, dan fakta bahwa kedua program berkomunikasi lewat protokol standar saja tidak menjadikannya satu program menurut GPLv3. Masalah bahwa aplikasi seharusnya bisa di-build dengan cara yang dicoba di sini disebut sebagai bug sederhana yang akan mereka perbaiki.

    • Jawaban semacam ini benar-benar membuat frustrasi. Karena mereka menghindari pertanyaan sebenarnya dengan cara yang seolah sengaja salah memahami ruang lingkup pertanyaan.
      Yang ingin saya tanyakan kepada CTO kira-kira begini. Mereka menjawab “apakah pengacara kalian menganggap ini bisa lolos secara hukum?”, tetapi tidak menjawab pertanyaan inti yang dikhawatirkan orang-orang. Apakah tim Bitwarden menganggap tidak ada masalah etis dalam memprivatisasi proyek yang didukung dan dikontribusikan banyak orang secara eksplisit karena open source? Pengelolaan kata sandi pada dasarnya adalah bisnis yang membutuhkan kepercayaan tinggi; bagaimana mereka akan menangani retaknya kepercayaan, fork, dan eksodus akibat rug pull dari open source ke closed source? Jika perusahaan berada dalam kondisi begitu mendesak sampai mempertimbangkan keputusan seperti ini, apakah tidak ada cara bagi komunitas untuk membantu melewatinya bersama tanpa privatisasi?
      Saya paham sebagai CTO saat ini tugasnya adalah berpura-pura peduli, terutama di forum tempat percakapan tidak bisa ditutup, tetapi pendekatan sekarang pada dasarnya mengonfirmasi ketakutan terburuk: “kami percaya ini legal, dan kami tidak melihat ada masalah dengan tindakan kami.” Ini persis nuansa yang salah bagi perusahaan yang pendapatannya bergantung pada pengguna yang harus memercayai kode dan orang-orang yang memperbaruinya.
    • Dengan kata lain, bitwarden/clients adalah GPLv3, klien Bitwarden sebagai keseluruhan yang berfungsi adalah perangkat lunak proprietari, CTO menganggap ini tidak masalah, dan issue-nya sudah dikunci.
    • Intinya tidak harus soal apakah ini “satu program”. Masalahnya ada di bagian ini:
      “'Corresponding Source' untuk karya dalam bentuk kode objek mencakup semua kode sumber yang diperlukan untuk menghasilkan, memasang, dan menjalankan kode objek serta memodifikasi karya tersebut, termasuk skrip untuk mengendalikan aktivitas-aktivitas itu.”
      Saya paham bahwa menghasilkan uang sebagai perusahaan open source itu benar-benar sulit. Karena itu saya juga salah satu pelanggan berbayar.
      Pengecualian yang ditempelkan pada SDK terlihat sangat mirip dengan perangkat lunak kontrol versi BitKeeper yang sempat dipakai di kernel Linux. Lihat saja bagaimana akhirnya.
  • Saya menyukainya, membayarnya, bahkan merekomendasikannya kepada teman-teman, dan mereka juga menyukainya.
    Sekarang saya berencana pindah ke KeePassXC. Apa cara yang direkomendasikan untuk menyinkronkan database dengan Android? Saya hanya punya server Raspberry Pi yang menjalankan cloudflared.

https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...

[https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE](<https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE>;)
  • Saya memakai SyncThing untuk mendistribusikan brankas KeePass hanya ke perangkat yang diperlukan secara tepat. Bagi saya ini berjalan sangat baik. Bisa saja berbeda tergantung kebutuhan

  • Saya benar-benar ingin memakai KeePass dan ekosistemnya, tetapi berbagi kata sandi kurang bagus. Saya dan istri punya banyak kata sandi bersama, dan Bitwarden bekerja sangat baik untuk bagian itu. Saya tidak tahu alternatif praktis apa yang cocok untuk kami

  • Keepass2Android bisa disinkronkan dengan berbagai cara seperti ssh(sftp), Nextcloud, dan lainnya. Seharusnya bisa menemukan cara yang sesuai

  • Kombinasi KeePassXC dan klien Nextcloud untuk Android sempurna bagi saya. Sudah saya pakai bertahun-tahun tanpa masalah

  • Mereka mengunci issue GitHub sehingga tidak bisa didiskusikan lagi. Salah satu alternatif yang mungkin tampaknya Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    Sangat disayangkan hal seperti ini terus terjadi pada proyek open source begitu orang-orang berduit masuk

    • Vaultwarden adalah pengganti server, dan setahu saya masalah di sini adalah lisensi klien desktop
    • García baru-baru ini mulai bekerja di Bitwarden. Akan menarik mendengar pendapatnya
    • Apakah Vaultwarden mendukung passkey?
  • Saya belum pernah melihatnya secara mendetail, tetapi dari pemasarannya saja saya mengira Bitwarden sepenuhnya perangkat lunak bebas. Namun sepertinya sejak sekitar 2020 ada unsur proprietary yang aneh masuk

  • Saya berharap suatu hari bisa pindah ke Bitwarden, tetapi jika tidak bisa menemukan ekosistem terbuka yang sehat, sepertinya sekarang saya tidak akan melakukannya. Saya akan terus memantau bagaimana perkembangannya

    • Saya pernah mencoba beralih sepenuhnya ke Bitwarden selama 1 tahun dengan backend Vaultwarden, tetapi dibandingkan 1Password yang saya pakai sebelumnya, pengalamannya jauh lebih buruk
      Salah satu kriteria penilaiannya adalah, “Semua anggota keluarga memakai 1Password dan puas; apakah ini cukup untuk meyakinkan mereka pindah?” Keputusan akhir untuk pindah memang bisa saya buat, tetapi agar orang tua saya yang sudah lanjut usia mau mencoba hal baru, pengalaman pengguna sangat penting
      Hasilnya, tidak. Selain UX secara keseluruhan yang buruk, klien Bitwarden jauh lebih lambat di Linux, Mac, Windows, dan iOS, dari pencarian sampai login, semuanya begitu. Fiturnya juga lebih sedikit; hal-hal yang terasa jelas seperti pengurutan kata sandi, favorit, dan alat pengorganisasian yang baik tidak ada, dan autofill juga jauh kurang andal
      Selama bertahun-tahun saya punya banyak ketidakpuasan besar terhadap cara bisnis dan respons pelanggan 1Password. Meski begitu, password manager—sekarang lebih mirip secret manager yang menyimpan lebih dari sekadar kata sandi—adalah pusat kehidupan sehari-hari, jadi saya merasa harus memakai yang sebisa mungkin paling minim rasa sakit, dan akhirnya dengan menyesal kembali lagi
      Saya tidak memakai Bitwarden karena open source, tetapi karena ingin memakai pengelola kata sandi terbaik yang memungkinkan. Meski begitu, saya suka bahwa ia terbuka, dan Vaultwarden adalah permata. Saya benar-benar berharap punya waktu dan kemampuan untuk membuat frontend yang lebih baik
  • “Untuk saat ini kami tidak memiliki rencana untuk menyesuaikan lisensi SDK. Kami akan terus memublikasikannya di repositori F-Droid kami sendiri https://mobileapp.bitwarden.com/fdroid/repo/.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Masalah ini sudah diajukan di repositori SDK pada bulan Juli, dan SDK tersebut sudah memakai lisensi ini selama lebih dari setahun

  • Saya memakai Bitwarden di iOS, PC, dan Mac. Sekarang harus mencari alternatif. Hari yang benar-benar menyedihkan
    Saya juga anggota premium seharga 10 dolar per tahun. Artinya itu akan menjadi pendapatan yang hilang karena praktik yang mencurigakan
    Apakah ada cara mengekspor lalu pindah ke alternatif lain?

  • Ini proyek yang saya pantau karena mungkin bisa menjadi alternatif Keepass(X,XC) yang lebih baik bagi saya, tetapi sekarang sepertinya pada akhirnya saya tidak akan pindah