"Pelanggan berbayar kami membutuhkan X, kapan Anda akan memperbaikinya?"

• Seorang pengguna perusahaan yang memiliki pelanggan di industri teregulasi (bank, lembaga federal, dll.) menekan proyek open source mitmproxy di isu publik untuk mengungkap jadwal rilis berikutnya, dengan alasan pelanggannya tidak dapat menggunakan perangkat lunak tersebut karena adanya kerentanan High dan Critical yang sudah diketahui
• Kerentanan tersebut berada di bagian library yang tidak digunakan oleh mitmproxy, sehingga dalam praktiknya tidak berdampak pada pengguna nyata
• Maintainer tidak menolak permintaan itu, tetapi menjawab bahwa jika mereka membutuhkan rilis patch yang tepat waktu, mereka bisa membuat kontrak dukungan berbayar (support contract), dan mengarahkan ke email di profilnya
• Pengguna perusahaan itu kemudian mengirim email protes, mengatakan bahwa ia menganggap jawaban tersebut sebagai "lelucon atau upaya pemerasan yang terselubung tipis"
• Intinya, pertanyaan tentang jadwal rilis itu sendiri sah, tetapi yang penting adalah adanya sikap kolaboratif seperti "bagaimana kami bisa membantu lewat kontribusi atau pendanaan"; penulis komentar asli kemudian mengirimkan permintaan maaf yang tulus

---

Latar belakang kejadian

• Menurut penjelasan konteks yang dilampirkan, ada kerentanan di sebuah library yang didistribusikan bersama mitmproxy, tetapi ada di bagian yang tidak digunakan oleh mitmproxy sehingga tidak berdampak pada pengguna nyata
• Setelah isu ini menjadi viral (went viral) di luar, konteks tambahan pun dijelaskan

Tuntutan awal dari pengguna perusahaan (isu GitHub)

• 16 jam sebelumnya, seorang pengguna menyebut anggota proyek lain, @Prinzhorn, sambil menanyakan tanggal target untuk rilis berikutnya
• Ia menjelaskan bahwa pelanggan di industri teregulasi (regulated industries) seperti bank dan lembaga federal dilarang oleh aturan untuk memakai perangkat lunak dengan kerentanan High dan Critical yang sudah diketahui
  • Mereka ingin menentukan posisi internal soal menunggu, tetapi membutuhkan semacam tanggal target

Tanggapan maintainer mhils

• Anggota mhils menjawab 15 jam sebelumnya bahwa jika mereka tertarik pada rilis patch yang tepat waktu untuk memenuhi persyaratan compliance perusahaan, ia bersedia menyiapkan kontrak dukungan
• Ia juga memberi tahu bahwa informasi kontak ada di email pada profilnya (termasuk penanda ":-)" )

Email protes ("Concerning response")

• Setelah itu, sebuah email dengan subjek "Concerning response" dikirim dari alamat berdomain us.ibm.com ke [e-mail] (bertanggal Jul 14, 2023)
• Email itu dimulai dengan "Mr. Hils" dan menyatakan bahwa alih-alih memperkeruh situasi atau memenuhi issue tracker GitHub dengan kata-kata yang tidak perlu, maksudnya adalah menjelaskan permintaan tanggal target dengan lebih baik agar mendapat jawaban langsung
  • Ia menegaskan bahwa ia berharap email lanjutan ini tidak diterima secara tidak menyenangkan, karena itu bukan niatnya
• Pada bagian yang disorot, ia menulis bahwa ia menganggap jawaban maintainer itu bukan tanggapan resmi proyek melainkan lelucon, atau lebih buruk lagi, upaya pemerasan yang terselubung tipis (thinly veiled extortion attempt) (kalimat kemudian terputus saat ia menyebut sedang meninjau dokumen resmi proyek)

Ringkasan posisi maintainer

