Zip Plugin-mu Bisa Dipercaya? Tanda Tangani Dulu

File ZIP rilis plugin WordPress terlihat polos. Namun, begitu file itu keluar dari laptopmu, masuk GitHub, lalu dipakai user di server produksi, kamu kehilangan satu hal penting: bukti bahwa file itu masih sama.

Di sinilah artifact signing jadi pembeda antara “semoga aman” dan “bisa diverifikasi”. Untuk author plugin WordPress dan maintainer OSS, artifact signing sebelum release WordPress.org atau GitHub membantu user mengecek integritas zip atau tar sebelum deploy.

Kenapa Checksum Saja Belum Cukup?

Checksum seperti SHA256 memang berguna. Kamu bisa memberi user nilai hash, lalu mereka mencocokkannya dengan file yang diunduh.

Namun, ada masalah besar. Kalau attacker bisa mengganti file release, sering kali ia juga bisa mengganti checksum yang tampil di halaman release.

Karena itu, checksum menjawab pertanyaan, “Apakah file ini sama dengan hash?” Sementara signature menjawab pertanyaan yang lebih penting, “Hash ini benar dari maintainer yang sah?”

Artifact Signing dalam Rilis WordPress Plugin

Dalam konteks plugin WordPress, artifact biasanya berupa:

• plugin-name.zip untuk distribusi manual.
• .tar.gz untuk GitHub source archive.
• SBOM jika kamu sudah memetakan dependensi.
• checksums.txt untuk daftar hash tiap file rilis.

Idealnya, kamu menandatangani file final yang benar-benar akan user unduh. Jadi, jangan sign folder source sebelum build, lalu menganggap ZIP hasil CI otomatis ikut aman.

Framework 3B: Build, Bind, Broadcast

Biar workflow-mu rapi, pakai model sederhana ini: Build, Bind, Broadcast.

1. Build: Buat Artefak Final Sekali Saja

Bangun ZIP plugin dari tag Git yang immutable. Selain itu, pastikan dependency install memakai lockfile, misalnya composer.lock atau package-lock.json.

Jika build bisa berubah meski commit sama, signature cuma membuktikan artefak itu ditandatangani, bukan bahwa build-nya reproducible.

2. Bind: Ikat Artefak ke Identitas Maintainer

Gunakan tool seperti Sigstore Cosign, GPG, atau minisign. Untuk banyak maintainer OSS, Sigstore menarik karena bisa mengikat signature ke identitas OIDC GitHub Actions.

Contoh alur sederhana:

sha256sum my-plugin.zip > checksums.txt
cosign sign-blob --yes my-plugin.zip --output-signature my-plugin.zip.sig
cosign verify-blob my-plugin.zip --signature my-plugin.zip.sig --certificate my-plugin.zip.pem

3. Broadcast: Publikasikan Cara Verifikasi, Bukan Cuma File

Release note yang bagus bukan hanya “download ZIP di sini”. Tambahkan instruksi verifikasi singkat, lokasi public key atau certificate, serta hash SHA256.

Dengan begitu, user yang deploy ke server klien punya prosedur jelas sebelum memasang plugin.

Hal yang Sering Terbalik: Jangan Sign Terlalu Awal

Banyak maintainer menandatangani commit atau tag, lalu berhenti di situ. Itu bagus, tetapi belum cukup.

Kenapa? Karena artefak release sering lahir setelah tag dibuat. CI bisa menambah vendor folder, minify asset, menghapus test file, atau membuat ZIP baru.

Jadi, tanda tangani hasil akhirnya. Signed tag membuktikan source, sedangkan signed artifact membuktikan paket yang user deploy.

Contoh Checklist Release Aman

• Buat tag Git yang ditandatangani.
• Jalankan build dari tag, bukan branch bebas.
• Generate ZIP final plugin.
• Buat checksums.txt dengan SHA256.
• Sign ZIP dan checksums.
• Upload ZIP, signature, certificate atau public key ke GitHub Releases.
• Tambahkan instruksi verifikasi di release note.
• Jika rilis ke WordPress.org, pastikan file ZIP lokal cocok dengan source tag yang kamu push ke SVN.

Untuk konteks supply chain yang lebih luas, kamu juga bisa membaca artikel internal tentang bom dependensi plugin WordPress dan auto-merge dependency tanpa jadi korban supply chain.

GitHub Actions Mini Workflow

Berikut pola minimal yang bisa kamu adaptasi:

name: release
on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write
  id-token: write

jobs:
  build-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: sigstore/cosign-installer@v3
      - run: zip -r my-plugin.zip my-plugin -x '*.git*'
      - run: sha256sum my-plugin.zip > checksums.txt
      - run: cosign sign-blob --yes my-plugin.zip --output-signature my-plugin.zip.sig --output-certificate my-plugin.zip.pem

Rujukan resminya bisa kamu cek di Cosign GitHub, GitHub Actions security hardening, dan panduan SVN WordPress.org.

FAQ

Apakah artifact signing wajib untuk plugin WordPress?

Belum wajib untuk semua plugin. Namun, jika plugin-mu dipakai di bisnis, agency, WooCommerce store, atau environment klien, artifact signing memberi lapisan trust yang sangat bernilai.

Apa beda signed tag dan signed artifact?

Signed tag membuktikan source Git berasal dari maintainer. Signed artifact membuktikan file ZIP atau tar yang diunduh user belum berubah sejak maintainer menandatanganinya.

Tool mana yang paling mudah untuk maintainer OSS?

Sigstore Cosign biasanya paling nyaman untuk GitHub Actions karena mendukung keyless signing via OIDC. Namun, GPG atau minisign tetap valid jika kamu mengelola key dengan disiplin.

Penutup: Trust Harus Bisa Dicek

User nggak harus percaya begitu saja pada file rilis plugin-mu. Mereka seharusnya bisa memverifikasi.

Mulai dari satu langkah kecil: sign ZIP rilis berikutnya, publikasikan checksum, lalu tulis instruksi verifikasi. Kalau kamu serius membangun plugin WordPress atau proyek OSS jangka panjang, artifact signing bukan hiasan keamanan. Itu bukti profesionalisme.