I sometimes think about those kinds of security problems, anf I think he underestimates how easy it is to make any machine infection persistent > But such an a

I sometimes think about those kinds of security problems, anf I think he underestimates how easy it is to make any machine infection persistent > But such an attacker would not only have to breach my development machine, such an infection of the release scripts would be awfully hard to pull through. [...] I of course do my best to maintain proper login sanitation, updated operating systems and use of safe passwords and encrypted communications everywhere. 1. Get the local user exploit at the machine. This is the hardest part, and requires most luck. But let’s say it happened for some reason. 2. Install malicious sudo and get root access. Clean up right away once you have it, because malicious sudo is a huge red flag. 3. Install a subtle exploit to persist on system. Try to avoid modifying existing binary files - maybe add .so file into unusual location, or add a fake plugin into a package. 4. Backdoor so file used by release tool. Maybe tar or sed or something like this. It will be trivial to add a caller check and invoke evil payload if we are inside the release script. The scary part is how is it is to permanently persist on a modern machine. I can easily come up with half a dozen methods which no automated tool will detect, and which would be tough to spot by manual inspection. Our developer machines are infinitely more vulnerable than those cloud servers we are working hard to secure. One mistake is all it takes. I probably don’t have to worry about it because no one cares very much about the stuff I do, but this is a very scary thought. Makes me wish I used ostree or fuix or some other system where I at least have a chance of spotting the backdoors.