Di sini Anda mengambil kode di bawah lisensi BSD, MIT dan Apache2 dan jangan meniup pengocok, lalu - bam! - shift kedua, dan dalam ketergantungan transitif kode di bawah AGPL ditarik. Kami mencoba untuk mengawasi ini dan lebih memilih untuk menyalip daripada gagal.
Sebelum menambahkan dependensi baru ke salah satu proyek saya, saya selalu melakukan pemeriksaan dasar. Apa yang saya periksa (daftar periksa standar):
- Di bawah lisensi apa kode dikeluarkan?
- Siapa penulisnya?
- Apakah ada masalah serius yang tidak terselesaikan dalam pelacak kesalahan?
- Apakah ada riwayat bug serius di pelacak kesalahan?
- Bagaimana cara review kode untuk pull-quests terjadi?
Setelah itu, saya membaca kode itu sendiri untuk mencari sesuatu yang jelas tidak aman atau berbahaya. Ini diperlukan untuk merasakan kualitas basis kode itu sendiri. Selanjutnya, saya mencoba mencari
"brown M & Ms" - detail kecil yang mungkin menunjukkan masalah besar. Dan ulangi semua hal di atas secara rekursif dengan dependensi transitif. Selain itu, saya sekali lagi menelusuri kode setiap kali saya memperbarui ketergantungan.
Ini adalah jumlah pekerjaan yang cukup besar, tetapi perlu agar tidak menjadi korban serangan seperti
event-stream . Dan baru-baru ini, saya diingatkan alasan bagus lain untuk memeriksa dependensi. Pada saat itu saya sedang melakukan tinjauan terhadap
perpustakaan yang diiklankan secara aktif dari Duo untuk WebAuthn on Go, ada di sini:
github.com/duo-labs/webauthn .
Semuanya dimulai dengan fakta bahwa saya memperhatikan beberapa "M&M coklat":
- Data telah dicatat di stdout, meskipun faktanya ini adalah perpustakaan.
- Kode itu ditimbun.
Tentu saja, masalah-masalah kecil ini hanya pertanda sesuatu yang lebih: ketika saya memulai review dari salah satu dependensi transitif (
github.com/katzenpost/core/crypto/eddsa ), header
lisensi AGPLv3 menemui saya.
Ini adalah berita buruk bagi siapa saja yang ingin menggunakan perpustakaan WebAuthn Duo. Terlepas dari kenyataan bahwa Duo melisensikan perpustakaannya di bawah BSD, memilihnya, Anda juga menautkan aplikasi Anda dengan perpustakaan AGPL. Dan, menurut (A) GPL, dengan cara ini Anda membuat produk "dimodifikasi" yang berada di bawah aturan
bagian 13 dari AGPL :
Jika Anda membuat perubahan pada program, versi modifikasi Anda harus secara eksplisit menawarkan semua pengguna yang berinteraksi dengannya dari jarak jauh melalui jaringan (jika versi Anda mendukung interaksi ini) peluang untuk mendapatkan akses gratis ke kode sumber versi Anda menggunakan alat penyalinan perangkat lunak standar (meskipun ke ketentuan lain dari Lisensi ini).
Dengan kata lain, jika Anda menggunakan
github.com/duo-labs/webauthn dalam aplikasi web publik, aplikasi web Anda sekarang harus open source.
Hal yang paling keterlaluan tentang ketergantungan ini adalah duplikat
golang.org/x/crypto/ed25519 - salah satu
perpustakaan "x" kuasi standar .
Sebenarnya,
github.com/duo-labs/webauthn sama dengan
golang.org/x/crypto/ed25519 yang awalnya digunakan. Substitusi berlangsung selama pencarian-tarik kolaborasi eksternal yang disebut
"Konsolidasi COSE hal-hal ke daerah mereka sendiri" . Dalam proses mentransfer bagian dari kode dari satu file ke file lain, permintaan tarik ini dengan diam-diam mengubah implementasi
OKPPublicKeyData.Verify .
Berikut adalah
OKPPublicKeyData.Verify yang menggunakan
golang.org/x/crypto/ed25519 :
Dan di sini adalah
OKPPublicKeyData.Verify , yang menggunakan
github.com/katzenpost/core/crypto/eddsa AGPL berlisensi:
Tidak ada penjelasan yang diberikan untuk perubahan ini. Review pullrequest dilakukan oleh
dua karyawan Duo, disetujui, dan menahannya.
Itu sebabnya saya tidak ingin menerima permintaan untuk permintaan tarik yang memindahkan kode. Bahkan jika organisasi baru dari kode lebih baik daripada yang sebelumnya, waktu yang dibutuhkan untuk memeriksa "apakah pencarian-tarik baru melakukan sesuatu yang berlebihan" memakan terlalu banyak waktu.
Saya
memposting peringatan tentang ketergantungan perpustakaan dengan lisensi AGPL, dan para pengembang
mengembalikan golang.org/x/crypto/ed25519 . Meskipun demikian, saya memutuskan untuk tidak menggunakan
github.com/duo-labs/webauthn . Sebagian besar perpustakaan dan dependensinya dirancang untuk mendukung kesalahan WebAuthn yang disebut pengesahan, yang keinginan saya kurang dari nol untuk menggunakannya. Saya baru saja selesai menulis perpustakaan yang jauh lebih sederhana, bebas pengesahan, dan itu lebih kecil dari sepersepuluh di atas. Segera saya akan membuka kode sumbernya. Pengembangan perpustakaan ini menjadi lebih murah daripada tanggung jawab untuk menggunakan perpustakaan WebAuthn Go yang ada.
Kasus ini mengingatkan saya mengapa saya suka pemrograman di Go. Berkat Go, pustaka "x" standar dan kuasi standar yang luas, biasanya ada beberapa dependensi tambahan dalam proyek saya. Reputasi dan prosedur operasi Go yang baik memungkinkan saya untuk tidak mandi uap dan tidak memeriksa ulang kode sumber dari kompiler dan perpustakaan standar. Dan, terlepas dari kenyataan bahwa saya mencintai Rust, saya ngeri setiap kali saya melihat pohon dependensi dari perpustakaan mereka yang khas: biasanya saya melihat lusinan dependensi transitif yang ditulis oleh pria acak yang tidak jelas dari Internet yang saya tidak punya alasan untuk percaya. Memeriksa semua dependensi ini membutuhkan terlalu banyak waktu, jadi saya jauh lebih tidak produktif di Rust daripada Go.
Satu catatan terakhir: sebagai penggemar struktur data yang dapat diverifikasi seperti Transparansi Sertifikat, saya harus menyukai
database Go checksum yang baru. Namun, database checksum tidak akan membantu Anda jika Anda tidak menghabiskan waktu memeriksa dependensi Anda. Sayangnya, saya telah melihat seorang pengguna Go yang sangat antusias mengklaim bahwa database checksum menyelesaikan semua masalah dengan manajemen ketergantungan. Tapi ini tidak benar. Tidak ada cara mudah untuk menghilangkan ini, dan Anda harus menerima kenyataan: dari waktu ke waktu Anda perlu melakukan ulasan ketergantungan pada proyek Anda.