https://cuelang.org/. I deal with a lot of k8s at work, and I’ve grown to hate YAML for complex configuration. The extra guardrails that Cue provides are hugely helpful for large projects.

If it’s a publicly-accessible repo, then immediately revoke the key and leave it. Force-pushing isn’t good enough because the old commit will still be tracked by Git until the garbage collector kicks in, and you don’t have control over the GC on GitHub (not sure about other providers).

If it’s an internal repo that’s only accessible by employees, then you probably should still revoke it, but you’ve got more leeway. Usually I’d create a ticket to revoke it when there’s time, unless this is particularly sensitive.

Probably because the individual engineers working on Takeout care about doing a good job, even though the higher-ups would prefer something half-assed. I work for a major tech company and I’ve been in that same situation before, e.g. when I was working on GDPR compliance. I read the GDPR and tried hard to comply with the spirit of the law, but it was abundantly clear everyone above me hadn’t read it and only cared about doing the bare minimum.

There’s no financial incentive for them to make is easy to leave Google. Takeout only exists to comply with regulations (e.g. digital markets act), and as usual, they’re doing the bare minimum to not get sued.

For extra fun, you can name your variables using solely Unicode invisible characters (e.g. non-breaking space) so they’re impossible to visually distinguish

Unfortunately, retrofitting CSP on an existing site can be nightmare, especially if you have external dependencies. At my job, we spent months trying to enable CSP on one our oldest sites, but ultimately gave up because one of our dependencies won’t work unless we added “unsafe-inline” everywhere, which kinda defeats the whole point of CSP.