I can confirm there's real wisdom in this approach, lol. Nothing bad had happened to me for a while so I decided to update that one computer to ubuntu noble and YUP, immediately bricked by some UEFI problem. Ok cool, it's not like 2004 anymore, this will probably be a quick fix.. 3 hours later...
In the newest iteration of a time-honored tradition, grub (and/or whatever distro's treatment of it) has been finding all kinds of ways to break upgrades for 30 years. If you're on the happy path you can probably go a long time without a problem.
But when you're the unlucky one and need to search for a fix, and you're checking hardware/distro/date details in whatever forums or posts, and that's when you notice that the problems don't actually ever stop.. it just hasn't happened to you lately.
No that's not what I mean, I mean technologically, UEFI is flashed in your motherboard and there isn't any way for an OS to mess with that. You need to boot from a specially prepared USB with compatible firmware in order to change it. Your problem must have been above UEFI, or an error in your OS that mentioned UEFI.
There have been buggy implementations where UEFI is in fact NOT flashed to the motherboard and can get removed.
If he has one of those crappy computers it could be, but when I read about it happening it was entirely due to users MANUALLY deleting the UEFI files, did not happen upgrading.
In principle by having the repository maintainer review the code they are packaging. They can't do a full security review of every package and may well be fooled by obfuscated code or deliberately introduced bugs, but the threshold for a successful attack is much higher than on Github Actions or npm.
It kinda feels like any CI/CD should only be run on the server after one of the maintainers gives it the okay to do so, after reviewing the code. From this, one can also make the assumption that most of the CI (linting, various checks and tests) should all be runnable locally even before any code is pushed.
