Chapter sebelumnya menandatangani commit dengan kunci latihan yang lahir dari satu baris --quick-gen-key. Kunci untuk pekerjaan sungguhan menuntut kendali lebih: algoritma dan ukuran dipilih sendiri, subkey enkripsi dipisahkan dari kunci penandatangan, dan masa berlaku direncanakan sejak awal. Chapter ini menuntaskan setup GPG penuh — pembuatan kunci lewat berkas parameter, pendaftaran ke Git, penandatanganan commit dan tag, sampai menyiapkan kunci publik untuk platform — lalu menutup dengan konsep rotasi agar kunci tetap sehat selama bertahun-tahun.

Pembuatan Kunci Penuh dengan Modus Batch #

Jalur interaktifnya adalah gpg --full-generate-key: GPG menanya jenis kunci, ukuran, masa berlaku, identitas, lalu passphrase — nyaman untuk manusia, mustahil untuk skrip. GPG menyediakan jalan kedua: berkas parameter yang menjawab semuanya sekaligus lewat gpg --batch --gen-key. Inilah isi kunci-param.txt di sandbox:

text 
%no-protection
Key-Type: RSA
Key-Length: 3072
Key-Usage: sign
Subkey-Type: RSA
Subkey-Length: 3072
Subkey-Usage: encrypt
Name-Real: Budi Santoso
Name-Email: [email protected]
Expire-Date: 0

Baris demi barisnya: %no-protection membuat kunci tanpa passphrase (khusus latihan otomatis — pada kunci sungguhan, hilangkan baris ini agar GPG menanyakan passphrase lewat pinentry); Key-Type/Key-Length memilih RSA 3072 untuk kunci utama yang hanya bertugas sign; blok Subkey-* membuat subkey kedua khusus encrypt — pemisahan tugas inilah yang membuat subkey enkripsi bisa diganti tanpa menyentuh identitas penandatangan; Name-* menjadi identitas yang terbaca pada verifikasi; Expire-Date: 0 berarti tanpa kedaluwarsa (kebijakan yang lebih sehat dibahas di section rotasi). Jalankan:

bash 
export GNUPGHOME=work/sandbox/keamanan-dan-akses/part-b/gpg-utama
gpg --batch --gen-key kunci-param.txt
text 
gpg: keybox '/home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/gpg-utama/pubring.kbx' created
gpg: /home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/gpg-utama/trustdb.gpg: trustdb created
gpg: directory '/home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/gpg-utama/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/gpg-utama/openpgp-revocs.d/E1ED559906E81BF05188B4714A03BD33DED38212.rev'

Sertifikat pencabutan disimpan terpisah dari kunci: bila kunci privat hilang, sertifikat inilah satu-satunya cara menyebarluaskan kabar “kunci ini tidak dipercaya lagi”. Struktur hasilnya terbaca dari daftar kunci:

bash 
gpg --list-secret-keys --keyid-format long
text 
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/gpg-utama/pubring.kbx
--------------------------------------------------------------------------------------------------
sec   rsa3072/4A03BD33DED38212 2026-10-13 [SC]
      E1ED559906E81BF05188B4714A03BD33DED38212
uid                 [ultimate] Budi Santoso <[email protected]>
ssb   rsa3072/085F7E1F902595AA 2026-10-13 [E]

Bedah singkatnya:

BarisMaknanya
sec rsa3072/4A03...kunci privat utama, tugas SC (sign + certify) — inilah yang dijadikan user.signingkey
uid [ultimate]identitas yang melekat; [ultimate] karena keyring ini pemiliknya
ssb rsa3072/085F...subkey privat kedua, tugas E (encrypt) — tidak dipakai Git

ID yang kita butuhkan ada setelah garis miring: 4A03BD33DED38212 — format long yang Git terima langsung. ID ini acak per pembuatan kunci, jadi nilainya di mesin pembaca berbeda.

Mendaftarkan Kunci ke Git #

Dua konfigurasi terlibat. Pertama user.signingkey — ID kunci penandatangan:

bash 
cd work/sandbox/keamanan-dan-akses/part-b/latihan-gpg
git config user.signingkey 4A03BD33DED38212
git config --get user.signingkey
text 
4A03BD33DED38212

Kedua gpg.program — program yang Git panggil untuk menandatangani. Nilai bawaannya sudah gpg:

bash 
git config --get gpg.program
text 
(kosong — memakai bawaan: gpg)

Keluaran kosong berarti Git memakai bawaan. Konfigurasi ini baru relevan pada distribusi lama yang memisahkan gpg (versi 1.x) dari gpg2 — di situ perintahnya git config --global gpg.program gpg2. Di distro modern, gpg adalah 2.x dan tidak ada yang perlu diatur. Verifikasi cepatnya: gpg --version.

