Sure reviewing changes is easy. But the problem is that it is still a review. You need to have an understanding of what exactly is being done and to account for any oddities that may or may not be because of the quirks of upstream. That's why I mentioned that AUR trust models should be made like pacman for most helper. We trust the maintainer of Arch so why can't we trust other people too? Take PPA, the trust model is exactly that. You trust the maintainer. At the very least make it an option that you can choose on first run
All of that wouldn't have any effect if the aur helper mimics the model of pacman. Trust the maintainer, not the build script. By requiring users to review PKGBUILD every time it changes, it encourages laziness. But by requiring the review only once then trusting the maintainer, it helps a lot because the only way an attack can be done is directly attacking infrastructure (pushing malicious script bypassing the auth) or hacking the account (author turning malicious). Both of those are hard with a properly configured system or not worth it because it requires a long game (like those of xz attack)
I feel like with WebRTC API it is already possible to fingerprint the network so no need for BSSID. They just need the database of that instead of BSSID
Adding stuff is easier than patching existing implementations is probably the reason why. Because up until this point, the webserver can just ignore the GET body request but if the client starts sending with body then who knows what bug might surface that turns into security vulnerability.
Yes it is a variant but also it's more general than that. If you sold the same item with a different number of pcs in a pack (even if just a plastic packing), it also gets SKU. In general you can't break SKU into smaller units without making a different SKU.
So if you sell socks in 1, 3, and 5 pairs, all get their own SKU even if every pair of socks in the bundle are the same kind. That means if someone wants to order 1 pcs but you only have SKU for 3 in your system, they can't. Even if the item is there physically. Not unless you remove the SKU of the 3 bundle and add 3 of the 1 (which requires the buyer to communicate it and the seller to jump a bunch of hoops on their system)
SKU is stock keeping unit. So not really about variant pf a product but every unique sellable items should have it's own SKU so you don't accidentally sell 5 of things with one color while only have 3 in stock.
I forgot where I got this, but it is from fediverse
Every *-git package also fetch it from the repo. The apt analogy is someone haven't been maintaining the nixpkg and then it gets adopted by someone else. Now that someone else change the build script to be malware. So it is no fault of the upstream
Not a bad thing IMHO. Reminds me of the very old youtube
Edit: Sorry I realize my rambling didn't answer your question. My suggestion is to not use aura. I do not see anywhere on their repo about their trust model or if they just do it like yay/paru. This is also why I recommend aurto and not aurutils. People would just skip the diff with aurutils.
The thing is, aurto is not the helper. The helper is aurutils. aurto is just the local repo manager that adds timer to auto-update and some QoL features. But to add packages to that local repo, you need to add the maintainer to the trust list. That means the current attack of adopting orphaned / unmaintaned packages is moot. The maintainer change means the package are kicked out and not tracked anymore by aurto. You can still re-add them after you've confirmed that they're safe.
That being said, aurto do have issue. They trust the PKGBUILD of the author/maintainer so if the maintainer got hacked or gone rogue, it will not protect you. Same as with every other package manager in that case.
It is useful because you don't need to migrate the fs if you need to expand later