Blog
Go, Rust, Linux, cryptography and UK privacy law. One properly researched article a day.
Page 2 of 2. Working notes from a software engineer who spends the day in Go, Rust and Linux and the evening reading legislation. Each post takes one specific question and answers it properly: why a worker pool deadlocks, what fsync really promises, how to enrol a TPM into LUKS without locking yourself out, what a technical capability notice can actually compel. Step-by-step how-tos sit alongside the deep dives, everything is checked against source code or primary legislation, and nothing is padded to hit a word count.
Subscribe with the Atom feed to get each post as it lands.
-
fsync() returning zero feels like a promise the bytes are safe. Page cache, errseq_t, directory entries and disk caches make that promise weaker than it looks.
-
Enrolling a TPM2 chip into a LUKS2 volume with systemd-cryptenroll: PCR selection, PIN protection and the kernel-update trap that locks people out.
-
Ofcom's section 121 powers under the Online Safety Act, what client-side CSAM scanning would involve, and why 'technically feasible' may be a category error.
-
A byte-level look at what a WebAuthn assertion signs: the origin, the challenge and the RP ID hash, and why that binding defeats classic phishing proxies.
-
How to set up LUKS2 disk encryption with the header on a separate USB key: the commands, the backup steps, and what it does and does not protect against.
-
tokio::select! drops the losing branch's future, and for some Tokio methods that means silently lost bytes and desynced protocols. How to spot and fix it.
-
How to choose Argon2id memory, time and parallelism parameters in Go that you can actually defend, with a working hash-and-verify implementation.
Page 2 of 2
← Newer posts