• Ia menegaskan bahwa jawabannya bukan lelucon
• Pendekatan seperti "pelanggan berbayar kami membutuhkan X, kapan Anda akan memperbaikinya" mungkin bukan cara terbaik untuk memperkenalkan diri ke proyek open source
• Ia mengakui bahwa pertanyaan tentang jadwal rilis itu sendiri tidak mengganggu dan merupakan pertanyaan yang sah (valid)
  • Namun, inti persoalannya adalah konteksnya harus berupa "kami peduli pada pekerjaan ini, bagaimana kami bisa membantu mewujudkannya" (kontribusi atau pendanaan), bukan "Anda sedang menimbulkan masalah bagi pelanggan kami"

Penutup

• Penulis komentar asli kemudian mengirimkan permintaan maaf yang tulus (genuine apology), dan maintainer menyatakan sangat menghargainya
• Ia juga meminta semua orang untuk menganggap ada niat baik (assume good intentions) dan bersikap ramah

[GN⁺]

Komentar Hacker News

• Jika membaca isu inihttps://github.com/mitmproxy/mitmproxy/issues/6051, permintaan IBM jauh lebih masuk akal daripada yang terlihat di tweet
  Masalahnya adalah ada CVE pada dependensi mitmproxy, dan meskipun mitmproxy telah memperbarui dependensi itu pada bulan Maret, mereka belum merilis rilis stabil yang mencakup pembaruan tersebut. Pihak IBM sedang menanyakan, “kapan Anda berencana memberi tag rilis, apakah ada jadwal yang bisa disampaikan ke pelanggan?”
  Secara khusus, mereka bukan bertanya “kapan ini akan diperbaiki?”. Tidak ada lagi yang perlu diperbaiki, dan pertanyaannya lebih dekat ke “kapan Anda berencana membuat rilis baru yang mencakup pembaruan dependensi ini?”
  Saya tidak menganggap pertanyaan seperti ini tidak pantas. Tentu saja, jika mereka ingin perbaikan seperti ini didistribusikan dalam jangka waktu tertentu, tidak tidak pantas juga untuk meminta kontrak dukungan, tetapi jawaban singkat “silakan hubungi lewat email untuk kontrak dukungan” terasa agak berlebihan

  • Pertanyaan pertama sopan dan masuk akal, dan jawaban @mhils juga demikian. Yang sama sekali tidak masuk akal adalah bagian di email tindak lanjut dari pihak IBM yang menuduhnya sebagai “upaya pemerasan yang disamarkan tipis-tipis”
    Maximilian tidak punya kewajiban memberikan jadwal rilis kepada orang yang tidak membayar, dan jika IBM benar-benar membutuhkan timeline, tidak aneh sama sekali bila ia menyarankan untuk membayar. Jika IBM menganggap ini sepenting itu, mereka bahkan bisa membuat rilis internal mitmproxy sendiri hari ini juga
  • Menanyakan tanggal rilis adalah permintaan yang sepenuhnya masuk akal. Hanya saja jawaban saya sangat dipengaruhi oleh konteks
    Alasan saya mengatakan “silakan hubungi lewat email untuk kontrak dukungan” adalah karena 1) saya sudah menyatakan di thread itu bahwa kami tidak akan membuat patch release untuk hal ini dan 2) pihak lawan menekankan dampaknya terhadap pelanggan berbayar mereka
    Jadi memang hanya itu yang bisa saya tambahkan di sana. Saya setuju itu bisa diungkapkan dengan lebih baik, tetapi saya tidak merasa jawaban saya sepenuhnya berlebihan
    CVE itu sendiri juga keliru, dan kami tidak menggunakan bagian dependensi tersebut
  • Bagian itu cukup jelas. Masalahnya adalah dalam komunikasi setelahnya mereka menyebutnya sebagai “pemerasan yang disamarkan tipis-tipis”, dan itu sangat jauh dari sikap yang masuk akal
  • Seperti yang dijelaskan maintainer, CVE itu sebenarnya tidak berdampak pada mitmproxy. Pada akhirnya ini hanya membantu petugas keamanan mencentang satu kotak pemeriksaan
    Mengapa maintainer harus bekerja gratis sementara pihak peminta mendapatkan keuntungan dari kerja gratis itu
    Yang tidak pantas adalah sikap merasa berhak dari FrugalGuy. Perlu tingkat kemunafikan yang istimewa untuk menuntut maintainer open source bekerja gratis lalu menuduhnya melakukan pemerasan. Anda tidak bisa memaksakan tuntutan kepada sukarelawan yang mengerjakan proyek open source bebas secara paruh waktu
  • Meski begitu, nada mengancam yang dipakai saat mengirim email ke maintainer tetap tidak berubah

