Utang teknis: pustaka Rust saya kini diubah menjadi CDO

• Di ekosistem Rust, begitu sebuah dependensi yang tidak lagi dipelihara masuk ke RUSTSEC, bahkan pustaka yang sebelumnya tidak bermasalah pun berubah menjadi utang teknis melalui pengguna dan CI
• insta bergantung pada yaml-rust, dan setelah penulis aslinya kehilangan minat, permintaan fitur dan bug menumpuk
• Setelah terdaftar di RUSTSEC, CI dari para pengguna langsung maupun tidak langsung mulai gagal, yang dalam analogi keuangan setara dengan penurunan peringkat dan margin call
• Pustaka pengganti atau fork juga bukan solusi yang jelas, karena meski dependensi diganti, beban pemeliharaan dan risiko dependensi baru tetap ada
• Respons akhirnya adalah mem-vendor kode yaml-rust ke dalam insta, yang memicu kritik bahwa ini lebih mirip CDO yang membungkus utang teknis buruk menjadi AAA

---

Proses dependensi yaml-rust terungkap sebagai utang teknis

• insta bergantung pada yaml-rust, dan setelah penulis aslinya kehilangan minat, isu-isu terus menumpuk di yaml-rust
  • Sebagiannya adalah permintaan fitur, dan sebagiannya adalah bug nyata
  • Pemelihara insta tidak mengalami masalah tersebut secara langsung, tetapi karena ini adalah dependensi yang tidak lagi dipelihara, hal itu merupakan utang teknis
• Situasi berubah ketika yaml-rust masuk ke diskusi untuk ditambahkan ke basis data RUSTSEC
  • Dalam analogi keuangan, RUSTSEC berperan sebagai lembaga pemeringkat
  • Setelah terdaftar, CI banyak proyek yang memakai yaml-rust secara langsung maupun tidak langsung mulai gagal dalam hitungan menit
  • Ketika pengguna menunjuk masalah penggunaan yaml-rust kepada pemelihara insta, dalam analogi keuangan itu setara dengan terjadinya margin call

Opsi yang ada dan respons yang benar-benar diambil

• Berpindah ke alternatif bukan pilihan yang menarik
  • Salah satu alternatif adalah fork dari yaml-rust, hanya punya 1 pemelihara, dan menambah 3 dependensi
  • Salah satunya sudah mendapat peringkat “B-”
  • Pilihan lain di ekosistem telah memutuskan mengubah nilai bawaan sebelum dikritik
• Melakukan fork sendiri juga bukan solusi mendasar
  • Pustaka hasil fork akan tetap membawa kebutuhan pemeliharaan yang sama
  • Jika laporan bug tidak ditangani, pada akhirnya ia akan dikritik seperti yaml-rust yang lama
  • Jadi fork bisa membeli waktu, tetapi tidak menghilangkan masalah
• Respons yang benar-benar diambil adalah vendoring dengan menggabungkan kode yaml-rust ke dalam insta
  • insta kini menjadi bentuk gabungan antara kode insta dan yaml-rust
  • Ini adalah struktur yang mirip dengan menaikkan utang teknis buruk menjadi AAA
  • CDO pada judul merujuk pada collateralized debt obligation, yang menjadi terkenal buruk saat krisis keuangan 2007
• Penilaian akhirnya kurang lebih adalah “tidak ada yang benar-benar menang”
  • Kode bermasalah itu tidak hilang, hanya dipindahkan ke dalam insta
  • Tekanan karena terlihat sebagai dependensi eksternal berkurang, tetapi beban pemeliharaannya sendiri tetap ada

[GN⁺]

Komentar Hacker News

