Event Log Verifikasi Integritas Ala Git di Pipeline Ingest
Cara sidecar content-addressed, event log append-only, dan re-hash dari disk bikin state pipeline bisa diverifikasi dan dipulihkan tanpa perbaikan tangan.
Ringkasan
File frame yang di-tamper nggak bikin planner crash, malah nge-emit action quarantine, soalnya state dibangun ulang dari event log. Caption disimpan sebagai sidecar yang namanya pakai prefix sha256, jadi teks sama dapet dedup gratis. Tapi hash chain cuma kasih tamper-evidence bukan authenticity, makanya verifikasi tetap baca ulang meta.json langsung dari disk.
Saya menambahkan subcommand caption ke kernel ingest di repo internal saya. Saat menguji skenario R71, saya menambahkan satu byte X ke file frame f0001.png lalu menjalankan planner. Saya menduga planner bakal langsung gagal total atau setidaknya melempar error parsing. Ternyata tidak. Planner justru menerbitkan action media-quarantine. Awalnya saya bingung, kenapa nggak langsung crash saja? Setelah menelusuri log event, saya sadar sistem ini nggak percaya pada metadata yang terekam. Ia membaca ulang meta.json langsung dari disk saat verify. Hash file yang terekam di log tidak membuktikan isi file sekarang. Inilah inti dari pola event log untuk verifikasi integritas: state dibangun ulang dari event, bukan dipercaya begitu saja.
Sidecar Content-Addressed dan Dedup Gratis
Di kernel itu, sidecar caption disimpan di path media/captions/<src_id>/<frame_id>.<8-karakter-sha256>.txt. Nama file memuat prefix hash dari isi teks caption itu sendiri. Artinya, teks yang sama persis menghasilkan file yang sama. Ini dedup gratis. Kalau teks berubah, nama filenya otomatis berubah. Event caption di log hanya menyimpan pointer {sidecar, sha256, deferred}, bukan teksnya. Pendekatan ini meniru filosofi dasar Git sebagai content-addressable filesystem, "a simple key-value data store" yang meng-address blob berdasarkan hash kontennya [1].
Ada satu momen yang membuktikan desain ini penting. Saat iterasi, delegate saya menemukan bug nyata: event transcribe dan refilter yang full-state ternyata menjatuhkan field captions{}. Efeknya, setelah transcribe selesai, budget caption menganggap semua frame belum berjudul dan planner meng-emit ulang action caption yang sudah selesai. Perbaikannya bukan menulis ulang log, tapi field-carry di semua site event: status turunan harus membawa serta field yang masih relevan. Model memang hanya menyuplai teks mentah, dan kernel membungkusnya dengan banner <!-- trust: untrusted --> tanpa pernah mem-parse balik teks itu sebagai struktur. Ini benteng klasik melawan injection flaw, karena "Injection flaws occur when an application sends untrusted data to an interpreter" [4]. Caption kosong? Ditolak dengan exit code 6 tanpa membuat event, dan planner tinggal re-emit.
Re-hash dari Disk, Bukan Percaya Hash Terekam
Saat verifikasi, checker membaca meta.json langsung dari disk, bukan sekadar membandingkan meta_sha256 yang terekam. Alasannya keras tapi masuk akal: checksum atas file yang bisa dimutasi tidak membuktikan isi file saat ini. Kalau meta dimutasi dengan menghapus penanda caption_deferred, checker tetap menemukannya lewat pembacaan disk dan memicu alasan keras frame-needs-caption. Kalau frame di-tamper, yang diterbitkan action media-quarantine, dan heal-nya sederhana: jalankan ulang langkah media. Status media-extracted dipulihkan, transcript dan caption yang sudah ada tetap terbawa, counter attempts naik satu. State bisa dipulihkan tanpa "perbaikan tangan" karena event log-nya append-only. Ini persis konsep Complete Rebuild di event sourcing: "We can discard the application state completely and rebuild it by re-running the events from the event log" [3].
Batas Kejujuran Hash Chain
Saya juga harus jujur soal batasannya. Hash chain memberi tamper-evidence, bukan authenticity. Tidak ada cryptographic signing di sini, dan penyerang dengan akses tulis penuh bisa membangun ulang rantai dari nol. Git sendiri secara default masih memakai SHA-1, meski SHA-256 tersedia sebagai opt-in lewat extensions.objectFormat=sha256 [1]. Event log juga punya biaya nyata: "Event storage, backups, and snapshots can also add additional complexity" [5]. Replay harus idempotent, dan event collision saat banyak proses menulis butuh optimistic concurrency control.
Detail Kecil yang Membuat Perbedaan
Banyak orang mengira integritas data cuma soal hash panjang. Padahal detail kecil di level filesystem yang sering menentukan. Di Git, hanya tiga mode blob yang valid: 100644 file biasa, 100755 executable, 120000 symlink [1]. Pembatasan ketat seperti ini mencegah anomali metadata yang jarang kelihatan. Filosofi yang sama saya bawa ke pipeline: remote-tracking state yang tersimpan selalu bernilai "yang terakhir diketahui dari komunikasi fetch atau push" [2], jadi verifikasi tinggal membandingkan yang diketahui versus yang ada di disk. Verifikasi integritas bukan ritual menempel checksum. Ia desain arsitektur yang memaksa setiap komponen membuktikan kebenarannya sendiri setiap saat, bukan mengandalkan ingatan sistem yang bisa usang atau dimanipulasi.
Sumber
[1] Pro Git — Git Internals: Git Objects
[2] Pro Git — Git Internals: Git References
[3] Martin Fowler — Event Sourcing