• Saya OP. Untuk memperjelas, pertanyaan tentang rilis itu sendiri sama sekali bukan masalah dan sepenuhnya valid
  Hanya saja konteksnya seharusnya “kami peduli soal ini, bagaimana kami bisa membantu agar ini terwujud?”. Entah lewat kontribusi atau biaya. Bukan “gara-gara Anda, pelanggan kami jadi bermasalah”
  Saya tidak berharap peminta itu sengsara hanya karena salah bicara, tetapi saya berharap perusahaan besar bisa membangun hubungan yang sehat dengan perangkat lunak open source bebas

  • Kalau ini proyek saya, saya rasa saya tidak akan menawarkan kontrak dukungan. Masalah hukum ketenagakerjaan dan pajak terlalu rumit bagi saya
    Fakta bahwa ia menawarkan kontrak seperti itu sebenarnya cukup baik hati. FrugalGuy bisa saja mendapat jawaban “kirim pull request”, dan entah apakah itu akan membuatnya senang
  • Kalau emosi dan orang-orang dikesampingkan, sebagai proyek perangkat lunak saya penasaran apa yang menghalangi mitmproxy merilis versi baru sekarang juga
  • Setelah membaca ini saya ingin menghapus komentar GitHub saya, tetapi thread-nya sudah dikunci jadi saya tidak bisa
  • Saya tidak mengerti bagaimana kontribusi atau uang menyelesaikan masalah rilis. Kalau ini bug, Anda bisa memperbaikinya lalu mengirim patch
    Tetapi kalau masalahnya adalah belum ada rilis untuk perbaikan yang sudah dibuat, saya kurang paham bagaimana itu bisa diperbaiki dengan kontribusi atau uang
  • Tetap saja, itu adalah upaya pemerasan

