On 05/29/2017 04:33 PM, Brandon Milton wrote:
Thank you for the clarification. After reading Allan's blog post regarding keychain separation [1], I understand where my confusion was.
To reiterate what I've learned:
The .sig file allows the user to download a built package and verify it outside of a database setting using `pacman -U`.
Correct. Although I believe it has been suggested that pacman start downloading the sig files instead of bundling it in the repo database, to save on size. (This will help prevent the size from exploding if source packages are added to the databases as well.)
The .sig files in the AUR are entirely different than those used by pacman, as they verify the source files, not the generated .tar.xz files. Furthermore, there should never be a .sig file for a .tar.xz resulting from `makepkg` since the generated binaries are system-independent.
Not strictly correct. sig files for upstream sources are linked in the PKGBUILD sources=() array when upstream sources have them available, and sig files for a .pkg.tar.xz are generated by makepkg --sign or when makepkg.conf contains BUILDENV=(sign) -- that is to say, when the user requests it... which generally doesn't happen unless the user is hosting a binary repo. (Ignore the fact that the official repos don't use this, and instead call gpg when uploading the built package.) Binaries are not necessarily system-dependent. Only the ones with automagic dependencies, or compiled with -march=native, should be. This is also why building in a clean chroot helps, as it uses a minimal set of installed packages and a chroot-specific makepkg.conf with stock values. -- Eli Schwartz