[a-dub]

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).

[embedding-shape]

> the diffs only really show that it's coming from the same source

What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?

Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.

You're mixing concerns here, as what you describe is completely different issue.

[a-dub]

blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.

there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.