• Ini terdengar seperti tipikal orang bodoh keamanan informasi yang bahkan tidak tahu apa yang sebenarnya sedang mereka “perbaiki”. Begitu sistem otomatis memberi tahu ada CVE, mereka langsung mengira itu harus di-"patch"
  Mereka tidak memeriksa apa sebenarnya klaim dalam CVE itu, atau apakah cara penggunaan mereka yang spesifik memang rentan. Mereka tidak tahu, tidak peduli, dan bukan programmer. Yang mereka tahu cuma ada kotak centang yang harus dihapus
  Hal serupa juga pernah terjadi di h2database. Seorang “peneliti keamanan” menemukan bahwa hal buruk bisa terjadi jika Anda melakukan sesuatu yang memang sudah dibilang jangan dilakukan, lalu tetap meminta CVE dan berhasil mendapatkannya. Kalau dilihat lebih dekat, itu omong kosong, tetapi bagi orang-orang seperti ini yang penting hanya fakta bahwa CVE itu ada
  Kata pengembang h2database: https://github.com/h2database/h2database/issues/3686#issueco...
  “Sulit memahami kenapa saya harus punya sedikit saja simpati pada ‘perusahaan besar’ yang memakai proyek open source buatan sukarelawan. Pakai uang perusahaan untuk mempekerjakan seseorang agar menanganinya, atau bayar library komersial serupa”

  • Mereka mungkin juga tahu dan memahami semua ini, tetapi tetap tidak peduli. Bisa jadi kinerja mereka dinilai dari seberapa cepat mereka menghapus kotak centang, dan terlalu banyak menyetujui justru lebih merugikan daripada terlalu banyak menolak
    Bahkan jika mereka punya wewenang memberi pengecualian untuk situasi tertentu, mereka mungkin harus menulis lebih banyak dokumen untuk membenarkan keputusan itu. Dokumen tambahan itu memperlambat kerja, dan berdampak buruk pada metrik evaluasi kinerja mereka
  • Wow, CVE itu benar-benar konyol
    “Jika kata sandi diberikan lewat command line, proses lain di sistem bisa melihatnya lewat ps”
    Ya jelas. Kalau itu layak jadi CVE dengan “tingkat keparahan tinggi”, saya juga bisa menyebut diri saya peneliti keamanan. Saya bisa memikirkan setidaknya lima atau enam aplikasi yang mengizinkan hal yang sama sambil memasang peringatan “jangan lakukan seperti ini”
  • Sangat setuju. Saya bekerja di industri yang teregulasi, dan alurnya seperti ini
    Tim keamanan informasi menaikkan kerentanan yang muncul di laporan, lalu manajer jadi panik
    Pengembang harus terus melakukan update. Bahkan untuk dependensi yang bukan bagian operasional sekalipun. Mengajukan pengecualian memang bisa, tetapi itu masalah tersendiri yang sangat merepotkan
    Lalu manajer bertanya-tanya kenapa pekerjaan pengembangan jadi melambat
  • Saya bekerja di vendor SaaS dalam industri yang masih menganggap SaaS agak “eksotis”. Kami menerima kuesioner keamanan yang absurd, dan 90% jawabannya adalah tidak berlaku
    Saya juga ragu ada yang benar-benar meninjau sisa jawabannya

• Salah satu proyek saya juga pernah tiba-tiba dibanjiri komentar seperti “kapan ini akan diperbaiki”, “saya juga terdampak dan ini penting”. Lonjakan perhatian mendadak seperti itu terasa cukup aneh
  Lalu pada waktu yang mirip, saya menerima email permintaan maaf yang menjelaskan bahwa atasan di sebuah perusahaan telah menyuruh karyawannya menekan saya dengan berpura-pura bahwa yang terdampak jauh lebih banyak daripada kenyataannya

  • Jawaban terbaik adalah “tarif saya $XYZ per jam, dan saya menerima uang tunai atau cek”

• Sepertinya seseorang belajar di tempat kerjanya bahwa nada agresif atau mengancam sangat efektif, tetapi gagal memahami bahwa posisi tawarnya di sini sama sekali berbeda

  • Kalau melakukan itu selama 27 tahun, Anda bisa dipromosikan menjadi Program Manager Secure Engineering and Incident Response di IBM

• Ada perbedaan halus antara “saya perlu tahu kapan ini akan selesai agar bisa membuat rencana” dan “saya dibayar karena pekerjaan Anda, jadi Anda harus melakukan ini, tolong percepat”
  Jika si peminta bertanya tanpa membuang informasi latar belakang, nadanya akan lebih dekat ke yang pertama dan lebih jauh dari yang kedua

  • Saya tidak setuju bahwa itu adalah cara yang benar. Tidak ada masalah sama sekali dalam menjelaskan kenapa sesuatu berguna pada proyek open source
    Jika alasannya tampak penting juga bagi banyak pengguna lain, itu bisa membantu maintainer memutuskan apakah penambahan fitur atau perbaikan bug perlu dipercepat. Jika ada solusi sementara, itu juga bisa membantu menemukannya
    Menyebutnya sebagai pemerasan terhadap pengembang memang tidak adil, tetapi saya rasa pesan pertamanya sendiri tidak bermasalah

