Jangan menganggap Trusted Publishing sebagai sinyal kepercayaan paket

• Trusted Publishing di sini bukan berarti paketnya layak 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, serta menerbitkan kredensial publikasi yang berumur pendek dan cakupannya sempit sebagai pengganti token API jangka panjang untuk mengurangi paparan kredensial jangka panjang yang berlebihan izinnya
• Setelah PyPI merilisnya pada 2023, pendekatan ini menyebar ke npm, RubyGems, crates.io, NuGet, dan lainnya, tetapi kompleksitas model data, penanganan berbeda per penyedia OIDC, dan kemungkinan kompromi CI/CD masih tetap ada
• PyPI tidak menonjolkan status Trusted Publishing dengan tanda centang hijau di halaman proyek, dan hanya menampilkannya sebagai metadata Yes/No sederhana pada detail file agar tidak disalahartikan sebagai sinyal keamanan
• Trusted Publishing dan attestation PyPI hanya menunjukkan autentikasi unggahan atau apakah penandatanganan dilakukan berdasarkan identitas mesin, dan tidak bisa dipakai untuk menilai keamanan atau kualitas paket sebelum identitas tersebut dipercaya secara terpisah

---

Cakupan kepercayaan yang ditangani Trusted Publishing

• Trusted Publishing bukan fitur yang menyuruh manusia memercayai sebuah paket, melainkan metode autentikasi yang menangani kepercayaan antarmesin
• Melihat Trusted Publishing sebagai pertanyaan apakah manusia bisa memercayainya atau tidak adalah kekeliruan kategori
• Intinya adalah membangun hubungan kepercayaan untuk autentikasi unggahan antara identitas mesin eksternal seperti alur kerja CI/CD dan identitas proyek pada indeks paket

Struktur Trusted Publishing di PyPI

• “Trusted Publishing” adalah istilah yang dipakai PyPI untuk menjelaskan metode autentikasi di atas federasi OpenID Connect
• PyPI merilisnya pada 2023, dan setelah itu npm, RubyGems, crates.io, NuGet juga mengadopsinya
• Titik berangkatnya adalah dua masalah
  • Token API indeks yang merupakan kredensial jangka panjang sulit dikelola dengan aman, dan pengguna sulit menentukan hak akses minimum serta masa berlaku sehingga mudah menjadi terlalu berizin
  • Banyak pengguna membuat kredensial untuk dimasukkan ke platform CI/CD, sementara platform CI/CD juga memiliki mekanisme melalui OIDC untuk membuktikan kontrol atas identitas mesin tertentu
• Pengguna mendaftarkan Trusted Publisher berupa identitas mesin CI/CD sekali saja ke indeks paket, lalu ketika CI/CD menyajikan token identitas, indeks memverifikasinya dan menerbitkan kredensial publikasi yang berumur pendek dan cakupannya sempit

Keunggulan dan batasan yang masih tersisa

• Pendekatan kredensial berumur pendek dengan cakupan yang ditentukan sendiri dinilai sangat berhasil bagi pengguna PyPI
  • Pengguna lebih menyukai pendekatan yang tidak mengharuskan mereka mengelola kredensial secara langsung saat tidak perlu
  • Proyek open source besar dan perusahaan lebih menyukai sifat bahwa hak publikasi terhubung ke identitas sumber alih-alih ke maintainer individu
• Trusted Publishing tetap menyisakan kompleksitas struktural
  • Fitur “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
  • Penyedia OIDC dapat memasukkan beragam nilai ke dalam kumpulan claim selain beberapa claim umum, sehingga indeks harus menangani bentuk khas tiap penyedia secara terpisah
  • Akibatnya, identitas mesin tidak saling dapat dipertukarkan antar OIDC IdP, dan ini menjadi salah satu alasan PyPI menambahkan penyedia Trusted Publishing baru secara lambat
• Jika alur kerja 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 alur kerja, tetapi kredensial Trusted Publishing tidak membawa risiko cakupan dan masa hidup yang sama
  • PyPI mengurangi risiko kompromi CI/CD dengan menolak pertukaran token untuk identitas mesin yang terkait dengan pemicu 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 bisa mengunggah, dan siapa pun juga bisa mengunggah memakai Trusted Publisher
  • Malware maupun kode yang rentan dapat diunggah melalui Trusted Publisher
  • Dalam hal ini, statusnya sama dengan token API sebagai metode autentikasi unggahan lain di PyPI
• Trusted Publishing tidak diwajibkan di PyPI dan tidak akan bisa menjadi kewajiban di masa depan
  • Memaksakan Trusted Publishing kepada pengguna tidak realistis secara rekayasa, dan juga tidak diinginkan secara teknis maupun sosial
  • Trusted Publishing akan selalu bersifat opsional

Cara UI PyPI mengurangi salah paham

• PyPI berhati-hati agar pengguna tidak salah mengartikan 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 dipakai 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, dan tidak berarti ada keamanan tambahan pada URL atau proyek tersebut
• Status Trusted Publishing untuk file tertentu ditampilkan sebagai nilai Yes/No sederhana di detail file
  • Area metadata file tidak dirender seolah-olah itu informasi penting untuk penilaian kepercayaan pengguna
  • Bahkan JSON blob dari user agent klien unggahan pun tidak dirender secara menonjol

Perbedaan dengan attestation

• Poin ini terpisah dari attestation milik PyPI
• Attestation saat ini juga menggunakan identitas mesin OIDC, tetapi bukan sinyal kepercayaan
• Attestation mirip dengan tanda tangan di atas identitas mesin, tetapi karena siapa pun bisa mengunggah ke PyPI, siapa pun juga bisa 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 poin ini dalam dokumentasi

[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.