Credential Helper

Chapter sebelumnya menutup dengan satu pertanyaan terbuka: bila token tidak boleh menempel di URL remote dan tidak disimpan git config, di mana ia tinggal? Jawabannya adalah credential helper — program kecil yang Git panggil setiap kali kredensial HTTPS dibutuhkan. Helper yang tepat membuat kita mengetik token sekali lalu melupakannya; helper yang salah menyimpannya dalam teks polos yang menunggu bocor. Chapter ini membedah mekanisme pemanggilannya, menguji dua helper bawaan (cache dan store) dengan perintah nyata, lalu menutup dengan pemetaan helper per sistem operasi.

Git Memanggil Helper Saat Kredensial Dibutuhkan #

Helper dikonfigurasi lewat satu variabel:

git config --global credential.helper 'cache --timeout=3600'

Nilai di kanan dibaca Git sebagai nama program git-credential-cache plus argumennya (--timeout=3600). Saat operasi HTTPS membutuhkan autentikasi, Git memanggil helper itu dengan tiga aksi berbeda: get (ambil kredensial yang tersimpan), store (simpan kredensial yang barusan dipakai), dan erase (hapus kredensial yang ditolak platform). Jika tidak ada helper yang menyimpan kredensial, Git bertanya ke terminal — itulah prompt Username/Password yang kita temui di Personal Access Token . Mekanisme lengkapnya terdokumentasi di gitcredentials(7) .

Helper cache: Kredensial di Memori #

Helper cache menyimpan kredensial di memori sebuah daemon kecil — bukan di berkas. Konfigurasinya:

git config credential.helper 'cache --timeout=3600'
git config --get credential.helper

Output yang Dihasilkan:

cache --timeout=3600

Nilai --timeout adalah masa hidup kredensial dalam detik: 3600 berarti satu jam, setelah itu daemon melupakannya dan prompt muncul lagi. Sandbox menjalankan siklus hidupnya secara nyata — kredensial disetorkan, lalu diminta kembali:

printf 'protocol=https\nhost=example.com\nusername=budi\npassword=YOUR_GITHUB_TOKEN\n' \
  | git credential approve
printf 'protocol=https\nhost=example.com\nusername=budi\n' | git credential fill

Output yang Dihasilkan:

protocol=https
host=example.com
username=budi
password=YOUR_GITHUB_TOKEN

Perintah fill mengembalikan kredensial utuh — bukan dari berkas mana pun, melainkan dari memori daemon. Buktinya: berkas ~/.git-credentials tidak pernah tercipta, dan satu-satunya artefak adalah socket komunikasi di ~/.cache/git/credential/:

total 8
drwx------ 2 z z 4096 Oct 13 13:57 .
drwxrwxr-x 3 z z 4096 Oct 13 13:57 ..
srwxrwxr-x 1 z z    0 Oct 13 13:57 socket

Daemon bisa dimatikan lebih awal — sekaligus melupakan seluruh kredensialnya — dengan git credential-cache exit. Kombinasi memori + timeout inilah alasan cache dianggap helper paling aman di antara bawaan Git: tidak ada berkas untuk dicuri, dan kebocoran menyusut sendiri dalam beberapa menit.

Helper store: Berkas Teks Polos #

Helper store memilih kebalikannya — kredensial ditulis permanen ke ~/.git-credentials supaya bertahan lintas sesi dan reboot. Siklus penuhnya di sandbox:

git config credential.helper store
printf 'protocol=https\nhost=example.com\nusername=budi\npassword=YOUR_GITHUB_TOKEN\n' \
  | git credential approve
cat ~/.git-credentials

Output yang Dihasilkan:

https://budi:[email protected]

Formatnya satu baris per kredensial: protokol, username, token, host — semuanya dalam teks polos. Izin berkasnya memang dibatasi:

stat -c '%a %n' ~/.git-credentials

Output yang Dihasilkan:

600 /home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-a/latihan-helper/rumah/.git-credentials

Jalur panjang itu adalah direktori rumah buatan sandbox; di mesin kita cukup ~/.git-credentials. Izin 600 berarti hanya pemilik akun yang bisa membacanya. Perlindungan itu berhenti di situ: pemilik akun adalah kita sendiri — dan siapa pun yang mendapat salinan disk, backup, atau akses ke sesi kita membaca token tanpa penghalang apa pun.

Penghapusan kredensial dilakukan lewat aksi reject:

printf 'protocol=https\nhost=example.com\nusername=budi\n' \
  | git credential reject
stat -c '%s %n' ~/.git-credentials

Output yang Dihasilkan:

0 /home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-a/latihan-helper/rumah/.git-credentials

Angka 0 adalah ukuran berkas dalam byte: baris kredensial yang cocok dihapus dan berkas dibiarkan kosong. Ini cara resmi mencabut satu token dari penyimpanan lokal tanpa menghapus berkasnya.

Plumbing: git credential fill, approve, reject #

Perintah git credential yang kita pakai di atas adalah plumbing yang sama dipakai Git internally — dan bisa dipakai untuk menguji helper mana pun tanpa melakukan push sungguhan. Alurnya empat langkah: fill mengambil kredensial (bertanya bila kosong), aplikasi memakainya, lalu approve atau reject melaporkan hasilnya. Saat tidak ada kredensial tersimpan dan terminal prompt dimatikan, fill gagal dengan pesan yang jujur:

GIT_TERMINAL_PROMPT=0 bash -c \
  "printf 'protocol=https\nhost=example.com\nusername=budi\n' | git credential fill"

Output yang Dihasilkan:

fatal: could not read Password for 'https://[email protected]': terminal prompts disabled

Dua aksi sisanya: approve menyimpan kredensial yang diterima platform, reject menghapusnya — persis siklus store di atas. Token tiruan YOUR_GITHUB_TOKEN dipakai di seluruh demo; di mesin sungguhan nilainya adalah token asli yang tidak pernah boleh tercetak.

Helper Bawaan Tiap Platform #

Git membawa cache dan store, sementara distribusi dan sistem operasi menambahkan helper yang terhubung ke brankas masing-masing:

Sandbox Linux hanya memuat cache dan store, sehingga dua baris terakhir dijelaskan dari dokumentasinya: osxkeychain dan manager bekerja dengan cara yang sama dengan demo di atas — menerima aksi get/store/erase — hanya brankasnya diganti brankas sistem operasi yang mengenkripsi isi dan menguncinya saat login. Git for Windows bahkan sudah mengatur manager sebagai bawaan, sehingga pengguna Windows memperoleh penyimpanan aman tanpa konfigurasi tambahan.

Memilih helper berarti memilih lokasi brankas. Untuk jalur SSH, pertanyaan setara adalah siapa yang memegang kunci privat saat dipakai — dan jawabannya, ssh-agent, menjadi chapter berikutnya.