Commit Git Bertanda Tangan — Apa Arti Sebenarnya dari “Verified”?
Commit Git Bertanda Tangan — Apa Arti Sebenarnya dari “Verified”?
Sebuah commit di platform hosting kadang memiliki label “Verified” yang meyakinkan. Wajar jika label itu dibaca sebagai “perubahan ini berasal dari orang yang namanya tercantum, sudah ditinjau, dan aman dipakai.” Namun, tafsiran itu jauh lebih besar daripada yang dapat dibuktikan oleh tanda tangan digital.
Commit Git bertanda tangan memang berguna, tetapi kegunaannya spesifik. Tanda tangan dapat membantu pemeriksa memastikan bahwa sebuah kunci kriptografis membuat tanda tangan untuk commit tertentu, sesuai aturan Git dan platform hosting. Tanda tangan itu sendiri tidak memberi tahu apakah perubahannya baik, apakah kuncinya saat itu dikendalikan oleh orang yang diharapkan, atau apakah perangkat lunak hasilnya dibangun dengan aman.
Yang Dihubungkan oleh Commit Bertanda Tangan
Git menyimpan commit sebagai object yang memuat informasi seperti tree yang dicatat, commit induk, metadata author dan committer, serta pesan commit. Tanda tangan dilekatkan pada commit tersebut. Saat verifikasi dilakukan, Git menggunakan public key terkait untuk memeriksa apakah tanda tangan cocok dengan data yang ditandatangani.
Ini memberi kita pernyataan penting tentang integritas: data yang ditandatangani tidak berubah dengan cara yang membuat tanda tangannya menjadi tidak valid. Kita juga memperoleh identitas kunci yang bisa ditelusuri. Kata pentingnya adalah ditelusuri. Nama atau alamat email yang tampil di sebelah kunci adalah metadata dan masukan kebijakan, bukan bukti mandiri bahwa manusia tertentu memang menghendaki perubahan tersebut.
Bayangkan seperti memeriksa segel pada amplop. Segel dapat menunjukkan bahwa amplop dibuka atau diubah setelah disegel. Segel tidak memberi tahu apakah isinya benar, apakah orang yang menyegelnya berwenang, atau apakah instruksi di dalamnya bijaksana.
Cara Git Menandatangani dan Memeriksa Commit
Dokumentasi Git menjelaskan cara menandatangani commit dan tag dengan signing key yang telah dikonfigurasi. Tanda tangan dapat diminta untuk satu commit dengan -S:
git commit -S -m "Describe the change"
Kunci dan program penanda tangan yang digunakan bergantung pada konfigurasi lokal. Referensi konfigurasi Git mendokumentasikan pengaturan seperti format tanda tangan dan kunci yang dipilih. Project juga dapat meminta tanda tangan secara default dengan pengaturan seperti berikut:
git config commit.gpgsign true
Pengaturan itu mengubah perilaku default commit dalam cakupan konfigurasi terkait. Pengaturan tersebut tidak menetapkan kebijakan kepercayaan untuk semua kunci di repository, dan tidak membuat commit historis yang belum bertanda tangan menjadi bertanda tangan.
Git dapat menampilkan informasi tanda tangan saat menampilkan riwayat. Git Book resmi mendokumentasikan git log --show-signature dan placeholder %G? untuk format pretty dalam memeriksa status tanda tangan. Pemeriksa sebaiknya memperlakukan hasilnya sebagai salah satu masukan keputusan, bukan sebagai audit keamanan yang lengkap.
Yang Ditambahkan Platform Hosting
Platform hosting dapat menghubungkan public key dengan akun, memeriksa apakah alamat email diizinkan untuk akun tersebut, dan menampilkan status seperti “Verified”. GitHub mendokumentasikan tiga keluarga tanda tangan untuk commit: GPG, SSH, dan S/MIME. Antarmukanya juga memungkinkan pembaca melihat detail di balik label status.
Kebijakan di tingkat platform ini berguna karena tanda tangan mentah biasanya tidak datang dengan semua konteks yang dibutuhkan pembaca. Akun mana yang boleh menggunakan kunci itu? Apakah alamat emailnya sudah diverifikasi? Apakah kunci tersebut masih diterima? Bagaimana platform menangani kunci yang dicabut atau dihapus? Pertanyaan-pertanyaan itu menjadi bagian dari kebijakan platform dan pemeriksa, bukan sekadar format object Git.
Ada perbedaan praktis antara “tanda tangan valid secara matematis” dan “saat ini dikenali oleh host”. Instalasi Git lokal mungkin memiliki public key dan dapat memvalidasi tanda tangan, sedangkan platform hosting tidak memiliki kebijakan akun yang cocok. Sebaliknya, badge platform mencerminkan aturan verifikasi platform tersebut saat ini; badge itu bukan sertifikat universal dari setiap orang yang mungkin memakai repository.
Yang Tidak Dibuktikan oleh “Verified”
Tanda tangan valid bukanlah code review. Commit tersebut mungkin berisi bug, default yang tidak aman, dependency rentan, atau perubahan yang tidak memenuhi kebutuhan project. Status review harus berasal dari proses review, protected branch, test, dan aturan penerimaan project sendiri.
Tanda tangan juga bukan bukti bahwa orang yang ditampilkan menulis setiap baris secara pribadi. Git memiliki field author dan committer yang terpisah, dan workflow dapat melibatkan rebase, cherry-pick, automation, atau maintainer yang menerapkan patch orang lain. Tanda tangan dapat menunjukkan bahwa sebuah kunci menandatangani commit; menafsirkan fakta itu sebagai kepengarangan pribadi memerlukan konteks tambahan.
Tanda tangan tidak membuktikan bahwa kunci tersebut tidak pernah disusupi. Jika penyerang memperoleh akses ke private key, mereka mungkin dapat membuat tanda tangan valid sampai kompromi terdeteksi dan kunci diganti atau dicabut. Penjagaan kunci, pemulihan, rotasi, dan keamanan akun tetap penting.
Terakhir, tanda tangan commit tidak membuktikan bagaimana artifact release dibuat. Package mungkin dibangun dari commit berbeda, dengan dependency berbeda, pada build system yang tidak tepercaya atau tidak dikendalikan dengan baik. Jalur dari source ke artifact memerlukan bukti tersendiri.
Tiga Kontrol yang Mudah Tertukar
Commit signature
Ini menjawab pertanyaan sempit: apakah tanda tangan pada commit dapat divalidasi dengan public key, dan apakah kunci tersebut memenuhi kebijakan kepercayaan pemeriksa? Kontrol ini membantu melindungi hubungan antara kunci dan object Git tertentu.
Developer sign-off
Dokumentasi kontribusi Linux kernel menjelaskan baris Signed-off-by: sebagai sertifikasi bahwa kontributor membuat karya tersebut, memiliki hak untuk mengirimkannya, atau menerimanya berdasarkan ketentuan yang berlaku. Ini adalah pernyataan proses project. Mekanismenya tidak sama dengan tanda tangan commit kriptografis, meskipun keduanya memakai kata “signed”.
Build provenance
SLSA menjelaskan provenance sebagai informasi tentang bagaimana artifact dibuat. Persyaratannya membahas hal seperti keaslian provenance, identitas build platform, dan isolasi antar-build. Ini adalah batas yang berbeda dari source commit. Proses release yang tepercaya dapat menghubungkan revisi source yang ditinjau dengan artifact tertentu, tetapi tanda tangan commit saja tidak menciptakan hubungan tersebut.
Workflow yang Proporsional untuk Project Kecil
Project kecil tidak harus langsung meniru semua kontrol distributor perangkat lunak besar. Langkah awalnya adalah memperjelas pertanyaan:
- Identifikasi kunci dan akun yang diharapkan menandatangani perubahan.
- Periksa status tanda tangan dan identitas kunci, bukan hanya mengandalkan badge.
- Tinjau diff, test, perubahan dependency, dan catatan release yang sebenarnya.
- Lindungi branch penting agar tanda tangan bukan satu-satunya kontrol di sekitar merge.
- Untuk release, catat revisi source yang menghasilkan artifact dan tempat build berjalan.
- Rencanakan apa yang dilakukan saat kunci hilang, disusupi, atau diganti.
Langkah-langkah ini memang kurang semenarik label hijau. Namun, pertanyaan yang dijawab lebih berguna: siapa yang berwenang membuat perubahan ini? Apa tepatnya yang berubah? Apakah perubahan itu ditinjau? Bisakah file yang diunduh pengguna dihubungkan dengan source yang diperiksa? Tanda tangan membantu menjawab sebagian pertanyaan tersebut, tetapi tidak semuanya.
Kesimpulan
Commit Git bertanda tangan paling baik dipahami sebagai bukti, bukan putusan. Tanda tangan dapat memperkuat integritas dan keterlacakan riwayat source ketika kunci dan kebijakan verifikasi dikelola dengan hati-hati. Tanda tangan tidak menggantikan code review, analisis dependency, keamanan akun, branch protection, atau build provenance.
Saat commit berikutnya menampilkan “Verified”, respons yang berguna bukan kepercayaan buta atau penolakan total. Tanyakan apa yang diverifikasi, oleh siapa, terhadap kunci yang mana, dan apa yang masih berada di luar pernyataan itu. Keamanan menjadi lebih jelas ketika sebuah label kecil tidak diminta memikul seluruh proses.