Menandatangani Commit dan Tag #

Commit ditandatangani seperti biasa — -S, atau tanpa flag bila commit.gpgsign true aktif sejak Signed Commits :

bash 
git commit -S -m "Tambah keranjang belanja"
git log --show-signature -1
text 
commit a5db822e9e265beecedcc5bc32b91a920b908243
gpg: Signature made Tue Oct 13 21:34:32 2026 WIB
gpg:                using RSA key E1ED559906E81BF05188B4714A03BD33DED38212
gpg: Good signature from "Budi Santoso <[email protected]>" [ultimate]
Author: Budi Santoso <[email protected]>
Date:   Tue Oct 13 21:34:32 2026 +0700

    Tambah keranjang belanja

Tag punya alur sendiri. Tag beranotasi menyimpan objek tersendiri — penanda, pesan, pointer commit — dan flag -s (huruf kecil) menandatangani objek tag itu, bukan commit yang ditunjuknya:

bash 
git tag -s v1.1.0 -m "Rilis 1.1.0"
bash 
git tag -v v1.1.0
text 
gpg: Signature made Tue Oct 13 21:34:32 2026 WIB
gpg:                using RSA key E1ED559906E81BF05188B4714A03BD33DED38212
gpg: Good signature from "Budi Santoso <[email protected]>" [ultimate]
object a5db822e9e265beecedcc5bc32b91a920b908243
type commit
tag v1.1.0
tagger Budi Santoso <[email protected]> 1791902072 +0700

Rilis 1.1.0

Baris Good signature menutup pertanyaan keaslian, lalu objek tag-nya ditampilkan utuh: tag bertanda tangan adalah pernyataan bersejarah — “rilis v1.1.0 dibuat oleh pemegang kunci ini, menunjuk commit ini”. Pengunduh rilis tahu tag itu tidak ditukar diam-diam. Perbedaan tanda tangan commit vs tag, beserta alur rilisnya, dibahas di Menandatangani Commit dan Tag .

Menyiapkan Kunci Publik untuk Platform #

Penandatanganan hanya berguna bila orang lain bisa memverifikasi. Kunci publik diekspor dalam format teks:

bash 
gpg --export --armor 4A03BD33DED38212
text 
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBGrOQXYBDADSmRmIYP36HUfBza+fJ1DcZUrx3QANqe1rCX3iILXuh53s5ni7
JfGmzjnVxnfzOpi4Gp6X3abhVMdPNf9qkT7rlJn+K2QcutNGE/hDtkdLdvBdkoSV
(dipotong)

Blok inilah yang didaftarkan ke platform: GitHub menyimpannya di pengaturan akun — alur lengkapnya di dokumentasi penambahan kunci GPG — lalu memverifikasi setiap commit dan tag yang kita dorong dan menampilkan lencana Verified kepada semua pengunjung. Efeknya besar: pembaca tidak perlu mengimpor kunci manual untuk mempercayai identitas; platform memverifikasi atas nama mereka. Kunci yang sama tetap perlu diimpor manual untuk verifikasi lokal dengan git log --show-signature — lencana platform dan verifikasi GPG lokal adalah dua jalur menuju kesimpulan yang sama.

Rotasi Kunci: Subkey dan Masa Berlaku #

Dua strategi rotasi, keduanya tanpa memutus verifikasi riwayat lama.

Strategi pertama: masa berlaku pada subkey penandatangan. Subkey baru ditambahkan lewat gpg --quick-add-key, Git diarahkan ke subkey baru, dan subkey lama dibiarkan berakhir — kunci utama yang menjadi identitas tidak berganti. Riwayat lama tetap terverifikasi karena kunci utama — dan kunci publiknya — masih sama.

Strategi kedua: kedaluwarsa pada kunci utama. Perintah gpg --quick-set-expire <fingerprint> <waktu> memberi kunci tenggat, misalnya 1y. Kedaluwarsa bukan kematian: selama pemegangnya masih menguasai kunci, tenggat diperpanjang dengan perintah yang sama, dan setiap perpanjangan memaksa bertanya “apakah kunci ini masih layak hidup?”. Bila kunci dicuri, pencuri paling jauh bisa memalsukan sampai tenggat — setelah itu verifikasi berhenti sendiri.

Satu keluhan lama tentang GPG tetap valid: rantai alatnya — keyring, agent, trustdb — terasa berat untuk sekadar menandatangani commit. Bagi yang sudah membawa kunci SSH untuk akses repository, Git menawarkan jalan yang jauh lebih ringan: memakai kunci SSH itu sendiri sebagai penandatangan. Chapter berikutnya mengujinya.