Trusted Publishing PyPI Tidak Boleh Dianggap sebagai Sinyal Kepercayaan Paket

• “Kepercayaan” dalam Trusted Publishing bukan berarti paket boleh dipercaya oleh manusia, melainkan merujuk pada hubungan autentikasi unggahan antara identitas mesin eksternal seperti CI/CD dan indeks paket
• Implementasi PyPI berjalan di atas federasi OIDC, menerbitkan kredensial publikasi yang singkat dan cakupannya sempit sebagai pengganti token API jangka panjang, sehingga mengurangi paparan kredensial jangka panjang dan berhak akses berlebihan
• Setelah PyPI meluncurkannya pada 2023, pendekatan ini menyebar ke npm, RubyGems, crates.io, NuGet, dan lainnya, tetapi kompleksitas model data, penanganan per penyedia OIDC, serta kemungkinan kompromi CI/CD masih tetap ada
• PyPI tidak menonjolkan status Trusted Publishing dengan tanda centang hijau di halaman proyek, melainkan hanya menampilkannya sebagai metadata Yes/No sederhana di detail berkas, sehingga mengurangi peluang disalahpahami sebagai sinyal keamanan
• Trusted Publishing dan PyPI attestations hanya memberi tahu apakah ada autentikasi unggahan atau penandatanganan berbasis identitas mesin; sebelum identitas itu dipercaya secara terpisah, keduanya tidak dapat digunakan untuk menilai keamanan atau kualitas paket

---

Cakupan kepercayaan yang ditangani Trusted Publishing

• Trusted Publishing bukan fitur yang mengatakan kepada manusia untuk memercayai sebuah paket, melainkan metode autentikasi yang menangani kepercayaan antarmesin
• Jika Trusted Publishing dilihat sebagai persoalan apakah manusia dapat memercayainya atau tidak, kategorinya menjadi keliru
• Intinya adalah membangun hubungan kepercayaan untuk autentikasi unggahan antara identitas mesin eksternal seperti workflow CI/CD dan identitas proyek di indeks paket

Struktur Trusted Publishing di PyPI

• “Trusted Publishing” adalah istilah yang digunakan PyPI saat menjelaskan metode autentikasi di atas federasi OpenID Connect
• PyPI meluncurkannya pada 2023, lalu npm, RubyGems, crates.io, NuGet, dan lainnya ikut mengadopsinya
• Titik awalnya adalah dua masalah
  • Token API indeks sebagai kredensial jangka panjang sulit dikelola dengan aman, dan pengguna sulit menentukan hak akses minimum serta masa kedaluwarsa, sehingga cenderung dikonfigurasi dengan hak akses berlebihan
  • Banyak pengguna membuat kredensial untuk dimasukkan ke platform CI/CD, sementara platform CI/CD juga memiliki mekanisme untuk membuktikan kendali atas identitas mesin tertentu melalui OIDC
• Pengguna mendaftarkan Trusted Publisher, yaitu identitas mesin CI/CD, satu kali di indeks paket; ketika CI/CD menyajikan token identitas, indeks memverifikasinya lalu menerbitkan kredensial publikasi yang singkat dan cakupannya sempit

Keunggulan dan batasan yang tersisa

• Pendekatan kredensial yang singkat dan cakupannya ditentukan sendiri dinilai sebagai pendekatan yang sangat berhasil bagi pengguna PyPI
  • Pengguna lebih menyukai cara yang membuat mereka tidak perlu mengelola kredensial secara langsung saat tidak dibutuhkan
  • Proyek open source besar dan perusahaan menyukai sifat bahwa hak publikasi terhubung ke identitas sumber, bukan ke maintainer individu
• Trusted Publishing tetap memiliki kompleksitas struktural
  • “pending publishers” di PyPI menyelesaikan masalah proyek yang belum ada, tetapi membuat model data lebih rumit dan lebih membingungkan bagi pengguna dibanding Trusted Publishing biasa
  • Selain beberapa claim umum, penyedia OIDC dapat memasukkan berbagai nilai ke dalam claim set, sehingga indeks harus menangani bentuk khas masing-masing penyedia secara terpisah
  • Karena itu, identitas mesin tidak dapat saling dipertukarkan antar-IdP OIDC, dan ini menjadi salah satu alasan PyPI menambahkan penyedia Trusted Publishing baru secara perlahan
• Jika workflow CI/CD dikompromikan, penyerang dapat membocorkan kredensial Trusted Publishing atau token ID OIDC yang menjadi benihnya
  • Ini mirip dengan saat kredensial jangka panjang berada di dalam workflow, tetapi kredensial Trusted Publishing tidak memiliki risiko cakupan dan masa hidup yang sama
  • PyPI memitigasi risiko kompromi CI/CD dengan menolak pertukaran token untuk identitas mesin yang terkait dengan trigger yang mudah disalahgunakan seperti pull_request_target

Mengapa ini bukan sinyal kepercayaan paket

