I think it’s fairly parochial, and sounds quite infantile to me. Growing up (uk) we just used clockwise to tighten.

The Sixth Sense.

It’s “revelation,” singular. Like trivial pursuit.

…unless it’s running software that uses signed 32-bit timestamps, or stores data using that format.

The point about the “millennium bug” was that it was a category of problems that required (hundreds of) thousands of fixes. It didn’t matter if your OS was immune, because the OS isn’t where the value is.

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.

What are the permissions on the directory? What is command are you running to edit the file? What command are you running to delete it? (Have you got selinux turned on? What filesystem is this directory on?)

Came here to mention laser cooling; glad someone else got there first.