What you're pointing out is, of course, correct, that was indeed the case with the first attack, but with the current attack, it appears that a binary file is being executed via `sudo` during the package build. At least, that's how I interpreted it from reading the emails on the AUR mailing list.
Since `sudo` is normally configured to require a password, I’m wondering how running `makepkg` with user privileges could cause `sudo` to run unnoticed during the build process. Perhaps if a user was working in the same terminal and had previously run something with `sudo`? If that were the case, it should be possible to prevent this by running `sudo -k, --reset-timestamp` before running `makepkg`. However, I’m not sure if a function in a script like `makepkg` treats `sudo` as if it were being used from a different terminal, and whether the timestamp is irrelevant anyway, which would mean that `sudo` would (usually) require a password to be entered regardless. In short, based on my understanding of the recent attack, the binary was executed via `sudo` during the “build” process, and at the very least, that should be easy to prevent. I’m wondering if I’ve misunderstood something about this specific recent attack.
