buck2

threat model: you are running buck2, you could attach a debugger to it too, so this is not meaningful to security in general. purpose: capture RE traffic in a decryptable form without putting anything actually in the middle, using tcpdump and then decoding with wireshark or similar.

Problem: We have local execution, and there's no easy to reach for buck command for getting the action cache digests of things that were uploaded. Furthermore, buck log what-uploaded is too tempting to reach for (yet is surprisingly the wrong tool). Solution: Make buck log what-uploaded print out the digests of the action cache entries uploaded in a build. Test plan:

Problem: Tests (including but not limited to Haskell) sometimes use the libc locales to interact with character sets; by default LANG=C and this causes corruption of UTF-8 text being passed through various libc text functions (it's real bad in Haskell where you can't print some UTF-8 to stdout without throwing an exception!). Buck2 eats those environment variables (including LANG), so that these tests are always broken. I presume Meta defaults this to something deterministic in tpx somewhere. Solution: If buck2 is going to eat the env-vars, it's probably best that we make it have reasonable behaviour for those who haven't yet noticed being bitten by their programs running in the C locale. Weakly default to C.UTF-8 for LC_CTYPE when running tests. Allow basically anything to override it: --env, invoker's environment, etc. We eat all other locale variables, which wind up defaulting to C (which is fine). I checked with an agent that with C.UTF-8 and en_US.UTF-8 the transliteration to ascii is the same. Collation order is codepoint order with C.UTF-8 unlike en_US where it is more human-friendly. Uncertainties: I don't know if it's smart to take what the caller environment contains for LC_CTYPE. That decision could go either way, to be honest: buck is pretty aggressive on test confinement, but on the other hand, it's an explicit signal from the user.