Package lama yang kelihatan stabil bisa jadi titik lemah kalau artifact-nya masih bisa berubah diam-diam.
PyPI baru saja menambah guardrail penting: file baru tidak lagi bisa diupload ke release yang sudah berumur lebih dari 14 hari. Intinya sederhana: kalau sebuah versi package sudah lama ada, registry mulai memperlakukan release itu sebagai sesuatu yang seharusnya makin sulit diubah. Buat developer, ini bukan cuma berita Python. Ini pengingat bahwa yang diinstall user adalah artifact, bukan niat baik maintainer di repository.
Apa yang sebenarnya berubah di PyPI?
PyPI adalah Python Package Index, registry utama tempat banyak developer mengambil package Python lewat tool seperti pip. Dalam kebijakan baru yang diumumkan PyPI, file baru untuk release yang sudah lebih dari 14 hari akan ditolak. Jadi kalau versi 1.2.3 sudah lewat dua minggu, maintainer tidak bisa tiba-tiba menambahkan file baru ke release itu.
Detail ini penting karena satu release package bisa punya beberapa distribution file: source distribution, wheel untuk platform tertentu, metadata, dan variasi lain. Kalau registry membiarkan file baru ditambahkan jauh setelah release pertama, versi yang terlihat sama di mata user bisa punya isi baru yang tidak semua orang sadari.
PyPI sendiri menulis bahwa mereka belum tahu apakah pola ini sudah pernah dipakai untuk serangan di PyPI. Tapi secara threat model, risikonya masuk akal: attacker yang mendapat akses publishing bisa mencoba menambah file berbahaya ke release lama yang sudah dipercaya banyak orang.
Kenapa release lama yang mutable itu berbahaya?
Dalam supply chain software, trust sering terbentuk dari kebiasaan. Developer melihat package populer, versi lama, download tinggi, lalu merasa aman. Masalahnya, kalau artifact untuk versi lama masih bisa berubah, rasa aman itu bisa menipu.
Bayangin lu pin dependency ke versi tertentu karena ingin stabil. Secara mental, lu merasa “versi ini sudah fixed”. Tapi kalau file baru bisa ditambahkan ke versi yang sama, ada celah: dependency resolver, platform target, atau installer tertentu bisa mengambil file yang berbeda dari yang pernah lu audit sebelumnya.
Itu sebabnya immutability mulai jadi tema besar di package registry. Bukan berarti semua hal harus kaku total sejak detik pertama, tapi semakin tua sebuah release, semakin kecil alasan sehat untuk mengubah isinya. Kalau ada bug, biasanya lebih bersih bikin versi baru. Histori jadi jelas. Diff lebih bisa dilacak. User tahu ada perubahan.
Ini bukan cuma soal Python
Walau kabarnya datang dari PyPI, pelajarannya berlaku lintas ekosistem: npm, RubyGems, crates.io, container registry, firmware update, bahkan static build artifact. Banyak incident supply chain tidak terjadi karena source code di GitHub terlihat jahat dari awal. Kadang masalahnya muncul di jalur setelah kode ditulis: token publish bocor, workflow CI terlalu bebas, artifact tidak diverifikasi, atau release metadata bisa berubah tanpa review yang cukup.
Dalam beberapa tahun terakhir, registry dan platform developer mulai menambah friction di titik yang tepat: 2FA untuk maintainer berdampak tinggi, token scoped, provenance, package cooldown, secret scanning, dan sekarang batas mutability release. Polanya sama: ekosistem tidak bisa cuma mengandalkan “maintainer baik-baik saja”. Sistemnya juga harus membatasi blast radius saat ada akun atau workflow yang kebobolan.
Apa hubungan kebijakan ini dengan PEP 740 dan Upload 2.0?
PyPI mengaitkan perubahan ini dengan arah yang lebih besar: membuat publishing package lebih bisa diverifikasi. PEP 740 membahas digital attestations untuk package index. Sederhananya, attestation adalah bukti tambahan yang menjelaskan artifact dibuat dari mana, oleh workflow apa, dan dalam kondisi seperti apa.
PEP 694 membahas Upload 2.0 API, yaitu arah baru untuk upload artifact yang lebih eksplisit dan bisa berkembang dibanding API lama. PyPI juga menyebut staged previews sebagai bagian dari masa depan workflow release yang lebih aman. Artinya, batas 14 hari ini bukan akhir cerita. Ini satu guardrail sambil ekosistem bergerak ke model publishing yang lebih terstruktur.
Gua suka bagian ini karena realistis. Security yang sehat jarang datang dari satu tombol ajaib. Biasanya dia datang dari lapisan kecil yang saling menutup celah: artifact lebih immutable, token lebih sempit, workflow lebih bisa diaudit, dan installer lebih paham metadata trust.
Checklist praktis buat developer dan maintainer
Kalau lu maintain package atau kerja di tim yang banyak bergantung ke dependency pihak ketiga, ini checklist yang bisa dipakai minggu ini:
- Anggap artifact sebagai produk final. Yang dipakai user bukan cuma source code, tapi wheel, tarball, Docker image, firmware, atau bundle JavaScript yang benar-benar dirilis.
- Jangan diam-diam menambah file ke release lama. Kalau ada fix penting, buat versi baru yang jelas dan komunikasikan perubahan.
- Pakai token publish yang scoped. Token full-access yang hidup terlalu lama itu risiko besar, apalagi kalau disimpan di CI.
- Aktifkan 2FA dan trusted publishing kalau tersedia. Jangan tunggu package lu besar dulu baru serius.
- Simpan provenance build. Minimal, lu harus bisa jawab: artifact ini dibuat dari commit mana, workflow mana, dan siapa yang approve.
- Pin dependency dengan sadar. Pinning membantu reproducibility, tapi tetap perlu update strategy, audit, dan monitoring advisory.
- Verifikasi artifact, bukan cuma repository. Review GitHub bagus, tapi user menginstall file release. Dua hal itu harus nyambung.
Counterpoint: 14 hari bukan silver bullet
Jangan salah baca kebijakan ini sebagai “PyPI sekarang aman total”. Attacker masih bisa menyerang window 14 hari pertama. Attacker juga masih bisa publish versi baru kalau akun maintainer kebobolan. Dependency confusion, typosquatting, malicious maintainer, compromised CI, dan installer behavior tetap jadi masalah yang berbeda.
Tapi guardrail seperti ini tetap penting karena security bukan cuma soal mencegah semua serangan. Security juga soal memperkecil ruang gerak attacker dan membuat perubahan mencurigakan lebih mudah kelihatan. Release lama yang tiba-tiba berubah itu harusnya kejadian langka, bukan behavior normal.
Kenapa ini penting buat personal workflow developer?
Banyak developer Indonesia mulai pakai AI coding tools, template starter, package random dari GitHub, dan copy-paste command install dari internet. Kecepatannya naik, tapi dependency trust sering tidak ikut naik. Di titik itu, supply chain bukan lagi topik enterprise doang. Ini bagian dari hygiene kerja harian.
Gua pribadi makin melihat release artifact sebagai boundary penting. Kalau build carousel, script automation, atau service kecil, yang perlu dijaga bukan cuma file source. Output final juga harus jelas: versi mana, dibuat kapan, dari input apa, dan bisa diulang atau tidak. Prinsip yang sama berlaku dari package Python sampai konten automation.
Takeaway singkat
- PyPI sekarang menolak file baru untuk release yang sudah lewat 14 hari.
- Tujuannya mengurangi risiko release lama diracuni setelah akses publish kebobolan.
- Ini bukan jaminan aman total, tapi guardrail bagus untuk supply chain modern.
- Developer perlu memperlakukan artifact sebagai sesuatu yang perlu diaudit, bukan sekadar hasil samping dari source code.
- Kalau lu maintain package, biasakan release baru untuk perubahan baru. Jangan ubah histori diam-diam.
FAQ mini
Apakah package lama di PyPI sekarang pasti aman?
Tidak. Kebijakan ini hanya membatasi penambahan file baru setelah 14 hari. Risiko lain seperti akun maintainer kebobolan, versi baru berbahaya, atau dependency confusion tetap perlu dimitigasi.
Kenapa tidak langsung dibuat immutable total sejak release pertama?
Ekosistem package punya workflow nyata yang rumit. Kadang maintainer perlu memperbaiki distribution file tak lama setelah release. Batas 14 hari mencoba memberi ruang operasional tanpa membiarkan release lama terlalu mudah diubah.
Kalau ada bug di release lama, harus gimana?
Biasanya cara paling bersih adalah membuat release baru. Dengan begitu user bisa melihat versi baru, changelog baru, dan histori perubahan yang lebih jelas.
