Unless you audit the entire codebase prior to a manual build, from a machine you know hasnt been compromised with a key you know hasnt leaked, how is a manual build different to CI/CD securitywise?
This is called two factor auth. SMS is not considered a secure method of transport (mostly due to porting). It only solves opportunistic password compromise via password dumps.
I wasn't aware that people hated it. I very rarely struggle through it (learning curve related, probably) but the objective behavior is something I wish Linux tools would move towards.
> Could you elaborate what you're talking about? Stealing passwords/sensitive info from Chrome temporary files?
Yes. Your browser stores passwords in a reversible format locally. If it's done well it may require root/ring0 privileges to abuse, but I'm unclear on how well local secret stores actually work for application-level secrets. However, if chrome temporary data becomes 100% secure I'll just steal all your documents, ssh keys and other application metadata - thus code exec is game over.
> How can one mitigate this threat?
Don't give me code exec on your box (eg don't run malware).
On a more actionable level, sandboxing every application should mitigate lots of malicious behaviors - iOS and (I've heard) chromebooks do this well, I think MacOS has some degree of sandboxing too. That being said, I don't think it'd be a practical solution for a 'power user' such as a web developer etc given the permissions power tools require are the same ones that are damaging in the hands of an attacker.
If I have code exec on your everyday system, it's game over. There are very few viable defenses without a complete architecture overhaul which would probably remove too much usable functionality to be a viable option anyway. It's just game over.