• Rasa berhak dari perusahaan yang memakai open source sambil tetap menuntut dukungan itu luar biasa besar. Saya berharap lisensi dengan pembatasan penggunaan dipakai lebih luas, dan OSI tidak hanya berkata “itu bukan open source!!!”
  Lisensi semacam itu bisa mencegah situasi seperti ini

  • GNU AGPLv3 membuat pengacara perusahaan begitu kesal sehingga pada praktiknya bisa berfungsi seperti lisensi nonkomersial. Namun sebenarnya itu bukan lisensi nonkomersial, dan memenuhi standar baik OSI maupun FSF
    Bagaimanapun, bagus juga OSI dan FSF mengambil sikap keras di sini. Jika prioritas Anda tidak sejalan dengan mereka, mengapa mereka harus berubah demi memuaskan Anda
    Pakai saja lisensi yang Anda suka. Meski mereka tidak menyetujuinya. Saya tidak paham kenapa itu jadi masalah. Kalau sejak awal Anda tidak berbagi nilai yang mereka pegang, kenapa organisasi itu harus memberi cap persetujuan pada pilihan lisensi Anda
  • Setuju, tapi lihat saja siapa yang membiayai OSI: https://opensource.org/sponsors/
    Bagi sponsor korporat, tidak mendukung pembatasan penggunaan itu bukan cacat, melainkan fitur
    Ada juga dogmatisme besar di sekitar definisi open source dan free software. Kalau tidak mengikuti definisi ini, orang mudah dikeroyok dan diserang, dan definisi tersebut sering diperlakukan seperti kitab suci. Para pendukungnya bahkan enggan menerima kemungkinan bahwa penyesuaian mungkin diperlukan agar cocok dengan realitas tahun 2023
    Bahkan kalau istilah baru diciptakan untuk menghindari benturan, para pendukung open source dan free software tetap memaksakan bahasa mereka sendiri dan ingin mengendalikan narasi. Bahasa itu dirancang agar punya konotasi negatif di dalam kerangka mereka
  • Saya tidak berharap pembatasan penggunaan dipakai lebih luas. Tidak, setidaknya bukan “pembatasan penggunaan” di luar spektrum pemaksaan share-alike dengan berbagai tingkat kekuatan yang diberikan LGPL, GPL, dan AGPL
    Kebebasan pengguna untuk menjalankan perangkat lunak untuk tujuan apa pun adalah kebebasan 0, dan Stallman menjelaskan dengan sangat meyakinkan mengapa pembatasan penggunaan tidak membantu: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
    Seperti klausul penafian garansi, free software diberikan tanpa syarat. Bahkan setelah diberi hadiah kebebasan untuk memodifikasinya sesuka hati, tetap menuntut dukungan dan pemeliharaan gratis itu tidak sopan. Mengganti lisensi rasanya juga tidak akan membuat orang-orang tidak sopan seperti itu hilang
  • Saya rasa kebanyakan orang tidak ingin sampai sebegitu anti-perusahaan. Kalau iya, dari awal mereka tidak akan memakai lisensi permisif
    Dan mungkin ada pilihan yang lebih ramah open source daripada korporat tanpa harus lewat lisensi. Misalnya, kalau seseorang ingin mengajukan isu penting, mereka harus mempublikasikan kode reproduksinya
  • Saya tidak begitu paham bagaimana itu akan menyelesaikan masalah. Mungkin perangkat lunak itu tetap akan dipakai di lingkungan bisnis, dan tetap akan ada orang yang menuntut dukungan atas nama pemberi kerja mereka
    Bahkan pada era 80-an, saat dukungan biasanya masih diberikan gratis, saya sering mendengar cerita bahwa perusahaan melakukan hal seperti itu dengan perangkat lunak bajakan. Satu-satunya hal yang mengurangi ulah itu adalah kontrak dukungan berbayar
    Respons yang realistis hanyalah menggugat pelanggaran lisensi, tetapi tidak banyak pengembang open source yang punya sarana untuk melakukan itu terhadap perusahaan menengah, apalagi perusahaan besar

