• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle












  • I think unqualified freedom to say anything can lead to negative utility, pragmatically speaking. Malicious lies bring less than nothing to discourse.

    I’m concerned that the libel system can be abused, of course; and I don’t approve of arresting octogenerians under the Prevention of Terrorism Act for shouting “nonsense!” at Jack Straw. But I don’t see there being a need to draw a distinction between online and in person speech, and I think that incitement to riot isn’t something I’d typically defend.

    Having said that: I hope the woman in question (who has a history of being a deniable pot-stirrer) gets a trial rather than copping a plea, because the bounds of these things are worth testing.








  • The test case purported to be bad data, which you presumably want to test the correct behaviour of your dearchiver against.

    Nothing this did looks to involve memory safety. It uses features like ifunc to hook behaviour.

    The notion of reproducible CI is interesting, but there’s nothing preventing this setup from repeatedly producing the same output in (say) a debian package build environment.

    There are many signatures here that look “obvious” with hindsight, but ultimately this comes down to establishing trust. Technical sophistication aside, this was a very successful attack against that teust foundation.

    It’s definitely the case that the stack of C tooling for builds (CMakeLists.txt, autotools) makes obfuscating content easier. You might point at modern build tooling like cargo as an alternative - however, build.rs and proc macros are not typically sandboxed at present. I think it’d be possible to replicate the effects of this attack using that tooling.