• Trusted Publishing hanyalah metode autentikasi, dan tidak memberikan informasi apakah sebuah paket aman, berkualitas tinggi, atau layak digunakan
• PyPI adalah indeks publik sehingga siapa pun dapat mengunggah, dan siapa pun dapat mengunggah menggunakan Trusted Publisher
  • Kode berbahaya atau kode rentan tetap dapat diunggah melalui Trusted Publisher
  • Dalam hal ini, ia sama seperti metode autentikasi unggahan lain di PyPI, yaitu token API
• Trusted Publishing tidak wajib di PyPI dan juga tidak akan bisa diwajibkan ke depannya
  • Memaksa pengguna memakai Trusted Publishing tidak mungkin diwujudkan secara rekayasa, dan juga tidak diinginkan secara teknis maupun sosial
  • Trusted Publishing selalu bersifat opsional

Cara UI PyPI mengurangi kesalahpahaman

• PyPI berhati-hati agar pengguna tidak salah memahami status Trusted Publishing sebagai sinyal kepercayaan paket
• Tidak ada tanda centang hijau yang menunjukkan status Trusted Publishing di halaman proyek
• Tanda centang hijau untuk status yang dikendalikan pengguna hanya digunakan pada tautan yang dapat dibuktikan PyPI berasal dari sumber yang sama dengan paket itu sendiri
• URL terverifikasi hanya membuktikan bahwa pada saat verifikasi, URL tersebut berada di bawah kendali pemilik paket PyPI; itu tidak berarti ada keamanan tambahan pada URL atau proyek tersebut
• Status Trusted Publishing untuk berkas tertentu ditampilkan sebagai nilai Yes/No sederhana di detail berkas
  • Area metadata berkas tidak dirender seolah-olah berisi informasi penting bagi penilaian kepercayaan pengguna
  • Blob JSON yang berasal dari user agent klien unggahan pun tidak dirender dengan benar

Perbedaan dengan attestations

• Poin ini terpisah dari attestations PyPI
• Attestations saat ini juga menggunakan identitas mesin OIDC, tetapi bukan sinyal kepercayaan
• Attestation mirip dengan tanda tangan di atas identitas mesin, tetapi karena siapa pun dapat mengunggah ke PyPI, siapa pun juga dapat menandatangani dengan identitas mesin yang mereka kendalikan
• Adanya Trusted Publisher tidak berarti attestation pasti ada, dan adanya attestation juga tidak berarti pengguna akhir boleh memercayai identitas tertentu
• Model keandalan attestation PyPI juga mendokumentasikan hal ini

[GN⁺]

Pendapat di Lobste.rs

• Tulisan yang bagus. Trusted Publishing dan attestation (pembuktian) memberikan jaminan yang berbeda untuk mode kegagalan yang berbeda, dan keduanya juga terpisah dari apa yang disebut sebagian besar pengguna sebagai kepercayaan.

• Trusted Publishing bisa terwujud karena selama 15 tahun terakhir banyak proyek open source berpindah dari self-hosting seperti mailing list, repositori Git, pelacak bug, dan server build ke forge terpusat.
  Kini, seiring makin jelasnya kelemahan forge terpusat, proyek-proyek mulai mempertimbangkan kembali self-hosting.
  Pada 2010-an, kemudahan dan efek jejaring sosial mendorong proyek masuk ke forge terpusat, tetapi sekarang ada jauh lebih banyak faktor yang mengikat proyek tetap di sana, termasuk Trusted Publishing.
  Jangan percaya otoritas — dorong desentralisasi
  — "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

  • Trusted Publishing tidak memiliki lock-in (ketergantungan). Kapan saja dapat memakai metode autentikasi lain, termasuk host yang dapat diintegrasikan dengan PyPI.
    Ada sedikit ironi dalam menyebut autentikasi federatif sebagai salah satu bentuk lock-in.
  • Self-hosting pada praktiknya hampir selalu menjadi pilihan kalangan minoritas. Tujuan SourceForge memang untuk mengambil alih beban itu.
    Sekitar 25 tahun lalu, pada periode yang hampir sama, ada juga ASF, tetapi ASF juga membawa banyak beban tata kelola. Sebelumnya ada proyek GNU, yang lebih menekankan ideologi perangkat lunak bebas dan kurang berfokus pada layanan hosting proyek yang sistematis. Sebab GNU sudah ada bahkan sebelum muncul konsep yang jelas tentang layanan apa yang dibutuhkan proyek perangkat lunak bebas.
    Proyek perangkat lunak bebas pada 1990-an biasanya ditempatkan di layanan time-sharing universitas atau server kolokasi milik teman. Contohnya seperti PuTTY atau Hyperreal.org, tempat Apache httpd berada sebelum ASF.
    Jarang ada proyek yang tumbuh cukup besar hingga bisa membenarkan infrastruktur sendiri, dan hosting murah pun relatif baru tersedia belakangan ini.
  • Apakah ada alasan mengapa Trusted Publishing tidak bisa dilakukan di Forgejo yang di-self-host? Kalau ada, sepertinya saya melewatkannya.