> Build scripts should not run sudo or anything similar. If it does that anyway, it’s wrong. At best, it’s a packaging error, as sudo shouldn’t be expected to work in a non-interactive environment like a build chroot. Sometimes a packager mistakenly tries to move package files into place instead of adding them to the package.
Something I've noticed over time is that security and quality are connected, not inherently but in that there's a lot of overlap. Reviewing an AUR package should include making sure that it doesn't use sudo and doesn't move files into place directly because that's a possible flag for malicious behavior. But equally, sudo is unreliable in the build environment ("sudo shouldn’t be expected to work in a non-interactive environment like a build chroot"), and trying to directly place files instead of packaging them means the package won't upgrade, downgrade, or uninstall cleanly, and won't properly attribute files when you ask the system what owns them. I don't know how well it generalizes, but heuristically I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
> I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
Quality implies knowledge, understanding, and the willingness to use them. Security is the same, but for the narrowed domain of security best-practices and common vulnerabilities. It's possible for something superficially high-quality to be insecure, but that implies that whoever made it either has extremely lopsided experience, or left the vulnerabilities in intentionally or knowingly. Of course, security is a particularly tricky domain, so even a fairly talented and good-intentioned developer is likely to make some missteps. Those missteps, I'd say, qualify as lapses in quality. I'd be damned surprised, on the other hand, to find that something low-quality is secure, and would assume that any such security is the product of a happy accident or sheer simplicity of the software, and is more likely than not to be lost as it grows and changes.
> Build scripts should not run sudo or anything similar. If it does that anyway, it’s wrong. At best, it’s a packaging error, as sudo shouldn’t be expected to work in a non-interactive environment like a build chroot. Sometimes a packager mistakenly tries to move package files into place instead of adding them to the package.
Something I've noticed over time is that security and quality are connected, not inherently but in that there's a lot of overlap. Reviewing an AUR package should include making sure that it doesn't use sudo and doesn't move files into place directly because that's a possible flag for malicious behavior. But equally, sudo is unreliable in the build environment ("sudo shouldn’t be expected to work in a non-interactive environment like a build chroot"), and trying to directly place files instead of packaging them means the package won't upgrade, downgrade, or uninstall cleanly, and won't properly attribute files when you ask the system what owns them. I don't know how well it generalizes, but heuristically I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
> I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
Quality implies knowledge, understanding, and the willingness to use them. Security is the same, but for the narrowed domain of security best-practices and common vulnerabilities. It's possible for something superficially high-quality to be insecure, but that implies that whoever made it either has extremely lopsided experience, or left the vulnerabilities in intentionally or knowingly. Of course, security is a particularly tricky domain, so even a fairly talented and good-intentioned developer is likely to make some missteps. Those missteps, I'd say, qualify as lapses in quality. I'd be damned surprised, on the other hand, to find that something low-quality is secure, and would assume that any such security is the product of a happy accident or sheer simplicity of the software, and is more likely than not to be lost as it grows and changes.