• Singkatnya, penulis serde_yaml parser YAML paling populer (https://lib.rs/crates/serde_yaml) tiba-tiba mundur tanpa pemberitahuan atau menunjuk penerus, lalu menandainya sebagai deprecated dan unmaintained
  Ini tidak persis sama seperti left-pad. Paketnya masih berfungsi dan crates.io juga tidak mengizinkan penghapusan, tetapi paket ini digunakan oleh 4.000 crate lain
  Alat audit dan pembaruan otomatis kemungkinan akan mulai menganggap penggunaan crate yang tidak terawat sebagai masalah

  • Tidak tepat. Teks aslinya mengatakan dependensinya ada pada yaml-rust (https://github.com/chyh1990/yaml-rust), dan proyek itulah yang sekarang tidak lagi dipelihara
    Pada saat yang sama, serde_yaml juga ditandai sebagai unmaintained agar orang-orang tidak berbondong-bondong pindah ke sana
  • Ini tidak berlaku di sini, tetapi pustaka tanpa dependensi kadang memang benar-benar fiturnya sudah lengkap, jadi hampir tidak perlu diubah selain untuk perbaikan keamanan
    Saya berharap alat audit dan kebijakan perusahaan cukup pintar untuk membedakan kasus seperti ini, alih-alih terus memberi peringatan “tidak dipelihara” hanya karena tidak ada commit terbaru
  • Bukankah penulis itu cukup produktif di ekosistem pustaka Rust? Dia tidak melakukan langkah seperti ini pada pustaka lainnya
    Saya penasaran apakah ada informasi yang lebih rinci

• Saya tidak langsung paham singkatan CDO yang muncul tanpa penjelasan, tetapi karena tulisan itu beberapa kali memakai istilah collateralized, sepertinya maksudnya adalah collateralized debt obligation
  https://en.wikipedia.org/wiki/Collateralized_debt_obligation
  Awalnya saya mengira itu chief data officer

  • Analogi di sini adalah bahwa CDO merupakan produk keuangan yang dibentuk dari utang-utang lain
    Secara spesifik, pada 2008 itu seperti kepemilikan sebagian atas banyak hipotek perumahan, dan ketika hipotek buruk gagal bayar, CDO juga ikut rusak [1]
    Bagaimanapun, yang dipikirkan penulis lebih dekat ke risiko sistemik seperti leftpad atau gangguan DNS berantai daripada sekadar metafora berbasis utang. Alasan besar mengapa 2008 menjadi kekacauan sebesar itu juga lebih karena masalah sistemik daripada semata fakta bahwa utang dijadikan produk [2]
    1. Fakta menariknya, sebelum 2008 permintaan atas produk keuangan berbasis hipotek tumbuh tanpa henti sampai orang mulai membuat CDO dari CDO. Mereka memberi hipotek bahkan kepada orang yang tidak punya pekerjaan, lalu membungkusnya menjadi produk berperingkat kredit AAA agar mudah dijual dan menghasilkan untung
    2. Ada juga fakta bahwa rasio leverage Lehman dan Bear Stearns mencapai 30–40x. Itu tingkat yang gila
  • Betul. Implikasinya adalah jika ada insentif untuk membundel utang teknis yang buruk ke dalam paket bereputasi baik, yaitu paket AAA, ekosistem Rust bisa menuju gelembung lalu akhirnya runtuh
    Itu juga berarti lembaga pemeringkat yang seharusnya berperan sebagai regulator sudah lebih dulu berhasil dikuasai
  • Harus menonton The Big Short. Saya belajar apa itu CDO dari sana
  • Saya baru sadar sekarang sudah ada generasi yang terlalu muda untuk membaca tajuk berita saat CDO meruntuhkan ekonomi dunia. Rasanya tua
  • Saya malah terpikir https://en.wikipedia.org/wiki/Collaboration_Data_Objects ;)

• Saya tidak ingin berdebat apakah ini bisa disebut “kemenangan”, karena itu terlalu bergantung pada definisi “kemenangan”, tetapi jelas ada keuntungannya. Jalur kode rentan yang tidak pernah dieksekusi dan juga tidak bisa dijangkau dari pustaka eksternal kini menjadi jalur kode yang aman
  Tentu tetap terasa kurang nyaman, tetapi memang aman
  Ada juga keuntungan lain dari vendoring seperti ini. Jika pustaka Anda sendiri punya cakupan pengujian yang kuat, Anda bisa menjalankan alat code coverage terhadap pustaka yang baru diambil itu
  Memodifikasi pustaka mungkin sulit, tetapi Anda mungkin bisa relatif mudah menghapus bagian yang tidak pernah disentuh oleh kode Anda. Tergantung strukturnya, jika semua kode rentan bisa dihapus itu jelas menguntungkan, dan jika Anda menemukan ternyata memang ada sebagian yang dipakai, itu juga bisa jadi keuntungan yang lebih jelas lagi
  Jadi, mem-fork pustaka untuk pemeliharaan publik adalah tanggung jawab besar, tetapi mem-vendor hanya bagian yang diperlukan lalu menyesuaikannya adalah beban yang jauh lebih kecil. Bahkan jika pemangkasan nyata belum dilakukan, fakta bahwa itu jadi mudah dilakukan sendiri sudah merupakan kemajuan
  Jelas ada kekurangannya, tetapi tidak semuanya buruk

  • Sebenarnya ini hasil yang sangat bagus. Semua dependensi adalah risiko keamanan, dan alasan mengapa kita tidak mem-vendor semua dependensi adalah karena untuk menghindari masalah keamanan yang sudah diketahui, dependensi eksternal harus terus diperbarui
    Namun jika sudah tidak ada lagi yang mengawasi dependensi eksternal itu, logika tersebut hilang, dan dependensi itu menjadi beban
    Dependensi ditandai sebagai abandoned dan mulai muncul di laporan keamanan adalah perilaku yang memang diinginkan. Dengan begitu kita bisa membuat keputusan yang terinformasi: apakah akan mem-vendor-nya, yakni menghilangkan risiko “ada pelaku jahat menyisipkan sesuatu”, atau memilih opsi lain
    Menyenangkan juga bahwa sistem build Rust memudahkan hal ini
  • Perlu dicatat bahwa di Google, semua dependensi pihak ketiga menurut kebijakan memang harus di-vendor
    Biasanya hanya satu versi dependensi itu yang diizinkan di seluruh monorepo raksasa. Mungkin sudah berubah sejak saya di sana
    Dan untuk setiap dependensi third_party, ada penanggung jawab atau OWNERS yang ditunjuk
    Ini membantu menjaga keteraturan
    Namun disiplin yang dipaksakan seperti ini mungkin cocok untuk organisasi seperti Google yang punya cukup waktu dan uang, serta tidak terikat filosofi “bergerak cepat dan rusak banyak hal”. Saya tidak yakin seberapa cocok ini untuk startup
  • Saya penasaran apakah ada alat yang memungkinkan pengelola pustaka menghitung cakupan kode transitif pustaka mereka, misalnya test suite pustaka lain mana saja yang menggunakan pustaka tersebut
    Dalam satu sisi, pustaka-pustaka lain itu seperti pengujian fuzz terarah yang memberi panggilan hampir acak, jadi ini bisa menjadi strategi pengujian yang menarik

• Saya juga melihat pola yang sama di ekosistem JS npm
  npm audit umumnya seperti bocah penggembala yang suka berteriak palsu soal masalah keamanan, dan jika lisensi mengizinkan, menarik kodenya ke dalam proyek adalah salah satu cara paling andal agar pengguna tidak kewalahan oleh isu-isu palsu
  Sering kali pengguna tidak memahami konteksnya, atau tidak peduli karena kebijakan perusahaan tempat mereka bekerja dibuat jauh dari realitas
  Bukan berarti regex yang dipakai di sebagian codebase dependensi transitif dalam pipeline build benar-benar bisa dieksploitasi untuk serangan denial-of-service terhadap layanan nyata
  “Isu” pada dependensi transitif yang dalam bisa sangat merepotkan untuk diakali. Secara struktural, sering kali sulit membuktikan secara teknis hal-hal seperti “kami tidak akan pernah masuk ke jalur kode itu, jadi kami tidak terdampak oleh cacat tersebut” atau “satu-satunya kasus yang masuk ke jalur itu adalah input tepercaya di lingkungan offline”

  • Isu pada dependensi pengembangan di dunia JS benar-benar menyebalkan
    Memang ada skenario di mana masalah semacam ini penting. Misalnya, tool build yang sudah disusupi bisa menyuntikkan kode berbahaya ke library yang sedang dibangun
    Namun kasus seperti itu sangat jarang, dan tenggelam di tengah banjir regex berpotensi denial-of-service yang sebenarnya tidak penting karena hanya dipanggil saat build
    Ditambah lagi, tool build pada umumnya punya pohon dependensi transitif yang seolah berjumlah 50 miliar, jadi ini benar-benar pekerjaan yang melelahkan
    Menurut saya, tool yang melaporkan isu semacam ini harus membedakan antara “bisa dieksploitasi jika didistribusikan ulang” dan “bisa dieksploitasi jika digunakan dalam pipeline build”
  • Bahkan jika sekarang tidak masuk ke jalur bermasalah itu, di kemudian hari pembaruan dependensi bisa membuatnya masuk ke jalur bermasalah

• Dalam kalimat “sekarang utang teknis yang buruk tiba-tiba menjadi berperingkat AAA”, kata “tiba-tiba” tampaknya berarti bahwa tidak masuk akal jika kode yang sama mendapat peringkat utang yang lebih baik hanya karena sudah di-vendor
  Namun itu hanya melihat nilai kodenya sendiri, dan melewatkan bagian terpenting dari keseluruhan proposisi nilai
  Ketika maintainer menarik kode itu ke dalam proyek, sekarang kode itu menjadi milik maintainer tersebut. Jika kode dari proyek mati di-vendor oleh maintainer yang masih aktif, nilainya naik karena sekarang ada orang yang aktif yang bisa menanggapi isu, meninjau pull request, dan memperbaiki bug
  Analogi lainnya, ini seperti mengirim hewan peliharaan yang terlantar ke pemilik baru: nilainya naik karena akan dirawat lebih baik, menjadi lebih sehat, dan hidup lebih lama

  • Itu hanya berlaku bagi orang yang memakai dependensi tersebut secara tidak langsung. Dalam kasus ini, kemungkinan besar sangat sedikit mata yang benar-benar melihat untuk menemukan bug
    Maintainer juga harus menyesuaikan diri dengan codebase besar yang asing, sehingga akan ada hambatan masuk untuk mengimplementasikan atau meninjau perbaikan

• Ini sedikit menyimpang dan cukup kontroversial, tetapi menurut saya akan sulit menghindari masalah mengerikan jika manajer paket berbasis source tidak menjamin hak hukum bagi registry untuk mengambil alih pemeliharaan paket yang telah dipublikasikan secara paksa
  Masalahnya meliputi penelantaran, perubahan jahat, penghapusan jahat, dan peniruan identitas
  Jika suatu paket dianggap cukup penting bagi komunitas yang lebih luas, perlu ada cara untuk merebut entri registry paket itu dari tangan pemilik aslinya dan mengarahkannya ke fork
  Tentu saja tindakan seperti ini akan menimbulkan banyak drama, tetapi bisa melindungi pengguna hilir secara proaktif

  • Ini tampaknya bukan masalah besar. Keindahan open source adalah kita bisa melakukan fork
    Masalah sebenarnya adalah bahwa memelihara proyek open source membutuhkan waktu dan usaha, dan tidak mudah menemukan orang lain yang punya waktu luang untuk melakukannya
  • Manajer paket berbasis source yang mencabut kepemilikan paket saat registry menganggap perlu seharusnya akan kesulitan menarik kontribusi
    Ini bahkan kurang menarik daripada model hak cipta di mana semua kontribusi otomatis menjadi milik kelompok tertentu
    Mungkin ada ruang untuk berargumen bahwa GitHub, dengan menjadi host software bebas, adalah tempat yang secara khusus condong pada pelanggaran hak cipta software tersebut, tetapi setidaknya untuk saat ini GitHub tidak berusaha merebut kepemilikan nominal atas paket
  • Jika alasannya adalah penting di tingkat komunitas, maka paling-paling itu adalah hal yang perlu dilakukan di tingkat paket, bukan di tingkat registry
    Karena ini soal komunitas, hubungannya bukan pelanggan-pemasok, dan sebagian besar paket hanya cukup penting sampai-sampai disediakan gratis
    Ini bisa berujung pada jumlah yang merendahkan seperti “kami akan memberi Anda $10 per bulan, jadi tolong kelola 100.000 paket untuk kami”
  • Semua masalah ini bukan jenis yang sama. Paket yang dibekukan berarti dependensi hilirnya harus mengambil keputusan, tetapi ada cukup banyak pilihan, termasuk vendoring
    Ada banyak source code yang tidak dipelihara di internet, dan itu memang hanya pernah dipublikasikan apa adanya. Tidak ada siapa pun yang dijamin mendapat pembaruan untuk kode gratis
  • Alternatifnya adalah masalah Kik NPM. Mana pun pilihannya, sama-sama buruk

• Cukup beruntung bahwa seseorang sudah mem-fork yaml-rust dan membuat yaml-rust2(https://github.com/Ethiraric/yaml-rust2/blob/master/document...)
  Keren juga bahwa fork tersebut sepenuhnya lulus test suite YAML dan bahkan lebih cepat dalam benchmark. Migrasinya pun tampak sederhana
  Namun pada akhirnya masalah dasarnya tetap ada. Untuk saat ini kita memang bergantung pada pekerjaan orang lain yang bersedia memberi tenaga gratis, tetapi itu mungkin tidak akan berlangsung selamanya
  Saya tidak tahu apakah ada jalan keluar selain memberi penghargaan atas waktu dan usaha mereka, serta berharap mereka terus melakukan pekerjaan yang baik

  • yaml-rust pada awalnya adalah implementasi Rust murni, dan tagline-nya benar-benar menyatakan itu secara harfiah
    “A pure rust YAML implementation.”
    Justru serde_yaml lebih sulit disebut Rust murni karena bergantung pada unsafe-libyaml, yaitu libyaml yang dikonversi dengan c2rust
  • Proyek dengan bus factor 1 pada dasarnya berisiko
    Dalam rentang waktu yang cukup panjang, probabilitas maintainer open source meninggalkan proyek adalah 1
    Satu-satunya cara untuk menghindarinya adalah dengan menganggap proyek dengan satu maintainer sebagai hal yang tabu
  • Solusi dasar saya untuk masalah ini adalah sebisa mungkin menghindari dependensi pihak ketiga
    Ini mungkin bukan pilihan untuk proyek Rust karena orang-orang yang membuat Rust standard library ingin standard library tetap minimal
    Namun saat memakai bahasa lain dengan standard library yang cukup kaya fitur, ini jelas merupakan pilihan yang memungkinkan
    Karena saya sengaja memakai bahasa yang sudah menyediakan hal-hal yang saya butuhkan, saya hampir tidak pernah memakai library eksternal selain driver database

• Seluruh situasi ini terlihat agak konyol. Jika kodenya berjalan dan sudah begitu selama bertahun-tahun, saya tidak paham kenapa tidak dikelola itu menjadi masalah
  Jika tidak perlu diperbaiki dan batasan serta fiturnya sudah diketahui, ya tidak apa-apa
  Kode tidak rusak dengan sendirinya. Saya sudah beberapa kali meminjam atau mengintegrasikan kode dari puluhan tahun lalu dan memakainya dengan baik
  Secara pribadi, saya rasa saya akan mengabaikan saja semua keluhan tentang pustaka itu

  • Jawaban yang jelas adalah bahwa dalam banyak hal itu memang tidak “berjalan”
    Sudah ada banyak bug yang menumpuk, dan meskipun perbaikannya ada, itu tidak akan pernah ditambal. Lihat saja https://github.com/chyh1990/yaml-rust/issues dan /pulls
  • Ketika Anda bilang pernah meminjam atau mengintegrasikan kode dari puluhan tahun lalu, bukankah itu dilakukan penulis dengan mem-vendor pustaka tersebut ke dalam proyeknya sendiri?
    Itu sama saja dengan mengambil alih pemeliharaan potongan kode yang Anda gunakan
    Kadang itu bisa buruk. Bisa jadi sekadar coding salin-tempel atau duplikasi usaha
    Tetapi jika komponen pihak ketiga itu benar-benar tidak dikelola, itu cukup masuk akal

• Benar, dependensi memang bisa di-vendor. Untuk dependensi yang sudah mendekati “hampir selesai” dan pengembangan serta pemeliharaannya melambat, saya pada dasarnya sudah melakukan itu selama 20 tahun
  Hanya saja, saya belum pernah bekerja dengan bahasa yang “batteries are not included”

• Adakah cara membuat sesuatu seperti cargo vendor --aggressive agar semua kode mati di dalam dependensi bisa dipangkas berdasarkan crate saya?
  Saya penasaran apakah itu bisa membuat masalah “tinjau dependensi” jadi lebih mudah ditangani
  Ini memang agak keluar dari pokok bahasan tulisan, tetapi tetap terkait karena pada akhirnya pemilihan dependensi dan semua tanggung jawab yang menyertainya ada pada kita
  Tampaknya ada ruang untuk alat yang membantu kita mengambil tanggung jawab lebih besar atas apa yang benar-benar ikut terkompilasi ke dalam crate

  • Kalau begitu, apakah semua laporan bug pustaka itu juga disalin ke pelacak bug Anda sendiri?
    Kalau tidak, saya tidak paham apa yang sebenarnya membaik