• Tindakan “FrugalGuy” memang tidak matang dan kekanak-kanakan, tetapi maintainer mitmproxy sebenarnya bisa menjawab dengan cara yang lebih sopan namun tegas, tanpa ruang untuk salah paham atau drama
  “Sesuai lisensi mitmproxy, perangkat lunak ini disediakan apa adanya tanpa garansi, dan maintainer proyek saat ini terikat pada prioritas serta deliverable lain”
  “Karena itu, pernyataan di issue tracker Github saja tidak cukup untuk membenarkan prioritas isu. Satu-satunya cara untuk menaikkan prioritas isu adalah dengan membuat kontrak dukungan, yang tersedia di [here]. Saya dengan senang hati akan membahas syaratnya lebih lanjut”

  • Kelihatannya pada dasarnya tidak jauh berbeda dari jawaban yang sebenarnya. Malah sedikit lebih kasar, walaupun saya tidak tahu apakah itu memang disengaja. Jadi saya tidak melihat apa nilai tambahnya dibanding jawaban yang asli
  • Saya juga merasa jawaban yang asli sudah sopan dan tegas
  • Tidak. Balasan itu juga sama anehnya dengan orang aslinya. Kalau sudah membuat permintaan yang tidak peka situasi, tidak ada hak untuk tetap mendapat jawaban yang sopan

• Jika nilainya setara gaji tahunan satu engineer, bagi skala perusahaan tertentu itu uang yang nyaris tidak berarti, dan sepertinya perbaikannya bisa dilakukan dalam beberapa minggu, yang terasa adil
  Atau kalau benar-benar tidak mau bayar, mereka bisa menugaskan satu engineer perusahaan mereka selama beberapa bulan untuk menambal bagian yang dibutuhkan pelanggan berbayar lalu berkontribusi ke upstream
  Koreksi: kompensasi setahun untuk engineer itu hanya perkiraan saya yang terbatas dan tidak akurat. Saya tidak pada posisi untuk mengatakan nilainya tepat berapa, tetapi saya menduga engineer yang belum akrab dengan codebase mungkin akan butuh usaha beberapa bulan

  • Dari kelihatannya, mereka sebenarnya tinggal membangun rilis yang lebih baru. Perbaikannya sudah ada
    Hanya saja itu mungkin menimbulkan masalah kepatuhan lain, dan mungkin itu sebabnya mereka tidak melakukannya. Tentu saja itu bukan masalah proyek open source

• https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

  • Email lanjutan yang ditautkan OP memang benar-benar kelewatan, tetapi postingan GitHub ini sendiri menurut saya tidak pantas dipermasalahkan. Jawaban “bayar saja” juga tidak bermasalah
    Sekadar bertanya “apakah ada target tanggal untuk rilis berikutnya?” itu bukan masalah. Karena itu bukan tuntutan
    Ungkapan “kami sedang mencoba menyusun logika internal untuk menunggu, jadi kami butuh suatu target tanggal” terbaca bahwa kata “butuh” itu bukan tuntutan kepada pengembang mitmproxy, melainkan karena ada pihak lain yang menuntut hal itu darinya
    Di komentar ini dia sedang membuat permintaan sambil menjelaskan motivasi komersial dan pribadi di balik permintaan itu. Tidak ada masalah sampai dia kembali lewat email sambil membawa kata-kata seperti pemerasan
  • Apakah orang tertentu itu penting?
    Di postingan asli, konteks dan pemberi kerja sama-sama disebutkan. Penulisnya jelas sengaja berusaha menghindarinya, jadi menyebarkan issue GitHub yang sebenarnya juga tindakan yang buruk
  • FrugalGuy, saya sampai tidak bisa berkata-kata